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

Re: [xmlblaster] volatile message problem

Whoops! Forgot some more details...

This occurs running on client protocols socket, and xml-rpc (as I
mentioned before, I don't think this is a client problem).

Args to reproduce the behaviour below are:

java -classpath demo.jar:xmlBlaster.jar:xmlrpc.jar
javaclients.VolatileTest -client.protocol socket -socket.hostname blade
-numTests 1 -numListeners 5


On Wed, 2002-10-30 at 16:17, Russell Chan wrote:
> Hi,
> Here's another volatile bug, which may be related to the earlier one
> that David posted.  Here's the scenario:
> -One publisher publishing messages.  
> -More than three consumers of messages (all listening on the same XPATH)
> -The messages are all volatile, non-durable.
> -This all occurs on the same xmlblaster connection.
> Problem:
> -Not all the subscribers are getting the message, *AND* there's an
> erroneous message sent twice to a subscriber (there should be one each
> in the output below).  The *NUMBER* of messages appears to always be
> correct, but the receivers get messed up.  (The "MessageEater-1" never
> received an update.).
> Here's the output from the attached program which reproduces the error:
> Subscribing using XPath syntax ...
> Subscribe done:MessageEater-0  subcriptionId=__subId:XPATH8
> Subscribe done:MessageEater-1  subcriptionId=__subId:XPATH9
> Subscribe done:MessageEater-2  subcriptionId=__subId:XPATH10
> Publishing ...
> MessageEater-0:Received asynchronous callback-update :published message
> number:0
> Publishing done, returned oid=http_10_0_1_157_3412-1036011675905-8
> MessageEater-2:Received asynchronous callback-update :published message
> number:0
> MessageEater-2:Received asynchronous callback-update :published message
> number:0
> I'm fairly sure that it isn't the client side of the equation causing
> this right now, and it appears to be related to a threading issue in the
> server.
> Having traced through the server as this runs, I have also noticed
> something strange, which I don't quite understand.  When  the one
> publish runs through the server, the server makes two passes at the
> publish, publishing first to (apparently) just one subscriber, and then
> again for the remaining two (which end up being the same subscriber as
> above).
> I'm going to keep digging, but as usual, any help appreciated.
> Russ