Re: [xmlblaster-devel] how to delay delivery of messages?

[Michele <laghi at swissinfo.org>]

Hi Brad,

Brad Clements wrote:
> I've checked the archives, and couldn't find much information on this 
> topic.
You'r right, this feature could be interesting for many usecases. 
Unfortunately it is not implemented yet.

> We use xmlblaster for low volume, small size, event notification 
> messages coming from Zope to backend processes running in Python.
>
> Often, xmlblaster delivers these messages before the Zope web 
> transaction has completed, so Zope has not committed changes to the 
> database.
>
> Our backend process starts to work on the message and finds no 
> candidate records in the database, hence it fails.
Could you not delay the publishing until the transaction is committed ?

> I'd like a QoS or something that says "deliver after xx seconds", or if I 
> need to use an absolute time, I can do that too.
>
> Is there some way to do this in xmlblaster?
>
> Basically, I want to schedule messages for future delivery. The "future" 
> isn't very far away, and there wouldn't be more than 3 or 4 of these 
> messages queued up at any given time.
One simple and fast solution would be to implement a mime plugin which 
depending upon your mime type would sleep for a given time. See

http://www.xmlblaster.org/xmlBlaster/doc/requirements/mime.plugin.accessfilter.html

on how to implement such a plugin. Keep however in mind that this blocks 
the dispatcher thread (callback thread) associated to that specific 
session, so meanwhile other messages in the queue will wait.

Of course a better way would be to use a publish filter (see 
http://www.xmlblaster.org/xmlBlaster/doc/requirements/mime.plugin.publishfilter.html)

You would set a client property in the PublishQos containing the delay 
or the exact "activation time". You would then "catch" the message on 
the implementation of this I_PublishPlugin (by returning "NOK"). This 
has the effect that the message is not published. In the plugin you 
would have a scheduler for example Quartz at 
http://www.opensymphony.com/quartz. When the scheduler fires, it would 
publish again the message either under another mimetype or without the 
"activation time" Client property (to avoid loops).

If you go for the second solution we would more than glad if you would 
donate back the code to the community.


Greetings
Michele


> We're using updateOneway, so the receiver of the message can't really 
> "reject" a message from xmlblaster.