2 Replies Latest reply on Jul 11, 2008 3:32 AM by Jeff Mesnil

    Some things I don't understand in the transport

    Tim Fox Master

      Looking through the code in detail as I look at the packet replication stuff, some questions spring to mind:

      1) Why do we need to create multiple RemotingSession objects per RemotingConnector? Why not just use the same RemotingSession object, then RemotingConnector and RemotingSession could be combined in a single object.

      2) Why do we create a new RemotingConnection object each time we create a jms connection? why not just use the same one per server? the RemotingConnection object could be stored in the connector registry. Moreover each RemotingConnection object currently starts its own pinger, this means we have one pinger per jms connection even if they are working over the same underlying tcp connection, which is unnecessary.

      Seems to me our cardinalities are a bit messed up.

        • 1. Re: Some things I don't understand in the transport
          Andy Taylor Master

          you're correct on both counts, in the end they use the same connector so it would make sense to change it, this would actually simplify things.

          • 2. Re: Some things I don't understand in the transport
            Jeff Mesnil Master

             

            "timfox" wrote:
            1) Why do we need to create multiple RemotingSession objects per RemotingConnector? Why not just use the same RemotingSession object, then RemotingConnector and RemotingSession could be combined in a single object.


            The RemotingSessions object created for the same RemotingSession wraps the same MINA IoSession internally.


            2) Why do we create a new RemotingConnection object each time we create a jms connection? why not just use the same one per server? the RemotingConnection object could be stored in the connector registry. Moreover each RemotingConnection object currently starts its own pinger, this means we have one pinger per jms connection even if they are working over the same underlying tcp connection, which is unnecessary.


            yes, this code is more convoluted than necessary.
            Anything refactoring to simplify it would be a good thing.