Re: [xmlblaster] multiple client message processing

[Michele Laghi <laghi at swissinfo.org>]

Hi Joanne,
I am afraid you have to forget the synchronous approach with get() since 
there is no way to perform a get() and an erase() operation in the same 
transaction (between a get and an erase another client could process the 
same message again).

This was one of the reasons why we designed a generic plugin approach 
(the message distributor plugin) which should be flexible enough to 
satisfy a broad range of needs.

A first implementation of that plugin was the ConsumableQueuePlugin 
which I believe is exactly what you need here.

As you already noticed it is unfinished. In particular it needs 
extensive testing to be used on a productional level. There is however 
already some simple testing available.

I will try to complete the requirement tomorrow morning. Meanwhile you 
could have a look at that test located under 
testsuite/src/java/org/xmlBlaster/test/distributor/TestConsumableQueue.java

for an example on its usage. Of course if you are going to use it we 
would be more than happy if you could provide us with the tests which 
are still missing.

Saluti
Michele


Joanne wrote:
> I'm currently evaluating xmlblaster as a possible MOM alternative to our current system which uses jabber. I'm most interested in using xmlblaster's synchronous get() method to process messages among several identical clients. The goal is to have n number of clients (all performing the same type of message processing), and querying for the same type of messages from xmlblaster. Simply using get() from each client is not enough, because several clients would receive the same message, but I only want the message to be processed by one of them. The only way I've found to guarantee that only one of the clients (i.e. the first one that get()s it) processes a particular message, is by issuing an erase() on that message so that no other clients will have the chance. But this approach doesn't seem right -- I'm thinking there must be some kind of negative performance impact somewhere -- and it simply doesn't seem efficient. It also seems probable race condition may exist using get()
!
>  & erase().
>
> According to the documentation, key & qos tags and  meta info cannot be changed once a message is published, not without erasing it first and re-publishing it. So is there some kind of flag or parameter that can be queried to know whether a message has already been viewed a client? I'm looking for the equivalent of a 'read' tag so when clients issue get()s, they can specifically request messages that haven't been 'read' or handled by anyone else. 
>
> For example, let's say I have a total of 3 xmlblaster clients, A, B, C. Client A publishes a message to xmlblaster. Clients B & C are responsible for processing the message, but only one of them needs to do it. They are only supposed to act on messages that have not been processed. Let's say B get()s the message first and somehow marks it for processing. C should never even see the message because it's only querying for non-processed msgs. After Client B finishes handling the message, it will publish a PTP message to client A as an acknowledgement that processing is complete. Client A would then be responsible for erasing the message from the server. Can anyone offer alternate suggestions on how to accomplish this kind of architecture using xmlblaster? 
>
> I was thinking that a better alternative would be to forget sychronous get() access and use something like the msgdistributor.plugin (consumablequeueplugin) instead, because it could handle load balancing and guarantee message delivery to only one of n clients (which is exactly what I want). Unfortunately, I haven't figured out how to invoke/configure it yet.


--
Michele Laghi
mailto:laghi at swissinfo.org
tel. +46 8 7492952 / mob. +46 70 4103964
http://eclettic.tripod.com
http://www.xmlBlaster.org