Exception on connect being caught by response handler

[Johnny Luong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/22/2010 11:59 AM, jgalyan wrote:
> I'm implementing ChannelFutureListener so I can avoid awaiting on
> ChannelFutures and keep my application entirely asynchronous and event
> driven.  When an exception happens during the connection attempt from my
> client to a server, I expected the exception to be held by the ChannelFuture
> so I could deal with it in operationComplete; instead, it's getting caught
> by my response handler (the exception is Connection Refused, which I
> wouldn't expect to be coming upstream to me).  Are my expectations wrong
> here?
> 
> My use case is as follows:
> I have a server that, as part of servicing a request from a client, sends a
> request to a host in a cache cluster.  If the request to the host fails for
> whatever reason, I want to mark that host down for a period of time so my
> server doesn't try to contact that host again (hosts in the cluster go down
> to reload their data periodically, by design.  At least two hosts in the
> cluster will be up at any given time, but which two is not something I can
> know in advance, for obvious reasons).  I would have expected the exception
> caused by a host being down to be caught and held by the
> ChannelFutureListener I attach to the future returned by connect(), rather
> than being passed to the response handler's exceptionCaught method. (If the
> connection fails, then a request doesn't get sent, so why would the response
> handler be called here?) 
> 
> Do I need to implement exceptionCaught in the ChannelFutureListener
> implementation or did I simply misunderstand the way the framework handles
> exceptions?

Hi,

I'm not really sure if there is an explicit contract with the API on
terms of what is fired but the following might help:

When the ChannelFuture callback is executed, is it telling you the
channel has failed to open?  I would think that it would do so and fall
under the Completed with failure case described here:

http://docs.jboss.org/netty/3.2/api/org/jboss/netty/channel/ChannelFuture.html

- From what I can tell of the non blocking and blocking connects (see
source code for sink for connect), it would appear that an exception is
fired on the connect in the failure scenario.  So I'm thinking that you
should see both your callback telling you it failed and you'll see the
upstream event you described.  From the application I write, I actually
monitor for the channel closed event since I think it is a side effect
of the different implementations as a means of handling a timer
reconnect scenario which catches a lot of the cases I am interested in.

Best,
Johnny


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzrK4IACgkQg7TIS7A9iscOGwCfZnR7MBDnttycxMcEJQ1DI6Jw
LQcAoJPujtZmiOLOUIJhdtcjHHRvag9W
=XgEO
-----END PGP SIGNATURE-----