On 4/30/10 2:08 AM, d...@xx wrote:
I am using last version 2.0.0 RC1
Ok.

The NPE you got was dur to the fact that the encoder is not present anymore in the session. What MINA does is just to propagate the exception. If you look at the stack trace, the cause in a NPE found in line 298, which is :

296     try {
297     // Now we can try to encode the response
298     encoder.encode(session, message, encoderOut);


where the encoder has been grabbed from the session. If the session has expired, obviously the encoder which is stored as an atttribute in this session will be null, thus the NPE.

Basically, it won't hurt, except that getting NPE is, well, not good.

We can improve the coe by checking that the encoder is not null before encoding the message, but as the session may expire at any moment (for instance, a few lines later, when we try to flush the data), we will have to deal with some other NPE.

Another possibility would be to catch the NPE and deal with this case (an expired session while we are trying to send some data back to the gone client). I don't really like this approach (NPE should not be catched, IMO).

What else ? We can also keep all the attributes into the session being closed, just to be sure that those elements won't be nul when we will try to read them. The problem with this is that we it will put some extra load on the server, as it will work for nothing until it detects that the session has expired.

Not that easy :/


JY

----- Original Message ----- From: "Emmanuel Lecharny" <elecha...@gmail.com>
To: <us...@mina.apache.org>
Sent: Friday, April 30, 2010 1:57 AM
Subject: Re: NullPointerException in ProtocolCodecFilter


Which version of MINA are you using ?

On 4/30/10 12:24 AM, Erinc Arikan wrote:
I thought it was handling that case, but in my application it was failing to do so. Your issue might be different than mine, but I think that, still it's
worth looking at.

Erinc

On Thu, Apr 29, 2010 at 6:21 PM, d...@xx<d...@proxiflex.fr>  wrote:


Thanks, I will try to reproduce the error with this info.

Does Mina should not handle this situation ?

JY

----- Original Message ----- From: "Erinc Arikan"<erincari...@gmail.com>
To:<us...@mina.apache.org>
Sent: Friday, April 30, 2010 12:07 AM
Subject: Re: NullPointerException in ProtocolCodecFilter



I've seen similar errors with my application too, Generally it happens, if

client closes the connection before you write into the session.

If I were you, I'd check if that's the case.

Erinc

On Thu, Apr 29, 2010 at 6:02 PM, d...@xx<d...@proxiflex.fr>  wrote:

One of my customers has very rare exceptions like this and I can't find

any
explanation in my code :

org.apache.mina.filter.codec.ProtocolEncoderException:
java.lang.NullPointerException
at

org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:313)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:805)
at

org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:706)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:46)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:805)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:731)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:498)
at

org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:428)
at

org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:369)
at

fr.proxiflex.axx.server.HTTPReceivedHandler.handleMessage(HTTPReceivedHandler.java:38)
at

org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:232)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:713)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:46)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:793)
at

org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:71)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
at

org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:780)
at

org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:772)
at

org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:714)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at

org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:298)
... 24 more

Anybody have any idea of what it can come from ?
I can give more information if necessary, but the exception seams to be
internal to Mina.

In case, the HTTPReceivedHandler code is :

public class HTTPReceivedHandler implements MessageHandler
{
  private String root ;

   public HTTPReceivedHandler( String root )
   {
  Log.info( "root=" + root ) ;
  this.root = root ;
  }

  @Override
public void handleMessage( IoSession session, Object message ) throws
Exception
  {
  Log.trace( "R" ) ;
  HTTPMessage msg = (HTTPMessage)message ;
  Log.received( msg ) ;
  msg.execute( root ) ;
  session.write( msg ) ;    //<<<<  line 38
  }

}

Thanks

Jean-Yves Linet








--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com






--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com


Reply via email to