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

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

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


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.