Hello All,
Probably http://svn.apache.org/viewvc?view=rev&revision=762167 is
guilty for the weird NPEs we've started receiving after updating to
the current trunk.
Rolling back to the revision previous to the one in the subject has
solved the problem.
NPE occurs when trying to get attribute from the session. In our
protocol logic if that place in the code is reached, attribute must be
there and session must be not null, this worked for months with no
exceptions.
However, updating to the current trunk (built after April, 6) has
introduced this:
org.apache.mina.filter.codec.ProtocolDecoderException:
java.lang.NullPointerException
at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:234)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:434)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:48)
at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:802)
at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:59)
at org.apache.mina.core.session.IoEvent.run(IoEvent.java:64)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:737)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:729)
at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:667)
at java.lang.Thread.run(Thread.java:619)
It doesn't happen often, probably once a minute under heavy load, but
only on the 2 servers where we've updated MINA. 4 other servers with
older build are running with no such exceptions.
In sessionCreated we suspend read.
In sessionOpened we set the attribute and then resume read.
In sessionClosed attribute is removed.
In the protocol decoder doDecode NPE occurs when trying to get
attribute set in sessionOpened.
It looks like doDecode is called after sessionClosed or sessionClosed
is called in the middle of doDecode from another thread (or doDecode
is called before sessionOpened completes).
We are using OrderedThreadPoolExecutor (as shown in the stacktrace
above), so it should not happen.
No test case, sorry.
--
Best regards,
Serge
