Amila I don't see why the Mercury module cannot automatically check when it starts up if there are unfinished sequences. That is Chamikara's option 2.
Paul On Wed, Jun 18, 2008 at 5:47 AM, Amila Suriarachchi <[EMAIL PROTECTED]> wrote: > hi all, > > On Tue, Jun 17, 2008 at 8:35 PM, Chamikara Jayalath <[EMAIL PROTECTED]> > wrote: >> >> Amila, Paul, >> >> I don't think I said that application client should have any logic to >> manage recovery. I simply said that one of following two has to be done to >> manage recovery in the client side. > > yes. I also has not mentioned you told such a thing. Here is what I have > said > > "Actually I had a chat with Chamikara regarding this and he told that > sandesha2 also can not > automatically restart." > > From your answer what I can get this that Sandesha2(currently) does not > support automatic recovery as Paul has mentioned. And that is what exactly > you told me and I have mention here. > >> >> >> 1. There should be a permanent RM agent running in the client side, which >> manages recovery. >> 2. RM client should check for crashed sequences whenever it is invoked in >> the client side, if it find any they should be resumed. > > As I understood what you are saying here is that An independent Agent has to > invoke the RM instead of Application. Then what is the difference? What you > are basically saying is that put that logic to an agent instead of > Application. > > > This is the use case I am thinking. Can you explain how it is achieved with > this method. > 1. Application client start a sequence with 10 messages (want to send) and > then hand over them to RM. The machine crashes after sending 5 messages. Now > This sequence should be restarted to send the remaining 5 messages and > terminate the sequence > > 2. Application client start sequence with 100 messages (want to send) and > then machine crashes when it has only handed over 25 messages and RM has > only send 10 messages. Now this sequence should be restarted so that > Application should be able to send 26 to 100 to RM and RM should complete > the sequence. > > if you take the second scenario how Application client knows how much > messages it has hand over to RM if the application crashes at the middle? > IMHO this is some thing to we have to think with the "end to end argument". > Anyway application client has to play some role when handling unreliability. > > thanks, > Amila. > >> >> >> In both cases work should be done by the RM client transparently, not by >> the application client. >> >> Chamikara >> >> >> On Tue, Jun 17, 2008 at 10:42 AM, Amila Suriarachchi >> <[EMAIL PROTECTED]> wrote: >>> >>> >>> On Tue, Jun 17, 2008 at 7:09 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote: >>>> >>>> Amila >>>> >>>> The Mercury design is wrong. >>>> >>>> The application client should not be responsible for understanding if >>>> the system needs to restart. There isn't a single successful messaging >>>> or transaction system in the world that requires the application to >>>> incorporate logic to handle recovery. Sandesha2 manages automatic >>>> recovery and so should Mercury. >>> >>> Here the question is that when a client dies. (i.e. system crashed) how >>> it automatically restart? >>> Actually I had a chat with Chamikara regarding this and he told that >>> sandesha2 also can not >>> automatically restart. >>> Chamikara could you please comment on this? >>> >>> thanks, >>> Amila. >>>> >>>> >>>> Paul >>>> >>>> On Tue, Jun 17, 2008 at 2:36 PM, Amila Suriarachchi >>>> <[EMAIL PROTECTED]> wrote: >>>> > +1 to add a policy to declare whether a service supports Persistence >>>> > or not. >>>> > >>>> > IMO if RM provides persistence then it should happen in both client >>>> > and >>>> > server side. >>>> > But at the client side Application layer has to do some part as well. >>>> > In Mercury if a client dies when sending a sequence it can be >>>> > restarted by >>>> > sending a message by setting a property called MercuryResumeSequence >>>> > to >>>> > true. >>>> > But in this case Application client have to check how many messages it >>>> > had >>>> > send to RM either by keeping a track of messages or by examining the >>>> > Mercury >>>> > data base store. >>>> > >>>> > thanks, >>>> > Amila. >>>> > >>>> > On Tue, Jun 17, 2008 at 6:50 AM, Jaliya Ekanayake >>>> > <[EMAIL PROTECTED]> >>>> > wrote: >>>> >> >>>> >> Hi Paul, >>>> >> >>>> >> I agree with the two scenarios you mentioned. >>>> >> So, if the majority of the use cases for RM are of the above type >>>> >> with >>>> >> long running communications, then we should stick to the persisted >>>> >> reliability in every usecase. >>>> >> Otherwise, I think we'd better keep the client side free from the >>>> >> mandatory database integration. >>>> >> >>>> >> Thanks, >>>> >> Jaliya >>>> >> >>>> >> >>>> >> ----- Original Message ----- From: "Paul Fremantle" >>>> >> <[EMAIL PROTECTED]> >>>> >> To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> >>>> >> Cc: <[email protected]> >>>> >> Sent: Monday, June 16, 2008 1:05 PM >>>> >> Subject: Re: Policy or other extensions to indicate persistent >>>> >> messaging >>>> >> >>>> >> >>>> >>> Jaliya >>>> >>> >>>> >>> I agree that it is the responsibility of the client. But I'm worried >>>> >>> about two scenarios. >>>> >>> >>>> >>> 1) The client crashes and restarts - the server has missing messages >>>> >>> and without them it cannot deliver the later messages that it has. >>>> >>> 2) The client crashes and restarts - the server has responses >>>> >>> stored, >>>> >>> ready to send, but the client has lost the sequence state and cannot >>>> >>> accept the stored messages. >>>> >>> >>>> >>> I still think that there is a requirement to ENSURE that a >>>> >>> particular >>>> >>> communication is completely reliable. >>>> >>> >>>> >>> Paul >>>> >>> >>>> >>> On Mon, Jun 16, 2008 at 5:54 PM, Jaliya Ekanayake >>>> >>> <[EMAIL PROTECTED]> >>>> >>> wrote: >>>> >>>> >>>> >>>> Hi Paul, >>>> >>>> >>>> >>>> Please see my comments below. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jaliya >>>> >>>> ----- Original Message ----- From: "Paul Fremantle" >>>> >>>> <[EMAIL PROTECTED]> >>>> >>>> To: "Jaliya Ekanayake" <[EMAIL PROTECTED]> >>>> >>>> Sent: Monday, June 16, 2008 11:40 AM >>>> >>>> Subject: Re: Policy or other extensions to indicate persistent >>>> >>>> messaging >>>> >>>> >>>> >>>> >>>> >>>>> Jaliya >>>> >>>>> >>>> >>>>>> My idea is that the persistence is a feature that the admin can >>>> >>>>>> turn >>>> >>>>>> on >>>> >>>>>> or >>>> >>>>>> off per service. >>>> >>>>> >>>> >>>>> So I agree that it is a good feature to turn it on and off per >>>> >>>>> service, and that we support today. So for this model, what I am >>>> >>>>> proposing adding is the ability for the server to advertize that >>>> >>>>> it >>>> >>>>> supports that. >>>> >>>>> >>>> >>>>>> If it is to be per sequence, I think it will over >>>> >>>>>> complicate the handshakes. >>>> >>>>> >>>> >>>>> It will *complicate* the handshakes :) I agree. I think to say it >>>> >>>>> over-complicates the handshake is a subjective idea. >>>> >>>>> >>>> >>>> I agree. >>>> >>>> >>>> >>>>>> Also, Sandesha should not impose restrictions to the clients >>>> >>>>>> based on >>>> >>>>>> their >>>> >>>>>> persistence settings. >>>> >>>>> >>>> >>>>> I don't agree. WSRM imposes plenty of restrictions on the client >>>> >>>>> and >>>> >>>>> server. It is perfectly possible for a server to refuse to >>>> >>>>> communicate >>>> >>>>> with a client that does not support RM. With WSRM 1.1 It is >>>> >>>>> possible >>>> >>>>> for clients to demand that the server creates an association >>>> >>>>> between >>>> >>>>> the sequence and a security session. >>>> >>>>> >>>> >>>>> If the server supports persistence but the client doesn't, then >>>> >>>>> there >>>> >>>>> is no overall guarantee of reliability. So I believe that it ought >>>> >>>>> to >>>> >>>>> be *possible* for a server to send CreateSequenceRefused if it >>>> >>>>> *requires* persistence and the client cannot provide it. Of course >>>> >>>>> that should be configured by the server. Similarly the client >>>> >>>>> should >>>> >>>>> be able to demand (like a mustUnderstand) that the server provides >>>> >>>>> a >>>> >>>>> persistent capability. >>>> >>>>> >>>> >>>>> Why do I want this? Almost every customer I talk to says that WSRM >>>> >>>>> without persistence is basically pointless. >>>> >>>> >>>> >>>> I totally agree with this. Without persistance, I can almost trust >>>> >>>> TCP >>>> >>>> for >>>> >>>> the reliability. (not for the multi-transport multi-hop cases) >>>> >>>> So we need persistance for *real* use cases. >>>> >>>> >>>> >>>> The blogging from people >>>> >>>>> >>>> >>>>> who believe that WSRM should not support persistence has - in my >>>> >>>>> view >>>> >>>>> - been very harmful to the adoption of the spec. Now the normal >>>> >>>>> argument is that "you can support persistence if you need it". But >>>> >>>>> frankly, that is a weak argument, because in a real distributed >>>> >>>>> SOA >>>> >>>>> you cannot (at the moment) know if there is persistence involved, >>>> >>>>> except maybe by phoning up the sysadmin at the other end. So if >>>> >>>>> you >>>> >>>>> require proper persistent reliability then you need a way of >>>> >>>>> agreeing >>>> >>>>> between both parties that it exists. Now WSRM has the perfect >>>> >>>>> model >>>> >>>>> for this negotiation - the CreateSequence/CSResponse. This ability >>>> >>>>> to >>>> >>>>> negotiate details is perfect for this, and I don't see any problem >>>> >>>>> extending it to support this. >>>> >>>>> >>>> >>>> >>>> >>>> I agree that the Client should be able to request persistence from >>>> >>>> a >>>> >>>> Service, but I still don' t understand why we need the server to >>>> >>>> reject >>>> >>>> a >>>> >>>> client if it does not support persistence. >>>> >>>> Here is a scenario. >>>> >>>> >>>> >>>> Say we have two companies A and B that perform some communications >>>> >>>> over >>>> >>>> snail mail. >>>> >>>> All the mails received by the company B first go through its mail >>>> >>>> processing >>>> >>>> system (MPS) which keeps information on all the mails received, and >>>> >>>> also >>>> >>>> keeps a copy of them. >>>> >>>> All the mails sent by the company B also go through the same MPS. >>>> >>>> >>>> >>>> Company A is not that sophisticated in its operations. They don't >>>> >>>> simply >>>> >>>> have a system as above. >>>> >>>> >>>> >>>> Now consider the communications that could happen. >>>> >>>> >>>> >>>> 1. A sends a mail to B >>>> >>>> If this reach B, things are fine. >>>> >>>> If this does not reach B then it is a problem of A. A should keep a >>>> >>>> copy >>>> >>>> so >>>> >>>> that it can send it again. >>>> >>>> >>>> >>>> >>>> >>>> 2. B sends a mail to A as a response to A's request >>>> >>>> If this reach A and processed by A things are fine >>>> >>>> If this reach A but not processed by A, then B can send it again. >>>> >>>> (up to >>>> >>>> some number of times) >>>> >>>> If this does not reach A, B can still send it again. >>>> >>>> >>>> >>>> 3. B needs to send a mail to A requesting something. (Now A is the >>>> >>>> service >>>> >>>> provider) >>>> >>>> In this case B can request that A provides the necessary >>>> >>>> reliability to >>>> >>>> its >>>> >>>> requests. >>>> >>>> If A does not support it, B should not proceed. >>>> >>>> >>>> >>>> Therefore, IMO the client does not need to have a real persistence >>>> >>>> to >>>> >>>> use a >>>> >>>> service offered with persisted reliability, but it can request this >>>> >>>> feature >>>> >>>> from the service. >>>> >>>> >>>> >>>> Let me know your thoughts. probably I have missed some use case. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Jaliya >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Say, the server supports persistance. In that case, any request >>>> >>>> sent by >>>> >>>> the >>>> >>>> client is guranteed to be served. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Paul >>>> >>>>> >>>> >>>>> , but we can advertise that we have persistence for this >>>> >>>>>> >>>> >>>>>> service. >>>> >>>>> >>>> >>>>> >>>> >>>>>> >>>> >>>>>> Thanks, >>>> >>>>>> Jaliya >>>> >>>>>> >>>> >>>>>> ----- Original Message ----- From: "Paul Fremantle" >>>> >>>>>> <[EMAIL PROTECTED]> >>>> >>>>>> To: "Danushka Menikkumbura" <[EMAIL PROTECTED]> >>>> >>>>>> Cc: <[email protected]> >>>> >>>>>> Sent: Monday, June 16, 2008 8:12 AM >>>> >>>>>> Subject: Re: Policy or other extensions to indicate persistent >>>> >>>>>> messaging >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> Danushka >>>> >>>>>>> >>>> >>>>>>> I'm not clear I understand your point. >>>> >>>>>>> >>>> >>>>>>> Firstly, I was just using AMQP as an example - I didn't mean >>>> >>>>>>> that we >>>> >>>>>>> wanted to be exactly the same as AMQP or do anything with AMQP. >>>> >>>>>>> >>>> >>>>>>> So firstly, in general, I don't believe that Sandesha2 can >>>> >>>>>>> modify the >>>> >>>>>>> persistence on a sequence by sequence basis - either it is on >>>> >>>>>>> for a >>>> >>>>>>> service or off. However, logically the sequence *is* the level >>>> >>>>>>> at >>>> >>>>>>> which persistence can be defined. So these are the options I >>>> >>>>>>> see: >>>> >>>>>>> >>>> >>>>>>> * The server has persistence set permanently on for a service. >>>> >>>>>>> It >>>> >>>>>>> does >>>> >>>>>>> not demand persistence from the client. It publishes a policy >>>> >>>>>>> saying >>>> >>>>>>> persistence is optional for the client. It accepts any sequence >>>> >>>>>>> creation, and persistently stores messages. If the client "asks >>>> >>>>>>> for >>>> >>>>>>> persistence" during the create sequence, then it says "yes I'm >>>> >>>>>>> persistent in reply" (by some yet to be determined mechanisms). >>>> >>>>>>> This >>>> >>>>>>> is how we operate today, except with the addition of the policy >>>> >>>>>>> and >>>> >>>>>>> the optional information passing during create sequence. >>>> >>>>>>> >>>> >>>>>>> * The server has persistence set permanently on for a service. >>>> >>>>>>> It >>>> >>>>>>> demands persistence from the client. Therefore it publishes a >>>> >>>>>>> policy >>>> >>>>>>> saying that client's must be persistent. During the >>>> >>>>>>> CreateSequence >>>> >>>>>>> exchange, it can refuse any client that doesn't agree (by some >>>> >>>>>>> yet-to-be-defined mechanism) to be persistent. This would be a >>>> >>>>>>> new >>>> >>>>>>> capability. >>>> >>>>>>> >>>> >>>>>>> * The server has some clever ability to turn persistence on or >>>> >>>>>>> off >>>> >>>>>>> per-sequence based on the create sequence. In this model, the >>>> >>>>>>> server >>>> >>>>>>> picks up the preference from the client. So the same service >>>> >>>>>>> might >>>> >>>>>>> have some persistent and some non-persistent sequences. Maybe >>>> >>>>>>> this is >>>> >>>>>>> overkill and beyond the basic requirements. I'm not clear. >>>> >>>>>>> However, >>>> >>>>>>> this seems to be a model that other systems allow. Of course, a >>>> >>>>>>> server >>>> >>>>>>> could respond that it doesn't support this capability. >>>> >>>>>>> >>>> >>>>>>> Ideally, all of this would be designed to allow backwards >>>> >>>>>>> compatibility. So even in the cases where the server refuses a >>>> >>>>>>> sequence because it requires persistence and the client doesn't >>>> >>>>>>> support this extension, the failure is explained in the error >>>> >>>>>>> and the >>>> >>>>>>> administrator can see why. >>>> >>>>>>> >>>> >>>>>>> Paul >>>> >>>>>>> >>>> >>>>>>> On Mon, Jun 16, 2008 at 12:20 PM, Danushka Menikkumbura >>>> >>>>>>> <[EMAIL PROTECTED]> wrote: >>>> >>>>>>>> >>>> >>>>>>>>>>> 1) A policy element to indicate whether this endpoint >>>> >>>>>>>>>>> supports >>>> >>>>>>>>>>> and/or >>>> >>>>>>>>>>> requires persistence >>>> >>>>>>>>>>> >>>> >>>>>>>>>>> >>>> >>>>>>>>>> >>>> >>>>>>>>>> (b) Even if we go for transport level persistence, the >>>> >>>>>>>>>> endpoint >>>> >>>>>>>>>> does >>>> >>>>>>>>>> not >>>> >>>>>>>>>> have a say in it, because in AMQP we can have either queue >>>> >>>>>>>>>> level >>>> >>>>>>>>>> persistence >>>> >>>>>>>>>> (i.e. transport receiver level abstraction) or message level >>>> >>>>>>>>>> persistence >>>> >>>>>>>>>> (i.e. message sender level abstraction). >>>> >>>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> Hi Paul, >>>> >>>>>>>> But still this is not doable with AMQP. >>>> >>>>>>>> >>>> >>>>>>>> Danushka >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> -- >>>> >>>>>>> Paul Fremantle >>>> >>>>>>> Co-Founder and CTO, WSO2 >>>> >>>>>>> Apache Synapse PMC Chair >>>> >>>>>>> OASIS WS-RX TC Co-chair >>>> >>>>>>> >>>> >>>>>>> blog: http://pzf.fremantle.org >>>> >>>>>>> [EMAIL PROTECTED] >>>> >>>>>>> >>>> >>>>>>> "Oxygenating the Web Service Platform", www.wso2.com >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> --------------------------------------------------------------------- >>>> >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> Paul Fremantle >>>> >>>>> Co-Founder and CTO, WSO2 >>>> >>>>> Apache Synapse PMC Chair >>>> >>>>> OASIS WS-RX TC Co-chair >>>> >>>>> >>>> >>>>> blog: http://pzf.fremantle.org >>>> >>>>> [EMAIL PROTECTED] >>>> >>>>> >>>> >>>>> "Oxygenating the Web Service Platform", www.wso2.com >>>> >>>> >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Paul Fremantle >>>> >>> Co-Founder and CTO, WSO2 >>>> >>> Apache Synapse PMC Chair >>>> >>> OASIS WS-RX TC Co-chair >>>> >>> >>>> >>> blog: http://pzf.fremantle.org >>>> >>> [EMAIL PROTECTED] >>>> >>> >>>> >>> "Oxygenating the Web Service Platform", www.wso2.com >>>> >>> >>>> >>> >>>> >>> --------------------------------------------------------------------- >>>> >>> 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] >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Amila Suriarachchi, >>>> > WSO2 Inc. >>>> >>>> >>>> >>>> -- >>>> Paul Fremantle >>>> Co-Founder and CTO, WSO2 >>>> Apache Synapse PMC Chair >>>> OASIS WS-RX TC Co-chair >>>> >>>> blog: http://pzf.fremantle.org >>>> [EMAIL PROTECTED] >>>> >>>> "Oxygenating the Web Service Platform", www.wso2.com >>> >>> >>> >>> -- >>> Amila Suriarachchi, >>> WSO2 Inc. > > > > -- > Amila Suriarachchi, > WSO2 Inc. -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
