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

Re: [xmlblaster-devel] Trouble with multiple subscibtions/callbacks

Wolfgang Kleinertz wrote: 
Hi!

I'm writing a program that uses an own callback for each subscibtion.
The problem is, that incomming messages won't be delivered to the
specialized callback. Instead, the default callback (registered while
login) gets the message, although
no subscribtion is running for this callback. Why?

An examples of an addressed message key:
  <key oid='agent-192.168.10.218___FRT1___log' contentMime='text/xml/'
contentMimeExtended='log'>
      <location source='agent-192.168.10.218' driver='FRT1'  />
  </key>

The XPath-query I use to subscribe:
//key[ at contentMimeExtended='log']/location[ at source='agent-192.168.10.218'
and
at driver='FRT1']


The analysis of the problem showed the following:
The returned subscibtionId is:
Subscription-192.168.10.211-null-1014388370206-208054022-1-192.168.10.211-7609-1014388469248-13

An incomming message needs the same id to be dispatched to the right
callback, but they are not the same. (An id of an incomming msg. was
'agent-192.168.10.218___FRT1___log' == oid!!!!)

Thus, if the oid of the key is set to a value, the msg can't be
dispatched via
org.xmlBlaster.client.protocol.xmlBlasterConnection.update(...) to the
right callback. If I don't use a msg-oid, it works well. But that's no
solution, because I need the oid to avoid more than one message per
type.

I think, it's not a feature, it's a bug. Isn't it?! :) 

I don't understand all of it.
On subscribe you recevie a subscription ID (as yours above).
Messages which arrive via update() have for example this QoS:

   <qos> <!-- UpdateQoS -->
      <state>
         OK
      </state>
      <sender>
         Tim
      </sender>
      <subscriptionId>

Subscription-192.168.1.2-null-1014638544858-1364780131-1-192.168.1.2-7609-1014638545563-1
      </subscriptionId>
      <rcvTimestamp millis='1014638547647' nanos='0'>
         2002-02-25 13:02:27.647
      </rcvTimestamp>
      <expiration timeToLive='129599952'/>
   </qos>

They deliver the reason for their arrival in form of a subscriptionId.
This should match to the id you got returned on subscribe().
If not, it is a bug.
But in my tests it runs fine.


regards,

Marcel


--
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org