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

Tim Fox (JIRA) jira-events at lists.jboss.org
Mon Apr 30 06:47:33 EDT 2007


     [ http://jira.jboss.com/jira/browse/JBMESSAGING-789?page=all ]

Tim Fox closed JBMESSAGING-789.
-------------------------------

    Fix Version/s: 1.2.1.CR1
                       (was: Unscheduled)
       Resolution: Won't Fix
         Assignee: Tim Fox

Due to the nature of how remoting is designed there is not much we can do about this (apart from remover remoting) AFAICT.

Remoting uses a client side pool of connections with all the socket based transports.

This means subsequent invocations can be executed on different connections.

Sychronizing is a good work around for now until we use a better transport.

> 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
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.1.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

        



More information about the jboss-jira mailing list