Some things I don't understand in the transport

[timfox]

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.

[ataylor]

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.

[jmesnil]

"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.