dev@grizzly.java.net

Re: NullPointerException problem on Linux?

From: Minoru Nitta <minoru.nitta_at_jp.fujitsu.com>
Date: Tue, 26 Jan 2010 19:28:07 +0900

Hi Alexey,



There is one point that differs from the sample program.
I used DefaultThreadPool, but I specified ArrayBlockingQueue
as a worker queue.

I tested a stress test and occurred NullPointerException. Before
that, RejectedExecutionException occurred at DefaultThreadPool.execute()
method. So I think this might be the reason why NullPointerException
occurred. I think I should use default queue (LinkedTransferQueue) or
increase the size of the ArrayBlockingQueue.


Minoru


> Hi Alexey,
>
>
> Thank you for your interest. I attached the test program.
> Actually it is not the one which caused NullPointerException
> (I simplified), but I think it can help you.
>
> Minoru
>
> > Hi Minoru,
> >
> > can you pls. share your client side code, which uses Cacheable
> > connections?
> >
> > Thanks.
> >
> > WBR,
> > Alexey.
> >
> > On Jan 21, 2010, at 2:47 , Minoru Nitta wrote:
> >
> > > Hi all,
> > >
> > >
> > > I encountered a strange problem. I am using grizzly 1.9.18-i and
> > > running it
> > > on RHEL4 with JDK5. I exexuted a stress test and found out that
> > > NullPointerException
> > > occurred in Grizzly.
> > >
> > > java.lang.NullPointerException
> > > at com.sun.grizzly.NIOContext.configureOpType(NIOContext.java:431)
> > > at
> > > com
> > > .sun
> > > .grizzly
> > > .connectioncache
> > > .client
> > > .CacheableConnectorHandler
> > > .notifyCallbackHandlerPseudoConnect(CacheableConnectorHandler.java:
> > > 221)
> > > at
> > > com
> > > .sun
> > > .grizzly
> > > .connectioncache
> > > .client
> > > .CacheableConnectorHandler.doConnect(CacheableConnectorHandler.java:
> > > 168)
> > > at
> > > com
> > > .sun
> > > .grizzly
> > > .connectioncache
> > > .client
> > > .CacheableConnectorHandler.connect(CacheableConnectorHandler.java:116)
> > >
> > >
> > > I understood that key argument to NIOContext.configureOpType was null.
> > > I executed the test with no -ea option (to java command), so
> > > assertion at
> > > CacheableConnectorHandler.notifyCallbackHandlerPseudoConnect was not
> > > executed.
> > > I checked and foud out that
> > > CacheableConnectorHandler.notifyCallbackHandlerPseudoConnect
> > > was modified because of spinning problem on Linux.
> > >
> > > So, should I run the test with -ea option or is this another
> > > spinning problem of
> > > Linux?
> > >
> > >
> > > Minoru Nitta
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >