On Tue, Jun 17, 2008 at 9:53 PM, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
> Don't know if somebody has done this earlier, but as Chamikara mentioned, > we can have a daemon process in the client side which acts as the: > > 1. Endpoint for the dual channel communications originating from that > machine. > 2. manager for the reliable communications. > > The communications between the RMHandler (not the client application) and > the daemon process should happen via a persistence storage mechanism. > isn't this mean the user has to write this logic in the deamon. So I think writing this straight away in the Application client would make it easier. > The daemon will keep trying to send the messages, and if something fail, > once in a while bug the user with a pop up window :) > Then anyway application client has to handle this isn't it? This means some recovery part should goes to application client. thanks, Amila. > > Thanks, > Jaliya > > > ----- Original Message ----- > *From:* Chamikara Jayalath <[EMAIL PROTECTED]> > *To:* Amila Suriarachchi <[EMAIL PROTECTED]> > *Cc:* Paul Fremantle <[EMAIL PROTECTED]> ; [email protected] > *Sent:* Tuesday, June 17, 2008 11:05 AM > *Subject:* Re: [Mercury] Mercury restarting (was persistence policy) > > 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. > > 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. > > 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.
