Hi Ruchith;
see my comments below;
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Ruchith Fernando" <[EMAIL PROTECTED]>
To: "Chamikara Jayalath" <[EMAIL PROTECTED]>
Cc: "Deepal Jayasinghe" <[EMAIL PROTECTED]>; <[email protected]>;
<[email protected]>
Sent: Friday, December 09, 2005 2:14 AM
Subject: Re: Supporting permanent storage based reliability
Hi,
I think Chamikara is correct. The SOAP headers are built anyway and
we can inspect those SOAP headers and find out whether there are any
RM headers.
*ONLY* if those headers are there we can store the message.
Also we do not have to worry about about the context hierarchy if we
can do transport based dispatching and figure out the service as I
have explained here : [1]
Deepal:
If you think we still have to store the whole context hierarchy can
you please explain what sort of information we store in the context
hierarchy just before it reaches the 'Persistence' handler. Note that
persistence handler has to be placed as explained in [1], as the first
handler after security where security *DEFINITELY* is the first
handler after transport based dispatch.
you do not have the context hierarchy until you come to InstanceDispatcher .
Till that point you only have mgsContext and Configuration context , if you
are sure about that you are not going to store any data in other contexts
then I am OK with saving at the first place. I thought that you are going to
store some properties in SGContext and ServiceContext use them latter in the
execution.
Thanks
Ruchith
[1]http://marc.theaimsgroup.com/?l=axis-dev&m=113404259319578&w=2
On 12/9/05, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi,
Yes. Thats why we try to inspect messages that go for RM enabled services
and save them only. We can do this by inspecting the SOAP headers.
Chamikara
On 12/9/05, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
>
> Hi Chamikara
>
> If you are going to save everything in the first place it will slow down
the system , all our OM stuff wont be useless if we are going to do so. If
and only if we want to save the message we do that , so I do not mind when
RM is turn on particular service then all the message come to that service
save some where , not other messages.
>
> I think we need to take this issue into Aixs2 mailing list.
>
> Thanks,
> Deepal
>
................................................................
> ~Future is Open~
>
>
> ----- Original Message -----
> From: Chamikara Jayalath
>
> To: Jaliya Ekanayaka ; [email protected]
> Sent: Thursday, December 08, 2005 1:21 AM
> Subject: Re: Supporting permanent storage based reliability
>
> Hi Jaliya,All,
>
> hmm. Very Good point.
> We can easily put a handler that does this (lets call this RMPersister).
It seems like this has to be the very first handler of the inFlow. But
since
we are after the transport level we will have to save any changes that
happened there. At a glance it seems like we should save following
>
> SOAPEnvelope -> We can easily save this in a database.
> Transport Information -> We have to save the name of in and out
transports. And transport header
> information.
>
>
> If we try to save every message this could greatly reduce the
> performance.
So we could try to detect the messages that go towards RM enabled
services.
We could identify them by inspecting the SOAP envelope.
>
> But When security is present and messages come in an encrypted form a
major problem could arise. We cannot inspect messages without decrypting
them. So the security handler has to be present before the RMPersister
handler. But if Security IN Handler edit the SOAP envelope, it could get
confused when we re-inject message when recovering. But if we have the
original SOAP Envelope available (without decrypting), we can inject that.
But we need some help from the security guys :)
>
> Thanx,
> Chamikara
>
>
>
>
> On 12/8/05, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
> > Hi Chamikara and all
> >
> > I was thinking this sometimes back and had this kind of idea. Need to
> > clarify regarding the feasibility with other modules.
> > If we need to provide failure safe RM then we need to store messages.
> > So if we store them just after the transport level with some id then
> > in
a
> > crash, RM can make that message to inject into axis2 engine at the
module
> > initialization method. (That is why we add the module init method in
> > the
> > initial design of Axis2)
> > Since we store messages before they get processed, we do not want to
store
> > the context information( assume that RM store everything in a DB)
> >
> > Please comment.
> >
> > Thanks,
> >
> > Jaliya
> >
> >
> >
> > ----- Original Message -----
> > From: Chamikara Jayalath
> > To: [email protected]
> > Sent: Tuesday, December 06, 2005 6:23 AM
> > Subject: Supporting permanent storage based reliability
> >
> >
> > Hi all,
> >
> > I'm trying to implement failure safe reliability for Sandesha2. The
> > idea
> > is to allow a Axis2+Sadesha2 system to continue a reliable message
> > sequence even after a failure (may be due to a sudden shutdown of
> > Sandesha2, or may be due to power failure). Since Sandesha2 itself is
> > going to be based on a database, it can protect its state from a
> > crash.
> >
> > However protecting the state of Axis2 system is a problem. It seems
> > like
> > to continue correctly Axis2 will need the contexts to come back with
> > the
> > same relationships and state ( flow information ect. ) it had before .
> >
> > Does this mean that we have to ask axis2-devs to bring back the
> > Context
> > Hierarchy Serialization methods we agreed to remove from it sometime
back.
> > Or is there a better/different way?
> >
> > Thanx,
> > Chamikara
> >
>
>
--
Ruchith
