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

Re: [xmlblaster] Message priority

Bertrand-Raphael.Maquel at ses-astra.com wrote:


I plan to use XML Blaster in an application that requires different kinds
of processing for different message priorities. This is because some
connections to client applications may switch from high bandwidth to low
bandwidth unexpectedly.
So the goal is to send only the most important messages when the bandwidth
is low, store the messages with normal priority and send them later, and
simply forget and delete the messages with the lowest priority.

Do you think I can  use XML Blaster "as is" in such a project, or should I
adapt some classes, or develope a plug-in ?

Hmm, it should be possible:

1. Message updates (msg send from MoM back to clients):
if you do a

java HelloWorld -?

you get the usage, the interesting part is:

Control the callback queue properties:
-cb.queue.maxMsg The maximum allowed number of messages in this queue [1000].
-cb.queue.onOverflow What happens if queue is full. block | deadLetter [deadLetter]
-cb.queue.onFailure Error handling when callback failed [deadLetter]

So you set the callback queue size to say 50000 messages, and generate
dead letters on overflows which you silently ignore (we could add
a DISCARD_SILENTLY option - but it works as is ok).

As higher prio messages are always in front, they are delivered.

So in fact you don't need to adjust anything, the default settings
do what you want - you can use xmlBlaster 'as is'.

2. Publishing messages from clients ==========================

If the publisher has the same band witdh problems this
is not addressed yet, possible solutions if you
need this as well:

a).We could extend the client side message recorder to allow it.

b). Currently the publishing client just blocks until the message is
published to the MoM (you could detect this yourself and react accordingly).
(If you use oneway publish, the client does not block, but
this does not help you).

c) Start an xmlBlaster instance in the publisher client (as a thread),
configure this xmlBlaster node as a cluster master and you
automatically use the update queue which supports what you want.
On the other side the xmlBlaster cluster node #2 subscribes to those
messages (as a slave).
This is a trick, but it should work 'as is'

Please read the requirement docs to learn more about the different