[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-789) Non causality when using Remoting socket transport and one way invocations

[Tim Fox (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-789?page=comments#action_12351821 ] 
            
Tim Fox commented on JBMESSAGING-789:
-------------------------------------

Actually I don't think setting clientMaxPoolSize=1 will work since the transport will create a new connection if there is none available in the pool.

> 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