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