[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Publish and Subscribe question
Brett Palmer wrote:
> This is a followup on some of my previous questions - Everything has worked
> wonderfully so far, I just need some clarification on publishing and
> subscribing clients.
> I have been able to publish XML documents via the xmlKey and query on the
> document with an XPath expression. I am using derivatives of the
> org.xmlBlaster.client.feeder.PublishFile and
> ..client.reader.SubscribeMessage client programs. Let's call them MyPublish
> and MySubscribe respectively.
> 1. Does client order matter?
> For example, I get a "null" pointer exception if I first run the MyPublish
> the client followed by the MySubscribe client. The exception occurs in the
> RequestBroker.subscribeToOid method because the xmlKey object is null.
> If I run MySubscribe first followed by the MyPublish, the XML document is
> successfully passed to the subscribing client. I was under the impression
> that the messages were persistent with xmlBlaster, so the order in which
> clients interacted didn't matter. The following are the commandline options
> I was using - perhaps I have the Qos options incorrect.
> First: jaco MyPublish -k MyXmlFile.xml -content " "
> Second: jaco MySubscribe -xpath "//[ at oid=\"410\"]"
> If I restart the xmlBlaster server and run the clients in reverse order
> (i.e. MySubscribe and then MyPublish) I don't get the null pointer exception
> and the client receives the XML document via the xmlKey parameter.
I can't reproduce it, could you please send the code & example?
Are you using the latest cvs code, or a release?
( Don't you need to add the 'key' as here?: //key[ at oid='410'])
> 2. How can I publish multiple XML documents from the same client?
> Another problem occurs after I start MySubscribe client and try to send
> multiple XML files using the MyPublish client. MySubscribe client receives
> the first XML message fine, but subsequent messages are not received by the
> client even when the XPath is still valid. Shouldn't xmlBlaster notify the
> client when a new message is received by another publisher?
Shure, if the client has subscribed on this.
If following messages have the same key oid, and the content has not
xmlBlaster won't notify the clients (to save bandwidth).
If you want to update identical messages, use the qos to enforce it:
<forceUpdate /> <!-- An update is forced even when the content
and meta data didn't change -->
<!-- Default is that identical published
messages aren't sent to clients again -->
Check xmlBlaster/src/dtd/XmlQoS.xml for examples.
thanks for bug reporting,
ruff at swand.lake.de