Client disconnect

Frederic Bregier fredbregier at free.fr
Thu May 7 06:25:34 EDT 2009


Hi Matthias,

I should have in mind that Netty can split or in contrary assemble write
operations so that the way (second way) that I propose to you was not ok.

Your way is ok but you loose the asynchronous part. Indeed you will wait for
each write (send) operation, which is not taken the possibility of
asynchronous operation (written a lot but wait only once a time).

If in your protocol there is always a "last" send operation, I would suggest
to use the way I propose to you, that is to say to explicitely wait on this
last write (send) and not the previous one). And if you only have to close
the channel, you could simply add the ChannelFutureListener.CLOSE to this
last write (send). 

If you have something else to do and if it can be done after the close of
the channel, then do the same but override the channelClosed method in order
to do what you have to do.

What I didn't get from you post is your question about "how to get a
ChannelHandlerContext outside the predefined methods"? I suppose that you
override predefined method to implement your handler, so that you have
access to those arguments. If you add more methods, you could of course pass
those arguments to the your own methods.
Or perhaps you are doing a client connection and then get back the channel
from the connection and directly use it? If so, then you have two choices
(at least): one is implementing your business in the handler of the client,
the other one is to store the channel in your own class which is not an
handler (which is what you want, the ChannelHandlerContext is just a way to
get back this value).
Perhaps I missed something in your question... ? ;-)

HTH,
Frederic


-----
Hardware/Software Architect
-- 
View this message in context: http://n2.nabble.com/Client-disconnect-tp2798147p2827161.html
Sent from the Netty User Group mailing list archive at Nabble.com.




More information about the netty-users mailing list