[email protected]
[Top] [All Lists]

Re: [Mercury] Mercury restarting (was persistence policy)

Subject: Re: [Mercury] Mercury restarting was persistence policy
From: Sanjiva Weerawarana
Date: Mon, 23 Jun 2008 04:59:52 +0530
I ain't no WS-RM expert, but gut instinct states that terminating sequences is a resource optimization thing .. so last message isn't crucial. If the client goes down and comes back up then it may end up starting a new sequence. However, ALL messages sent under the old sequence MUST be delivered somehow. (Subject to things like network failures, destination being gone etc. etc. of course.)

Amila, I think you're putting too much weight on the sequence concept. That's really an internal WS-RM thing that has no end user usage IMO.

One thing we could do is if the system is recovering from a crash, then just terminate sequences that were in-stream.


Jaliya Ekanayake wrote:
Hi David,

I would also like to see a RM implementation, which requests no interactions from the application. However, one of the issues that we could not solve so far is determining the last message.

Say an application needs to send some 10 messages. How can the RM implementation determine when to terminate the sequence? The current solution is that the application informs the RM implementation that this is the last message.

This itself eliminate the possibility of using RM as a switchable module which has no relation to the application. So if we can find a solution to this, we can apply the same for recovering process as well.


----- Original Message ----- From: "David Illsley" <[email protected]>
To: <[email protected]>
Sent: Friday, June 20, 2008 12:05 PM
Subject: Re: [Mercury] Mercury restarting (was persistence policy)

FWIW, my mental model of a robust reliable messaging implementation
allows 'client' restart and message resend without any additional
application work, which I think matches that of Dims, Paul and

To me it's clear that you can write an Axis2 client which operates
within the context of a transaction. When the transaction commits the
message should be stored safely with associated sequence information
and can then be sent. If for some reason that JVM dies and another
starts with access to the same WS-RM persistent store, there is no
reason that it should not at least attempt to cleanly terminate any
sequences still stored by resending unacknowledged messages to the
destination. (In fact, I think not attempting to re-use the sequence
for new messages is probably a good idea).

I do think it's an interesting question about what should happen in a
non-transactional world. Given the standard model of WS-RM, I think
it's reasonable to retransmit unacknowledged messages regardless. If
the application is really looking for all-or-nothing delivery of an
entire set of messages which seems to be what the 5of10 discussion is
about, WS-RM isn't quite enough.


To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

[email protected]----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

Blog: http://sanjiva.weerawarana.org/

To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>