Re: Happy new year !

2007-12-31 Thread Jeff Genender


Emmanuel Lecharny wrote:
 Hi Ladies and Gentlemen,
 
 I wish you an Happy New Year ! I hope that 2008 will be way better than
 2007, with less wars, less bugs and less cholesterol :)

Hmmm...with you being from France...that cholesterol thing may be a
tough one ;-)

Happy new year to you guys too and am glad to be helping out.

Jeff


Catching IO exception

2007-12-31 Thread James Mansion

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.


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'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.


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.


Is the difference of behaviour between the cases of a client that does 
write and one that doesn't indicative of a bug?


James



TextLineDecoder bug

2007-12-31 Thread rstupek

I've found a bug in TextLineDecoder.  The following will not be correctly
interpreted by the decoder using \r\n as the LineDelimiter

This is some text\r\r\n

I believe the issue is that the decoder encounters the first \r and is not
able to match because the second character is not a \n but it then has
skipped the second \r for purposes of matching the next character which is a
\n
...
byte b = in.get();
if (delimBuf.get(matchCount) == b) {
...
-- 
View this message in context: 
http://www.nabble.com/TextLineDecoder-bug-tp14563042s16868p14563042.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.