https://blogs.oracle.com/ateamsoab2b/entry/coherence_in_soa_suite_11g
http://biemond.blogspot.com/2014/02/configure-coherence-hotcache.html
Configure Coherence HotCache
Coherence can really accelerate and improve your application because it's fast, high available, easy to setup and it's scalable. But when you even use it together with the JCache framework of Java 8 or the new Coherence Adapter in Oracle SOA Suite and OSB 12c it will even be more easier to use Coherence as your main HA Cache.
Before Coherence 12.1.2 when you want to use Coherence together with JPA for the database connectivity, you must make sure that there is no batch job or application doing modifications directly in the database. This will lead to an out of sync Coherence Cache. But with Coherence 12.1.2 together with GoldenGate you can capture these database changes and send updates to the Coherence Cache. This is called Coherence HotCache.
Oracle SOA Suite 11g utilises an embedded Coherence cache to coordinate several cluster-wide activities including composite deployment
By default, this embedded Coherence cache is configured for multicast node discovery. This is normally fine, because you probably should only have one cluster on a subnet, and the multicast packets usually don't cross the router boundary. However, it may be the case that you wish to have multiple clusters on a single subnet, or your router is forwarding multicast for you.
You may encounter problems with deployment, for example, if you have two independent SOA clusters that can see each other through Coherence. Check your log files for a message like this:
[SOA_server1] [ERROR] [] [Coherence] [] [] [APP: soa-infra] 2011-08-01 00:00:00.000/0000.000 Oracle Coherence GE 3.6.0.4 (thread=Cluster, member=1): This senior Member(Id=1, Timestamp=2011-08-01 00:00:00.000, Address=10.10.10.10:8088, MachineId=43868, Location=site:blah,machine:blah1,process:15875, Role=WeblogicServer) appears to have been disconnected from another senior Member(Id=1, Timestamp=2011-07-01 00:00:00.000, Address=10.11.11.11:8088, MachineId=43815, Location=site:blah,machine:blah2,process:18955, Role=WeblogicServer); stopping cluster service.
What has happened here is that the machine blah1 has seen the cluster that's owned by machine blah2 because they're both sharing the same multicast information. This can cause a deployment on blah1 to stop responding, ultimately resulting in things like "Stuck Thread" warnings from Weblogic server.
If you wish to separate the two clusters and you should, because they shouldn't be communicating with each other, you have two options.
You can reconfigure the embedded Coherence for Unicast operation, and use Well-Known Addressing (WKA). This is documented in the HA documentation for SOA: http://download.oracle.com/docs/cd/E21764_01/core.1111/e10106/ha_soa.htm#ASHIA3848. For a single node environment you can simply specify the localhost as wka1 and "localhost" at the same time and you've effectively isolated it from other environments.
You can reconfigure the multicast address and port that Coherence is listening on. This can be done by specifying -Dtangosol.coherence.clusteraddress and -Dtangosol.coherence.clusterport, instead of using the WKA techniques above (otherwise, you should follow those instructions for where to set these properties). These should follow the usual rules for Coherence multicast cluster addressing (specifically, the address has to be from the multicast IP address range and unique amongst your Coherence clusters). It is normally recommended to make both unique, and not just set the port differently, because there have been problems with the OS level sockets on different ports "seeing" each others packets.
Hopefully this will help you get your cluster (even a cluster of one node) working.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment