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

Re: [xmlblaster] Clients receiving other client's messages


you suspect that suddenly the %UNIQUE_SESSION_NAME is mixed?
Are both clients in the same process (with C threads)?

Is it possible that suddenly the %USER is used instead of %UNIQUE_SESSION_NAME?
<session name='%UNIQUE_SESSION_NAME/1' ...

Could you please check the xmlBlaster server log?
(you can also send it directly to my email-address so i can have a look at it).
Which version do you use on client and on server side?

Keep us informed,


Steven Wei wrote:
We have been having an interesting problem with xmlBlaster recently. Clients subscribed to one key oid will receive messages destined to another oid. For instance:

client one subscribes to <key oid='screen_1'/>
client two subscribes to <key oid='screen_2'/>

A message is sent to 'screen_1', but it goes to'screen_2' instead. The message received by client two has the 'screen_1' key, even though it is only subscribed to 'screen_2'. Restarting both clients seems to fix the problem once it occurs.

This is the connect QoS we are using. %USER and %PASSWORD are identical for each client, and %UNIQUE_SESSION_NAME is unique for every client ("session-MACADDRESS").

<securityService type='htpasswd' version='1.0'>
 <![CDATA[ <user>%USER</user> <passwd>%PASSWORD</passwd> ]]>


<session name='%UNIQUE_SESSION_NAME/1'

<queue relating='callback' maxEntries='50000' maxEntriesCache='10000'>
   <callback type='SOCKET'/>

The client subscribe properties are:
# default subscribe properties
wantContent                    = true
multiSubscribe                = false
subscribe/qos/persistent    = false
local                        = false
initialUpdate                = false
updateOneway                = false
notifyOnErase                = true
historyNumUpdates            = 1
historyNewestFirst            = true

The client is using the C xmlBlaster library. I suspect that the problem is related to the persistent session tracking on the server, where a client is inadvertently reconnected to another client's sessions/subscriptions.

Any thoughts?