[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] how to delay delivery of messages?
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
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.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
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.
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
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.
We're using updateOneway, so the receiver of the message can't really
"reject" a message from xmlblaster.