[netty-users] New Feature Request - Connection caching

[Simon Trudeau]

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.

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.

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.

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

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


Simon

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
> >
> > _______________________________________________
> > netty-users mailing list
> > netty-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/netty-users
> >
> >
>
>
> -----
> 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.
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20081121/651cc120/attachment.html