What I tried to explain is the following:
RM Specification considers sequence establishment and termination as core
concepts.
If we implement RM endpoints as passive entities (something that will only
work when invoked by some other entity) then there is no way (I could think
of) that implementation send a LastMessage information unless the
application instruct it to do so.
If we consider the RM endpoints as separate processes, then they can send
the LastMessage after some wait period and always start a new sequence if
there are more messages to be sent.
IMHO the problem that we are discussing is caused by the following
inconsistencies in our expectations
1. The WS-RX spec includes almost all the reliable messaging features, which
are typical in other messaging implementations
2. The idea "drop a module and it should just work" expects the application
code to have zero modification to use RM.
3. The handler based module implementation of RM will be a passive entity
(at least for the client side)
I don't see a way to get all these requirements satisfied at once.
Any thoughts?
Thanks,
Jaliya
----- Original Message -----
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: "Jaliya Ekanayake" <[EMAIL PROTECTED]>
Cc: "David Illsley" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Sunday, June 22, 2008 7:29 PM
Subject: Re: [Mercury] Mercury restarting (was persistence policy)
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.
Sanjiva.
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.
Thanks,
Jaliya
----- 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
Sanjiva.
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.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
