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. Any thoughts? Thanks, Jaliya ----- Original Message ----- From: Amila Suriarachchi To: Sanjiva Weerawarana Cc: Paul Fremantle ; Chamikara Jayalath ; [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.
