Amila, *conceptually*, the fact that *we* are choosing to implement the RM
protocol in the same JVM is not something that should affect the
application. We can implement it in process or with a daemon of some sort.
The app is not in a tight loop sending a set of messages in a sequence.
Let's be real- an application that is sending messages via WS-RM and is
truly crash-resilient, will need to be smarter than a totally dumb app to
not re-send all its old messages .. that's not our problem. If they do
re-send, then we must deliver them twice as Chamikara explained as the
WS-RM message uniqueness criteria is violated. However, an application
(thru user intervention, transaction recovery, or whatever mechanism) that
starts off where it left off somehow needs to be guaranteed that the
messages it has already sent will not need to be resent again.
Basically our job is not to worry about *how* the application figures out
what to re-send or not, but rather to give the assurance to the
application that whatever it has asked us to send WILL be sent.
Don't focus on the sequence concept too much - to me that's a session
established to ensure ordered delivery of messages. If the application
wants to remember which RM session it used to send messages then *it* has
to worry about how it saves that information in a crash-resilient way. A
more common case is that the app is running a workflow and the different
messages are sent in different sequences as the message exchanges as the
workflow progress give the application the assurance it needs that the
other side's moving along as well.
Sanjiva.
Amila Suriarachchi wrote:
On Thu, Jun 19, 2008 at 8:30 PM, Jaliya Ekanayake <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Amila,
Let me add little bit more thoughts.
As you have mentioned, in our current implementations of WS-RM the
RM process runs in the same process space as the application.
So there is no concept such as starting the RM process again after a
crash. It will only happen if the application is recovered and it
sends another message, which is a very passive approach.
The other problem is that in WS-RM the messages are connected to a
sequence(or session). It is not just delivering a single message
from endpoint A to endpoint B, rather delivering a sequence of
messages with some delivery assurance.
With these settings, the recovery is not simple as just starting the
RM process. The application has to have a way to inform the RM
process that it is the same sequence it wants to continue. The
reasons for this requirement are as follows.
In WS-RM we have two types of information to uniquely identify the
messages.
1. Sequence
2. MessageID (+ message number)
In a crash-recovery scenario, non of them is useful in identifying
whether this is a previously crashed sequence or not, because WS-RM
allows multiple messages in a same sequence, and also the message ID
is assigned by the RM implementation to the message (not by the
application itself).
The following is something I thought as a solution to this problem.
Break the RM Process (in one side) into two parts.
1. Part one reside in the same process space as the application and
simply "store" the messages in a persistence storage. It also keeps
checking the storage for response messages.
2. Part two, keeps processing these messages and handle the RM
related logics and the response messages are pushed to the storage.
Are you proposing to use an intermediate layer between Application
Client and Service Client (or Stub)?
Application Client
New intermediate layer
Stub/ Service Client
RM layer.
1. Application Client
Instead on directly calling to Stub it put the messages to a
persistence store and check for responses
2. New Intermediate Layer
This gets messages from persistence storage and Call stub. Here
this layer can work independently. It may have some RM logic to find the
send messages and resume message accordingly. This may be in a different
JVM.
Seems to be a good idea. But here we loss the RM transparency. Since
Application client has to write to the Database.
But most importantly In this way I think it is very easy to implement
the Transactions as well.
thanks,
Amila.
Any thoughts?
Thanks,
Jaliya
----- Original Message -----
*From:* Amila Suriarachchi <mailto:[EMAIL PROTECTED]>
*To:* Sanjiva Weerawarana <mailto:[EMAIL PROTECTED]>
*Cc:* Paul Fremantle <mailto:[EMAIL PROTECTED]> ; Chamikara
Jayalath <mailto:[EMAIL PROTECTED]> ;
[email protected] <mailto:[email protected]>
*Sent:* Thursday, June 19, 2008 10:08 AM
*Subject:* Re: [Mercury] Mercury restarting (was persistence policy)
On Thu, Jun 19, 2008 at 8:01 AM, Sanjiva Weerawarana
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Amila Suriarachchi wrote:
Here there are two cases, 1. Finished sequences (from
Application
client) Here Application client has not messages to
send. So it sends a
special message
2. Non complete sequences Here Application client has
messages.
Currently Mercury requires to send a special message but
can avoid this
requirement and start with the next message.
No. The whole point of *reliable* messaging is that once the
application
has sent the message it can *forget about that message* and
it'll somehow
get delivered (subject to constraints obviously .. best
effort). The
application CANNOT be expected to tell the RM engine "dude,
yeah you know
like those messages I asked you to send? yeah those ones.
please do send
them out when you feel cool about it"!
Your design requires the user to do something which is
totally unnatural in a *reliable* messaging world.
I think here you are comparing WS-RM with other reliable
messaging like JMS, SMTP. I don't have a broad knowledge about
reliable messaging. But this is what I can see.
The other transports send the message to an intermediate node
before sending to the destination. But for WS-RM it persists the
message at the same JVM and do a direct service invocation.
In JMS case when the message goes to JMS Queue it does not
matter whether client crash or not. But for WS-RM once the
client crash RM source also crashed and some one has to re start
that.
In JMS case what happened if the JMS Queue crashed? in this case
some one has to restart it and JMS Queue may recover. Here it
would be easier to start it since it is dedicated to JMS
messages. Here Axis2 Engine is a general purpose one. So there
are some technical problems with that as well.
thanks,
Amila.
Sanjiva.
--
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/
--
Amila Suriarachchi,
WSO2 Inc.
--
Amila Suriarachchi,
WSO2 Inc.
--
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]
