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.<br>
<br>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. <br><br>
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.<br>
<br>Connection caching is far from trivial... :.)<br><br>Hope this little discussion can help the community come up with an elegant and most importantly resiliant connection pooling mechanism!<br><br><br>Simon<br><br><div class="gmail_quote">
On Fri, Nov 21, 2008 at 1:49 PM, Trustin Lee <span dir="ltr"><<a href="mailto:trustin@gmail.com">trustin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi Simon,<br>
<br>
If I understood correctly, it sounds like your problem could be resolved by<br>
reconnection feature, which will be implemented in 3.1.<br>
<br>
With reconnection, Netty will automatically (or manually) attempt a new<br>
connection when the previous connection is disconnected. It should be as<br>
simple as calling connect() again on a disconnected channel in your<br>
handler's channelDisconnected method. Then, it is guaranteed that only one<br>
connection is made per device.<br>
<br>
WDYT? Would this approach work for you, or am I missing something?<br>
<br>
Thanks for your feed back,<br>
Trustin<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
SimonT wrote:<br>
><br>
> I have been an intensive Mina 2.x user for the past year and have always<br>
> liked the relatively simple use of the API over other NIO frameworks.<br>
> Unfortunately, what's always been a pain on the client side is the<br>
> connection management. There was no easy mechanisms for connection<br>
> pooling.<br>
><br>
> My application needed to create 1000+ concurrent tcp client connection to<br>
> cellular devices. The connections couldn't be permanent, those devices<br>
> could<br>
> only accept one connection at a time. Connecting again to a device would<br>
> cause the previous connection to get dropped.<br>
><br>
> What's really clumsy about the client API is this idea of connect - send,<br>
> when all we want to do is send and connect only if there are no opened<br>
> connections in the pool (establishing a connection takes a long time).<br>
> What's hard is to keep track in which state is the connection attempt<br>
> (attempting to connect, connected by attempting to disconnect, connected,<br>
> etc...). Also, what's complicated about developping your own connection<br>
> pool<br>
> is the error management, you always have to check if the connection is<br>
> still<br>
> valid, check that the connection future is not taking too long, etc...<br>
><br>
> It would really be appreciated if NETTY could provide developpers with<br>
> connection pooling capabilities.<br>
><br>
> I hope to see it in a future NETTY release. :.)<br>
><br>
><br>
> Simon<br>
><br>
</div></div>> _______________________________________________<br>
> netty-users mailing list<br>
> <a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
><br>
><br>
<br>
<br>
-----<br>
Trustin Lee, Principal Software Engineer, JBoss, a division of Red Hat<br>
--<br>
what we call human nature is actually human habit<br>
--<br>
<a href="http://gleamynode.net/" target="_blank">http://gleamynode.net/</a><br>
<font color="#888888">--<br>
View this message in context: <a href="http://n2.nabble.com/New-Feature-Request---Connection-caching-tp1562733p1563017.html" target="_blank">http://n2.nabble.com/New-Feature-Request---Connection-caching-tp1562733p1563017.html</a><br>
Sent from the Netty User Group mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
</font></blockquote></div><br>