Re: [xmlblaster] Message priority

[Marcel Ruff <ruff at swand.lake.de>]

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

> Hello,
>
> 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
variants.

regards,

Marcel