-----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]
