I'll do it now, however it might take a time to get mina compiled from
source, I didn't do that before.

Ok, I did it, but it didn't help :-(
At least, this is not the same NPE :)

It was used in a .war file with the following web.xml:
When I deployed the war file to a glassfish instance it yielded the
following logs:


14:55:55.469 [pool-1-thread-4] DEBUG test - Before connect...
14:55:55.484 [pool-1-thread-4] DEBUG test - After connect...
14:55:55.484 [pool-1-thread-4] DEBUG test - Before await...
14:55:56.422 [NioSocketConnector-1] WARN
o.a.m.util.DefaultExceptionMonitor - Unexpected exception.
java.lang.NullPointerException
        at 
java.util.concurrent.ConcurrentLinkedQueue.offer(ConcurrentLinkedQueue.java:190)
        at 
org.apache.mina.core.polling.AbstractPollingIoConnector.processConnections(AbstractPollingIoConnector.java:440)
        at 
org.apache.mina.core.polling.AbstractPollingIoConnector.access$500(AbstractPollingIoConnector.java:64)
        at 
org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:476)
        at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)


I used the current trunk version of MINA with your patch.

>From the log I guess that in AbstractPollingIoConnector the following
line fails:

            } finally {
                if (!success) {
                    // The connection failed, we have to cancel it.
                    cancelQueue.offer(connectionRequest);  // <-----
This line fails with NPE
                }
            }

It might mean that it is possible that in some situations the
cancelQueue might not have been initialized before the offer statement
but that's not the case here. But according to the javadoc:
The problem is that we don't check the connectionRequest higher in the code :

   private int processConnections(Iterator<H> handlers) {
       int nHandles = 0;
// Loop on each connection request
       while (handlers.hasNext()) {
           H handle = handlers.next();
           handlers.remove();

ConnectionRequest connectionRequest = getConnectionRequest(handle); // Here, we should do that :
           if ( connectionRequest == null) {
               continue;
           }

Without the check, as the getConnectionRequest() method can return null for the very same reason than the previously fixed accept() method, you will have a NPE.

I have committed a patch for this case. Can you run another test ?

(I'm currently installing glassfish, but it will take a bit to have it up and running)

Thanks !

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org


Reply via email to