[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Brian Stansberry updated JBCLUSTER-220: --------------------------------------- Issue Type: Feature Request (was: Bug) This behavior is inherent in JGroups. In order to ensure ordered delivery of messages from a sender to the application, only one thread at a time is allowed to carry a message to the application from each sender. So if you had a 4 node cluster {A, B, C, D} on A at most 3 threads would be carrying regular messages to the application, one from B, one from C, one from D. Another thread carrying a message from B will block until the first "B" thread returns. Effect of this is if you use the thread carrying the first "B" message to make a synchronous RPC back into the cluster, the response to your RPC from B can't be received, because the thread carrying the response will block. To deal with this, use a separate thread to make the synchronous RPC and let the first thread return promptly. Or, make an asynchronous RPC (HAPartition.callAsynchMethodOnCluster(....)). I'm keeping this JIRA open as I think it's a legit feature request to find a way to make this easier. Off the top of my head, a possible approach would be add a way to tell JGroups to make the response to the RPC an "out-of-band" message, which JGroups will let proceed to the application even though another thread from the sender is already calling on the application. No matter what, any improvement on this in ha-server-api is going to be based on changes in JGroups. If this is a priority for you, suggest you post on the javagroups-development(a)lists.sourceforge.net to see what the JGroups devs have to say. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Bela Ban commented on JBCLUSTER-220: ------------------------------------ Brian, did you know that RpcDispatcher already has a method callRemoteMethods() which has an 'oob' parameter ? I don't think this is exposed at the callMethodOnCluster() method though. If a recursive synchronous method call had an OOB flag, the call would not block ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Bela Ban commented on JBCLUSTER-220: ------------------------------------ In 2.6.7, only the request is OOB, *not* the response. In 2.7 and later, the response is *always* OOB. I changed that because I removed the deadlock detection code in 2.7 and later. Should I backport this change to 2.6.x (2.6.8) ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Brian Stansberry commented on JBCLUSTER-220: -------------------------------------------- Bela, A backport of making the response always OOB to 2.6.8 would be great; that would remove this issue for a lot of cases. I'll add an overloaded callMethodOnCluster to HAPartition to allow the OOB request, but that's an API change, so AS 6. Fol de Rol, JGroups 2.4 does not support out-of-band messages. You could try using JGroups 2.6.7 in community AS 4.2.x. If it works, then when 2.6.8 comes out you can move to that and get the benefit Not sure if JGroups 2.6.x will work in AS 4.2; haven't tried it. But I think it should. For sure you'll get some WARN logging about using deprecated configuration attributes, but the log messages do a good job of explaining what's wrong; generally you just remove attributes that are no longer relevant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Fol de Rol commented on JBCLUSTER-220: -------------------------------------- 2.7 does not work with JBoss 4.2 because of conflicts in class definitions. 2.6.7 works though I see lots of warnings: [UDP] down_thread was deprecated and is ignored [UDP] up_thread was deprecated and is ignored [UDP] Attribute "use_outgoing_packet_handler" has been deprecated and is ignored [PING] down_thread was deprecated and is ignored [PING] up_thread was deprecated and is ignored [MERGE2] down_thread was deprecated and is ignored [MERGE2] up_thread was deprecated and is ignored [FD_SOCK] down_thread was deprecated and is ignored [FD_SOCK] up_thread was deprecated and is ignored [FD] down_thread was deprecated and is ignored [FD] up_thread was deprecated and is ignored [VERIFY_SUSPECT] down_thread was deprecated and is ignored [VERIFY_SUSPECT] up_thread was deprecated and is ignored [NAKACK] down_thread was deprecated and is ignored [NAKACK] up_thread was deprecated and is ignored [NAKACK] max_xmit_size was deprecated in 2.6 and will be ignored [UNICAST] down_thread was deprecated and is ignored [UNICAST] up_thread was deprecated and is ignored [STABLE] down_thread was deprecated and is ignored [STABLE] up_thread was deprecated and is ignored [GMS] down_thread was deprecated and is ignored [GMS] up_thread was deprecated and is ignored [GMS] join_retry_timeout has been deprecated and its value will be ignored [FC] down_thread was deprecated and is ignored [FC] up_thread was deprecated and is ignored [FRAG2] down_thread was deprecated and is ignored [FRAG2] up_thread was deprecated and is ignored [STATE_TRANSFER] down_thread was deprecated and is ignored [STATE_TRANSFER] up_thread was deprecated and is ignored [STATE_TRANSFER] use_flush has been deprecated and its value will be ignored Is this normal to ignore them? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBCLUSTER-220?page=com.atlassian.jira.... ] Brian Stansberry updated JBCLUSTER-220: --------------------------------------- Fix Version/s: HA-Server-API 2.0.0.Beta1 Scheduling for the next major release of HA-Server-API. This is to add overloaded methods to HAPartition to pass through what's now available in RpcDispatcher. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira