[xmlblaster] Another volatile message bug
Ok, now that the NPE problems have been resolved, we've run into another problem, probably related, where volatile messages are not deleted properly. What happens is xmlBlaster seems to get itself confused and not delete a volatile message when it should. After it gets into this state, it will never delete the message and continue to re-deliver it to each new subscriber/login that it applies to. It will do this forever as far as I can tell - ie: it will never expire the message either. Attached are test scripts to reproduce the problem. Protocol is XML-RPC, BTW. To reproduce, run the scripts in the following order: 1) perl server2.pl (in xterm #1) 2) perl serverlogin.pl (in xterm #2) 3) perl testpub.pl (in xterm #2) (server2.pl will spit out 'GOT UPDATE' to note that it got the published message via callback) 4) kill server2.pl (ctrl-c in xterm #1) 5) perl testpub.pl (in xterm #2) (xmlblaster will kill server2's login because it can no longer reach the callback server) 6) perl server2.pl (in xterm #1) 7) perl serverlogin.pl (in xterm #1) Note that server2.pl now says 'GOT UPDATE' again. It should not receive a callback at this point - the message was volatile so it should have been deleted immediately. Continued restarting of server2/serverlogin will cause the same message to get continually posted again and again when it should receive nothing at all. -- David Kerry testpub.pl Description: Perl program server2.pl Description: Perl program serverlogin.pl Description: Perl program
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
David Kerry wrote: On Fri, Oct 25, 2002 at 04:42:29PM +0200, Marcel Ruff wrote: Ok, i have comited it to xmlBlaster/demo/perl/xmlrpc as is (i've only added some credits). Volunteers may extend the examples :-) thanks for your contribution Marcel PS: Has the NPE disappeared? Actually, the NPEs went away for the test case, but we encountered more NPEs when we pointed our development code against it. However, I noticed there were some more changes this morning, so I did another update and now with the latest changes, it no longer seems to have any problems. Thank you! Yes, i had a dream tonight, and adding that fix solved it finally :-) Marcel
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
On Fri, Oct 25, 2002 at 04:42:29PM +0200, Marcel Ruff wrote: > Ok, i have comited it to xmlBlaster/demo/perl/xmlrpc as is (i've only > added some credits). > > Volunteers may extend the examples :-) > > thanks for your contribution > > Marcel > > PS: Has the NPE disappeared? Actually, the NPEs went away for the test case, but we encountered more NPEs when we pointed our development code against it. However, I noticed there were some more changes this morning, so I did another update and now with the latest changes, it no longer seems to have any problems. Thank you! -- David Kerry
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
David Kerry wrote: On Fri, Oct 25, 2002 at 01:29:11PM +0200, Marcel Ruff wrote: David Kerry wrote: >Alright - I've attached two scripts that reproduce the problem >right away. > >Just run the server script, then follow up with the test.pl script. >No other work needed - it will cause xmlBlaster to NPE right away. > > > Thanks - this way it was easy to locate the problem. I have fixed it and it is available via cvs on the main branch. Sorry about the inconvenience. Your Perl code is cool, may i add it to the xmlBlaster/demo directory to Cyrilles examples (after adding credits to you)? best regards, Marcel Certainly. I wouldn't quite call those 'good' examples though... ;-) It would probably be better to rewrite them to use the xmlBlaster perl modules instead though (as the xmlBlasterClient.pl example does). Ok, i have comited it to xmlBlaster/demo/perl/xmlrpc as is (i've only added some credits). Volunteers may extend the examples :-) thanks for your contribution Marcel PS: Has the NPE disappeared?
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
On Fri, Oct 25, 2002 at 01:29:11PM +0200, Marcel Ruff wrote: > David Kerry wrote: > >Alright - I've attached two scripts that reproduce the problem > >right away. > > > >Just run the server script, then follow up with the test.pl script. > >No other work needed - it will cause xmlBlaster to NPE right away. > > > > > > > Thanks - this way it was easy to locate the problem. > I have fixed it and it is available via cvs on the main branch. > Sorry about the inconvenience. > > Your Perl code is cool, may i add it to the xmlBlaster/demo directory to > Cyrilles > examples (after adding credits to you)? > > best regards, > > Marcel Certainly. I wouldn't quite call those 'good' examples though... ;-) It would probably be better to rewrite them to use the xmlBlaster perl modules instead though (as the xmlBlasterClient.pl example does). -- David Kerry
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
David Kerry wrote: On Thu, Oct 24, 2002 at 01:36:43AM -0400, David Kerry wrote: Ok - I've attached a short perl client for client #2 in this case. I don't have a simple client #1 yet. However, it should be trivial to whip one up - it only has to login, subscribe, and listen for callbacks and nothing more. I'll try to make one in perl tomorrow if I have a chance. -- David Kerry Alright - I've attached two scripts that reproduce the problem right away. Just run the server script, then follow up with the test.pl script. No other work needed - it will cause xmlBlaster to NPE right away. Thanks - this way it was easy to locate the problem. I have fixed it and it is available via cvs on the main branch. Sorry about the inconvenience. Your Perl code is cool, may i add it to the xmlBlaster/demo directory to Cyrilles examples (after adding credits to you)? best regards, Marcel
[xmlblaster] Re: logout blocking
> I am now integrating the new >XmlBlaster into instant news, and a few problems have poped up. Here is >one of them. When trying to disconnect a client connection (in same VM >as server if that matters) the stuff just hangs: > >"ScannerThread" daemon prio=1 tid=0x0x8582ad8 nid=0x6cb in Object.wait() [4dc33000..4dc34840] >at java.lang.Object.wait(Native Method) >- waiting on <0x46bcd3e8> (a org.jacorb.orb.connection.ReplyInputStream) >at java.lang.Object.wait(Object.java:426) >at org.jacorb.orb.connection.ReplyInputStream.result(ReplyInputStream.java:142) >- locked <0x46bcd3e8> (a org.jacorb.orb.connection.ReplyInputStream) >at org.jacorb.orb.Delegate.invoke(Delegate.java:779) >at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457) >at org.xmlBlaster.protocol.corba.authenticateIdl._AuthServerStub.disconnect(_AuthServerStub.java:130) >at org.xmlBlaster.client.protocol.corba.CorbaConnection.disconnect(CorbaConnection.java:531) >at org.xmlBlaster.client.protocol.XmlBlasterConnection.disconnect(XmlBlasterConnection.java:1176) >- locked <0x466f5558> (a org.xmlBlaster.client.protocol.XmlBlasterConnection) >at org.xmlBlaster.client.protocol.XmlBlasterConnection.disconnect(XmlBlasterConnection.java:1101) >at org.backsource.in.blaster.BlasterFactory$BlasterSubscriber.logout(BlasterFactory.java:179) > >Is there any way to sort of force a closedown? > It seems you client blocks on the disconnect invocation because there is no response coming back. 1 .JacORB seems to be in a deadlock - or - 2. xmlBlaster does not respond and your JacOrb client waits forever. The IDL declaration is: void disconnect(in string sessionId, in serverIdl::XmlType qos) raises (serverIdl::XmlBlasterException); So the client can only expect an XmlBlasterException but never a return value. If it continues to be a problem change the IDL to oneway void disconnect(in string sessionId, in serverIdl::XmlType qos); -> oneway and without an exception. Please report to us any progress with this issue. What does the server side logging say? Do you have a simple example for me to reproduce the problem? thanks, Marcel > >//Peter > >
Re: [xmlblaster] NPE in ClientSubscriptions.getSubscriptionByOid
David Kerry wrote: >On Thu, Oct 24, 2002 at 01:36:43AM -0400, David Kerry wrote: > > > >>Ok - I've attached a short perl client for client #2 in this case. >>I don't have a simple client #1 yet. However, it should be trivial >>to whip one up - it only has to login, subscribe, and listen for >>callbacks and nothing more. I'll try to make one in perl tomorrow >>if I have a chance. >> >>-- >>David Kerry >> >> > > >Alright - I've attached two scripts that reproduce the problem >right away. > >Just run the server script, then follow up with the test.pl script. >No other work needed - it will cause xmlBlaster to NPE right away. > > > Thanks - this way it was easy to locate the problem. I have fixed it and it is available via cvs on the main branch. Sorry about the inconvenience. Your Perl code is cool, may i add it to the xmlBlaster/demo directory to Cyrilles examples (after adding credits to you)? best regards, Marcel
