On Thu, Jun 19, 2008 at 8:30 PM, Jaliya Ekanayake <[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 <[EMAIL PROTECTED]>
> *To:* Sanjiva Weerawarana <[EMAIL PROTECTED]>
> *Cc:* Paul Fremantle <[EMAIL PROTECTED]> ; Chamikara Jayalath<[EMAIL
> PROTECTED]>;
> [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]> 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.
