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.
