Multiplexing a client connection

JonY jonathan.yonker at lmco.com
Wed Jul 29 23:23:30 EDT 2009


Frederic,

Thank you for your reply. 

Unfortunately, I've had some trouble implementing your solution. I created
an object to contain the client bootstrap and channel and I pass it to my
client and server handlers. I put a listener on all messages that attempt to
send on the channel. The listener checks the isSuccess() function and, if
false, tries to connect on the bootstrap again. 

I have a channelfuture for this conection which returns true to isSuccess(),
but when I try to write to this new channel, it throws a
ClosedChannelException just like before.

Does isSuccess() tell you whether or not the connection actually worked, or
is it a purely user-set flag? I haven't been able to find a definitive
answer to this in the documentation. Regardless, I feel like this approach
should work. Do you have any ideas as to why it isn't?

Thank you for your help,

Jon


Frederic Bregier wrote:
> 
> Hi Jony,
> 
> As far as I understand your questions, you have to face up several
> differents problems.
> 
> A client bootstrap is somehow a shortcut to enable easier connection. So
> if you use it to reconnect when the previous channel is over (closed), it
> is just fine.
> 
> Now, to keep the reference of your "current" client channel (as it could
> change), I would suggest you to store it in an object that would contain
> for instance the bootstrap but also the last and current active channel.
> Doing that, you will have to pass this object to each server channel, such
> that you can write to the current and active client channel.
> 
> Now to replay the messages that weren't sent through the local client
> channel, several ways (and other that I don't have in mind right now) can
> be achieved (less simple):
> - you can first test if the channel is still connected before writing. If
> so just write, if not, re open the channel, replacing the previous one
> with the new one. Take care to be "thread safe" there since it could be a
> minn breaker (take care that if a problem occurs, only one thread will try
> to reopen the channel and that other will wait this operation is ok to
> reuse the result and to not close and reopen again a new one when not
> necessary). This would be the most difficult operation. 
> - Perhaps a more simpler way would be to only add this handling in
> exceptionCaught and channelClosed of the client channel such that it only
> occurs there. However, for write operation, you should add something to
> test the channel is still connected or in reconnection process...
> - you can also be blocking on the write operation (await), but keep
> attention that you will have blocking operation, thus less efficiency. If
> the operation is not in success, you know that you will have to send again
> it through the new client channel.
> - you can also add a listener on each write operation (much better than
> await), a future listener on close or error, such that you will be
> informed asynchronously that there was a problem, such that you can send
> again your message. Note that the future listener will only inform you of
> the end of the operation (and therefore the status) but you will have to
> create a new future listener for each write such that in the constructor
> of this future listener you can pass the message you wanted to write again
> in case of error. Doing this way, I would suppose that you don't need to
> have a list of messages since the future listeners will do that for you.
> 
> Well, I could say more, but I think this is a start, some ideas...
> HTH,
> Frederic
> 
> 
> JonY wrote:
>> 
>> Hello Everyone,
>> 
>> I'm pretty new to netty, and I'm having a little trouble implementing a
>> solution that I believe netty can handle. What I have so far is an
>> application that contains a client bootstrap and a server bootstrap. The
>> server accepts multiple connections and writes them to the client
>> bootstrap's one persistent channel. The way I've done this is by passing
>> the client bootstrap's channel to the server's handler and writing to it
>> (I'm assuming there's a better/safer way to do this?). 
>> 
>> In addition to improving my current implementation, I need to be able to
>> reconnect the client piece if the connection dies (i.e. unplugging the
>> cable). I've tried reconnecting the channel in the client handler, but
>> the channel sometimes gets closed even if the connection dies. I've also
>> tried a number of other solutions involving trying to reconnect the
>> bootstrap, etc from the exceptionCaught handler.
>> 
>> Given my current implementation, I need some way to reconnect the client
>> bootstrap and then send the new channel to the server bootstrap. The
>> server bootstrap then needs to start writing all of the data that has
>> been queuing on the old channel to the new channel.
>> 
>> Any help/suggestions would be greatly appreciated!
>> 
>> Jon
>> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/Multiplexing-a-client-connection-tp3347008p3354060.html
Sent from the Netty User Group mailing list archive at Nabble.com.


More information about the netty-users mailing list