[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid



On Wed, Oct 23, 2002 at 11:19:03AM -0400, Russell Chan wrote:
>  >I'm using XMLBlaster 0.80.  I'm getting a NPE in
>  >ClientSubscriptions.getSubscriptionByOid...
>  >
>  >
>  >
>  >[Oct 18, 2002 4:44:50 PM ERROR
>  >CbWorker-/node/http:10.0.1.157:3412/client/guest/3] Unexpected
>  >exception: java.lang.NullPointerException
>  >java.lang.NullPointerException
>  >	at
>  >org.xmlBlaster.engine.ClientSubscriptions.getSubscriptionByOid(ClientSubscriptions.java:210)
>  >	at
>  >org.xmlBlaster.engine.ClientSubscriptions.messageErase(ClientSubscriptions.java:285)
>  >	at
>  >org.xmlBlaster.engine.RequestBroker.fireMessageEraseEvent(RequestBroker.java:1669)
>  >	at
>  >org.xmlBlaster.engine.RequestBroker.eraseVolatile(RequestBroker.java:1318)
>  >	at
>  >org.xmlBlaster.engine.queue.MsgQueue.checkForVolatileErase(MsgQueue.java:212)
>  >	at org.xmlBlaster.engine.callback.CbWorker.run(CbWorker.java:61)
>  >	at
>  >EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:728)
>  >	at java.lang.Thread.run(Thread.java:498)
>  >
>  >
>  >All of my subscriptions are XPATH based, rather than OID based.. For
>  >example:
>  >
>  >SubscribeKeyWrapper subscribeKey = new
>  >SubscribeKeyWrapper(
>  >"//service[.=\""+EventQueueConstants.SERVICE_TEMPLATE_PARSE+"\" and "+
>  >                    "../type[.=\""+EventQueueConstants.TYPE_RESPONSE+"\"
>  >and "+
>  >                    "../id[.=\""+ eventQueueId+"\"]]]","XPATH");
>  >
>  >
>  >I'm using primarily volatile messages.  I see the NPE while the sweeper
>  >thread (for volatile messages) appears to be running.
>  >
>  >I'm going to attach a dump of the xmlblaster state.  I *DO* notice that
>  >even during a dump xmlblaster complains about the "Can't determine key
>  >oid" (See the top of the dump).
>  >
>  >I'm obviously doing something wrong here... Insights appreciated :-)
>  >
> If there are NPEs its not you but xmlBlaster which is fishy.
> Can you provide a little demo client reproducing this problem?
> 
> thanks
> 
> Marcel

Here's some more details...

The exception from the latest CVS cut I get is this:

[Oct 23, 2002 11:10:51 AM ERROR CbWorker-/node/http:127.0.0.1:3412/client/test/2] Unexpected exception: java.lang.NullPointerException
java.lang.NullPointerException
        at org.xmlBlaster.engine.ClientSubscriptions.getSubscriptionByOid(ClientSubscriptions.java:210)
        at org.xmlBlaster.engine.ClientSubscriptions.messageErase(ClientSubscriptions.java:285)
        at org.xmlBlaster.engine.RequestBroker.fireMessageEraseEvent(RequestBroker.java:1669)
        at org.xmlBlaster.engine.RequestBroker.eraseVolatile(RequestBroker.java:1318)
        at org.xmlBlaster.engine.queue.MsgQueue.checkForVolatileErase(MsgQueue.java:212)
        at org.xmlBlaster.engine.callback.CbWorker.run(CbWorker.java:61)
        at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:728)
        at java.lang.Thread.run(Thread.java:536)

The first time we get this, it happens under the following circumstances:

1) All clients use XML-RPC protocol
2) Client #1 logs in and subscribes using an XPATH query
3) Client #2 logs in and starts publishing simple messages
4) Client #1 receives messages published by client #2
5) Client #1 is killed
6) xmlBlaster throws the above NullPointer exception when it tries
   to publish to the now non-existent client #2.

For reference, client#2 is publishing messages like this:

<key oid='' contentMime='text/xml'>
	<service>post</service>
	<type>request</type>
	<id>123</id>
</key>
<qos><isVolatile>true</isVolatile><isDurable>false</isDurable></qos>

And client #1 is subscribing like this:

<key oid='' queryType='XPATH'>//service</key>
<qos><duplicateUpdates>false</duplicateUpdates></qos>


Note also that after this event, if I restart client #1, it again
starts receiving messages, but xmlBlaster will then start throwing
out NullPointerExceptions very frequently (same as one above) and
the memory consumption starts growing.

-- 
David Kerry