Non causality when using Remoting socket transport and one way invocations -------------------------------------------------------------------------- Key: JBMESSAGING-789 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-789 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Priority: Critical Fix For: 1.2.0.CR1 The remoting socket transport uses an underlying pool of tcp connections, and subsequent invocations get a connection from the pool, use it and return it from the pool. This means that subsequent invocations can use a different underlying TCP connection, and later invocations can overtake earlier ones depending on how the OS schedules the read threads listening on the connections. Temporary work around is to use a pool size of 1, or completely serialize all invocations per VM by encloing in the synchronized block. This gives us effectively one TCP connection per VM. A better approach would be for the remoting Client object to be pinned to the actual TCP connection one to one. I.e. we don't want or need the pool. It is just a big PITA for us. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira