Notification of handler removed (separate from ChannelHandler.handlerRemoved(ctx))

[Rogan Dawes]

Hi folks,

I'm trying to monitor changes to the pipeline, and wondering if there is any way to be notified when a handler is removed from a pipeline?

By that I mean, independently of the specific handler's handlerRemoved(ctx) method call. I'd like to be able to tell when a particular handler is removed, without having to extend it and override that method on every single handler.

From what I can see, the only way to do it at the moment is by using Aspect-Oriented programming, and decorating each handler that is added (a slight difference from manually extending each handler).

Am I missing something?

Thanks!

Rogan

[Norman Maurer]

No there is nothing like that.

Bye

Norman

--
You received this message because you are subscribed to the Google Groups "Netty discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netty+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netty/0c580f34-35bf-4d69-ad80-f0ad0d7e1605%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rogan Dawes]

I guess I could try using Java.lang.reflect.Proxy to wrap the class and supplement handlerRemoved.

Should work ok, I think.

Rogan

To view this discussion on the web visit https://groups.google.com/d/msgid/netty/3CA9AB84-DC67-4BAB-8392-AC8143F79440%40googlemail.com.

[Rogan Dawes]

Nope, java.lang.reflect.Proxy won't work either, because of things like:

ChannelInitializer:

void initChannel(Channel ch) throws Exception {

  String me = ch.context(this).name();

  ch.pipeline().addAfter(me, null, new WhateverHandler());

}

fails with a NullPointerException because context(this) returns null, because "this" is not actually in the pipeline(), Proxy(this) is!

Sigh!

While in theory, I could extend handlerAdded(ctx) and save a ref to the ctx to be used in initChannel(), that would work for my own code, but is unlikely to work for anyone else's!

Perhaps there is a way to achieve what I want without the shenanigans?

What I'm ultimately trying to do is "blame" the ChannelHandler that throws an Exception.

So while I can implement exceptionCaught() in the last handler of the pipeline, and catch the Exception, it's impossible to know which ChannelHandler actually threw that Exception, other than by stepping through the stackTrace, and looking for my own code (or Netty code, as the case may be!) However, if there is more than one instance of a particular ChannelHandler (e.g. tunnelling SSL in SSL), that still doesn't tell you which *instance* threw the exception.

My solution to that was to alternate legitimate ChannelHandlers with an ExceptionCatcher ChannelHandler. Each ExceptionCatcher has a reference to the ChannelHandler before it. The first ExceptionCatcher to have its exceptionCaught() method called can blame the ChannelHandler immediately preceding it.

HOWEVER, should that ChannelHandler remove itself from the pipeline, or insert other ChannelHandlers, it all falls down, because the ExceptionCatcher gets left behind!

An alternative way to approach this would be to extend DefaultChannelPipeline, but that kind of thing seems to be deprecated in netty 4.

Any suggestions?

Thanks!

Rogan

[Rogan Dawes]

Would taking the approach used in CombinedChannelDuplexHandler work, perhaps?

i.e. using something like the DelegatingChannelHandlerContext to intermediate access to the pipeline? Possibly creating sub-pipelines using EmbeddedPipeline, perhaps?

Rogan