Hi James, On Jan 1, 2008 8:02 AM, James Mansion <[EMAIL PROTECTED]> wrote: > I'm having a play with mina-core-2.0.0-M1-20071221.061156-110 > > I'm using slf4j-simple-1.4.3. > > If I add a LoggingFilter using addLast to the filter chain (as the first > such addLast call), then the logging filter will use its > EXCEPTION_CAUGHT if I have a socket client that connects, does not send > anything, and then disconnects. > > The trace looks like: > > Listening on port 2960 > 10836 [NioProcessor-1] WARN org.apache.mina.filter.logging.LoggingFilter > - [/127.0.0.1:4036] EXCEPTION: > java.io.IOException: An existing connection was forcibly closed by the > remote host > at sun.nio.ch.SocketDispatcher.read0(Native Method) > at sun.nio.ch.SocketDispatcher.read(Unknown Source) > at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) > (and so on) > > Two things: > > 1) I'd like to receive this in the exceptionCaught method of my > IoHandlerAdapter - and if I don't push the logger into the filter chain > then its what happens.
That's weird. I tried to reproduce this problem but failed. Could you provide reproducing source code? > 2) It doesn't seem to be thrown for clients that connect, write a > message (which I handle with a specialised codec) and then quites. I think it depends on network status. The client might not know if the connection has been closed yet. > I'd like to have the filter so I can turn on logging for the session and > message events, but setting the log level to NONE for EXCEPTION_CAUGHT > doesn't pass it on - it seems to consume it silently. > > Is there any way I can achieve what I want? Ideally I'd like my > exceptionCaught handler to be called first and to be able to filter the > exception at that level, so that only exceptions I don't discard will be > reported by the filter. Any filter implementation is supposed to propagate EXCEPTION_CAUGHT event to the next filter or the IoHandler, so what you are experiencing might be a bug of a MINA filter or your filter implementation, if you inserted your own filter. > A further issue is that if I 'pass on' to super.exceptionCaught then I > get 'please implement <myclass>.exceptionCaught() for proper handling' > and in the case of a client dumping the connection untidily without > writing the exception repeats - nothing closes the session and the > process spams its log. The log message was added to force a user to override exceptionCaught() method because we found some people forget to override it and fails to spot a problem. > Is the difference of behaviour between the cases of a client that does > write and one that doesn't indicative of a bug? Well.. I don't think so. It would be really nice if you could come up with some example code that reproduces the problem. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
