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

Re: Once and only once delivery



Geoffrey Lowney wrote:
> 
> OK, so I am very new to xmlBlaster (and MOM in general).  I am checking out
> xmlBlaster for a potential project.  I've read the docs online and such, but
> I am having a problem getting part of the behavior I want.  So I have a
> couple of questions, and I am hoping someone has some insight they can give
> me.
> 
> 1. I made two copies of SimpleChat.java.  In one, called SimplePost, I just
> post messages.  In the other, called SimpleGetCallback, I just setup the
> callback and display messages received.  The problem is that the messages
> don't appear to be processed in the order sent.  I am not sure this is a
> problem.  But I wonder if this is the expected/desired behaviour, or if
> there is a way to get the messages to process in the order posted.

With the CORBA driver this can happen, since the callback
is invoked 'oneway'. So it is possible that one
task overtakes another (one thread from a thread pool for each
invocation).
This will be changed in a future release.

The other drivers (RMI, XML-RPC) shouldn't have such a problem.

> 
> 2. I also made a version of SimpleGetCallback called SimpleGet.  This
> program uses "get" instead of a callback to receive and display the
> messages.  I found that I receive messages multiple times.  I tried making
> the messages volatile.  In that case I only receive each message once, but I
> miss some.  I want a behavior where each message is delivered to a client
> once and only once.  I tried pub/sub and point-to-point, and I tried turning
> on and off volatile and durable, but no combination seemed to do what I
> wanted.

Geoffrey,

a non-volatile, 'published' message lies around in the server.
Every get() invocation (form any client) receives this message
again, since a get() does not discard the message.

Pub/Sub delivers the message exactly once to any subscriber,
otherwise it would be a bug.

A volatile message makes only sense with Pub/Sub, since it does
exist only a very short period of time.
If the get() hits the server between processing and deleting
the message, the get would receive the message.
This is no clean behaviour, possibly we should
change this in a new xmlBlaster release.

best regards,

Marcel

> 
> Thanks in advance for any information you can provide.
> 
> Geoffrey A. Lowney
> Senior Software Development Engineer
> Recreational Equipment, Inc.
> Phone 253-395-8164 Fax 253-437-7291
> Pager 206-625-8477 2066258477 at page.metrocall.com
> glowney at rei.com http://www.rei.com/
> In order to draw a limit to thinking, we should have to think both sides of
> this limit.
> -- Ludwig Wittgenstein, Tractatus Logico-Philosophicus

-- 
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org