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 Russ 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 > >
