-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "bug the user with a pop up window " - Please think of a production farm with 100's of machines with no GUI, just headless java with may be one operator on a night shift :)
- -- dims Jaliya Ekanayake 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. | 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 :) | | Thanks, | Jaliya | | ----- Original Message ----- | From: Chamikara Jayalath | To: Amila Suriarachchi | Cc: Paul Fremantle ; [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. | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIV+gGgNg6eWEDv1kRAm+HAKCQ50D9z//duv5V/YpT3cVNPrhUMQCgh+yx MG9qE8kYrTnheVH9Fgly0Ao= =o+Dy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
