New Feature Request - Connection caching

[Trustin Lee]

Hi Simon,

On Sat, Nov 22, 2008 at 04:34:08AM +0900, Simon Trudeau wrote:
> Interesting, encapsulating the reconnection mechanics in its own handler
> would certainly work, although I guess a bit more plumbing would be required
> to make something more error resistant. A good connection caching mechanism
> needs to handle the case where the connection with the remote host was
> silently terminated (network cable disconnected) and invoking the send
> method on the channel will most certainly trigger an exception. In that case
> we need a retry mechanism where a new connection gets created and the
> message we were attempting to send but failed due to the exception will get
> resent on the new channel.

Yes.  Whenever a disconnected channel is detected, you will be notified
with a channelDisconnected event, so you should be able to attempt
reconnection there.  My point is that automatic reconnection can be
built on top of manual reconnection.

> Also, what's tricky is managing concurrency, for example the case where
> given two threads who want to send messages to the same ip address one must
> wait for the other to finish establishing the connection.

Yes, that is true.  I think there should be some notification mechanism
when the state of a channel changes.  We can do this already by adding
another ChannelHandler, but Netty doesn't provide an out-of-the-box
handler implementation that helps this case.  A good suggestion!

> My preliminary idea was that there should be a virtual channel to abstract a
> physical channel. The client would write and receive messages from / to the
> virtual channel thus providing the proper level of abstraction. The virtual
> channel would maintain a certain number of connections to a remote IP and
> would deal with connection / reconnection and retry should the physical
> channel becomes disconnected or there is a failure. Thinking about it, I
> guess this could be implemented in an handler. Although this handler would
> need to be global in scope because it could be shared by many threads. For
> instance, in my system, many concurrent JMS sessions will trigger the
> sending of different messages to the cellular device.

Could you let me know what is the difference from the message
retransmission on TCP or JMS level?  OS TCP stack and JMS already does the
job for you in this case, no?

> Connection caching is far from trivial... :.)

Very true.  That's why I'd like to break it into small features so that
a user can combine them into the reconnection policy that he or she
wants to implement.

> Hope this little discussion can help the community come up with an elegant
> and most importantly resiliant connection pooling mechanism!

Sure.  Please keep posting your ideas.  I really appreciate them!

Cheers,
Trustin

> On Fri, Nov 21, 2008 at 1:49 PM, Trustin Lee <trustin at gmail.com> wrote:
> 
>>
>> Hi Simon,
>>
>> If I understood correctly, it sounds like your problem could be resolved by
>> reconnection feature, which will be implemented in 3.1.
>>
>> With reconnection, Netty will automatically (or manually) attempt a new
>> connection when the previous connection is disconnected.  It should be as
>> simple as calling connect() again on a disconnected channel in your
>> handler's channelDisconnected method.  Then, it is guaranteed that only one
>> connection is made per device.
>>
>> WDYT?  Would this approach work for you, or am I missing something?
>>
>> Thanks for your feed back,
>> Trustin
>>
>>
>> SimonT wrote:
>>>
>>> I have been an intensive Mina 2.x user for the past year and have always
>>> liked the relatively simple use of the API over other NIO frameworks.
>>> Unfortunately, what's always been a pain on the client side is the
>>> connection management. There was no easy mechanisms for connection
>>> pooling.
>>>
>>> My application needed to create 1000+ concurrent tcp client connection to
>>> cellular devices. The connections couldn't be permanent, those devices
>>> could
>>> only accept one connection at a time. Connecting again to a device would
>>> cause the previous connection to get dropped.
>>>
>>> What's really clumsy about the client API is this idea of connect - send,
>>> when all we want to do is send and connect only if there are no opened
>>> connections in the pool (establishing a connection takes a long time).
>>> What's hard is to keep track in which state is the connection attempt
>>> (attempting to connect, connected by attempting to disconnect, connected,
>>> etc...). Also, what's complicated about developping your own connection
>>> pool
>>> is the error management, you always have to check if the connection is
>>> still
>>> valid, check that the connection future is not taking too long, etc...
>>>
>>> It would really be appreciated if NETTY could provide developpers with
>>> connection pooling capabilities.
>>>
>>> I hope to see it in a future NETTY release. :.)
>>>
>>>
>>> Simon
>>>
>>
>>
>> -----
>> Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> View this message in context:
>> http://n2.nabble.com/New-Feature-Request---Connection-caching-tp1562733p1563017.html
>> Sent from the Netty User Group mailing list archive at Nabble.com.
>>
 
-- 
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20081124/aa933f65/attachment.bin