Re: [xmlblaster] Deliver-once semantics and synchronous message query
If I understand that page correcly, I have two alternatives: Either a plain GET command on the administrative telnet port, or with the query variables encoded on the same form inside a querySpec tag in the QoS of (for instance) an xmlrpc call to xmlBlaster.get. If the latter is correct, then I suggest mentioning the querySpec tag in the example of all available get QoS on the interface.get requirement page. Done, thanks Marcel -- Marcel Ruff http://www.xmlBlaster.org
Re: [xmlblaster] Deliver-once semantics and synchronous message query
Thanks for the quick answer. Marcel Ruff [EMAIL PROTECTED] wrote: you can access any server side queue (callback-queue, history-queue, subject-queue) with a synchronous call with get(). I'm pleased to hear that. This is described in http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html If I understand that page correcly, I have two alternatives: Either a plain GET command on the administrative telnet port, or with the query variables encoded on the same form inside a querySpec tag in the QoS of (for instance) an xmlrpc call to xmlBlaster.get. If the latter is correct, then I suggest mentioning the querySpec tag in the example of all available get QoS on the interface.get requirement page. Your XmlRpc client would login and subscribe to all interested topics, its callback queue is filled but because you don't establish a callback server they are never delivered. Ah, interesting. I misunderstood the docs on this; I thought it wasn't possible to subscribe without providing a callback. The combination of: 1. interface.subscribe: Messages are asynchronous accessed with the subscribe() method, and 2. Clients have to establish a callback server instance to allow asynchronous callbacks. (same page) led me to believe that subscriptions primarily was a tool to achieve asynchronous communication. Rather, they are primarily for setting up a queue, and the asynchronous callback is optional (which makes more sense imho).
[xmlblaster] Deliver-once semantics and synchronous message query
Hello. I'm just figuring out how to put xmlBlaster to work in a project and I've never used it before, so please excuse what might be a newbie question. The engine.callback requirement mentions a guarantee to deliver messages only once. The thing is that I'd prefer to not use callback mode, but rather only use the synchronous get() method (over xmlrpc) to poll for messages. That way I don't have to set up an xmlrpc server. So can I get deliver-once semantics using synchronous polling too? Thanks.
Re: [xmlblaster] Deliver-once semantics and synchronous message query
Hi Martin, you can access any server side queue (callback-queue, history-queue, subject-queue) with a synchronous call with get(). This is described in http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.qos.queryspec.QueueQuery.html It allows polling - or more elegant - doing a blocking get() until the given timeout happens or the given messages are available and then immediately returns. Your XmlRpc client would login and subscribe to all interested topics, its callback queue is filled but because you don't establish a callback server they are never delivered. Now you can use the above consuming get() to poll for them without ever loosing a message, even if you XmlRpc client is offline for some days, regards Marcel Martin Stjernholm wrote: Hello. I'm just figuring out how to put xmlBlaster to work in a project and I've never used it before, so please excuse what might be a newbie question. The engine.callback requirement mentions a guarantee to deliver messages only once. The thing is that I'd prefer to not use callback mode, but rather only use the synchronous get() method (over xmlrpc) to poll for messages. That way I don't have to set up an xmlrpc server. So can I get deliver-once semantics using synchronous polling too? Thanks. -- Marcel Ruff http://www.xmlBlaster.org
