This content has been marked as final. Show 8 replies
Unicast or Multicast is Just a Mode of Communication between the Members of the Cluster...In case of Multicast each and every member of the Cluster Sends it's heart beat message to all the other members available in the Cluster....It creates a Bit burden on the Network...(some times called as Multicast Storm as well).
In Unicast Complete Cluster is automatically gets divided in multiple Groups and Every group the Oldest member (A member Managed Server which is started earliest) becomes the Group Leader....All the Group members now sends their heatrbeat messages only to the group leaders and not All the members...All the group members then sends the Heart beat messages of their group members to the "Cluster Master".
Please have a look on the Diagram: http://jaysensharma.wordpress.com/?attachment_id=556
The unicast messages can appear like normal system message. In one embodiment of present invention that uses the Weblogic T3 protocol, the wire level messages can appear like T3 messages to network monitors with specially encoding to differentiate from other types of T3 requests. The T3 dispatcher on the receiving side can understand the special nature of the unicast requests and dispatch them to a special handler without going through the connection management layer. The socket connection established for unicast messaging need not be shared by other T3 clients and can be maintained exclusively for unicast messaging. This can enable closing and re-opening connections without worrying about ripple effects on other T3 users.
did you ever had problems with unicast and weblogic 10.3.1? we have 3 clusters (c1, c2, c3, each one with 2 managed server m1 and m2).
a transaction starting on c1 (c1-c2-c1-c3-c2-c3-c1) sometimes we've got the following error. with multicast we never had such an exception.
<Feb 1, 2010 8:02:18 AM CET> <Error> <Cluster> <BEA-000141> <TCP/IP socket failure occurred while fetching statedump over HTTP from -3954610625469552096S
I am co-worker of BOD and like to specify an other aspect of the same problem. Often the transactions get cancelled with the following exception:
javax.transaction.SystemException: SubCoordinator 'managedServer_a_xx_01+a-xx-appl01:31370+a_xx+t3+' not available
at weblogic.transaction.internal.CoordinatorImpl_WLSkel.invoke(Unknown Source)
We suspect that the clusters are not synchronised like they should. Interestingly the same code ran well on weblogic 9.2.3 with multicast. Now with weblogic 10.3.1 with unicast enabled we encounter these problems. Furthermore we should mention that the replication occurs on the default channel.
No we use unicast, means that the multicast is not activated, and even if it was we had before an different multicast address and port for each cluster.
As a matter of fact, we found the problem being one of the cluster in the DMZ. Means that the firewall blocks the request.
The problem itself is caused by cluster A in the green zone which calls cluster B in the green zone and cluster C in the dmz.
To our big surprise cluster C tries to call cluster B for checking his subcoordinator!
And which is even worser, if we take down all servers except one in cluster B, it works! Means that cluster C doesn't try to communicate with B anymore.
Is there any explanation for this very strange behaviour?
I have the same problem.
####<Jun 8, 2012 10:52:11 AM CEST> <Error> <Cluster> <c-572> <social_c-572> <[ACTIVE] ExecuteThread: '10' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1339145531976> <BEA-000141> <TCP/IP socket failure occurred while fetching statedump over HTTP from 3026061844013098928S:slish577:[17705,17705,-1,-1,-1,-1,-1]:wl-social:social_c-577.
weblogic.net.http.HttpUnauthorizedException: Proxy or Server Authentication Required