[prev in list] [next in list] [prev in thread] [next in thread]
List: sandesha-dev
Subject: Re: Supporting permanent storage based reliability
From: Chamikara Jayalath <chamikaramj () gmail ! com>
Date: 2005-12-11 4:53:46
Message-ID: 9d4ec10b0512102053u152a96f1u5a1557f4eb14fc09 () mail ! gmail ! com
[Download RAW message or body]
+1.
Chamikara
On 12/10/05, Paul Fremantle <pzfreo@gmail.com> wrote:
>
> Ruchith
>
> I really like your suggestion. My only comment is that we should NOT
> inject an RM handler into a "security" phase. That would confuse everyone=
-
> me included. So can I suggest we add a "Persistence" or RM phase directly
> after security and inject the RM persistence handler there.
>
> Paul
>
> On 12/10/05, jaliya@opensource.lk <jaliya@opensource.lk > wrote:
> >
> > Hi Deepal and All,
> >
> > Yes, storing of messages should only happen for the RM enabled services=
.
> >
> > In any case if someone needs failover persistence he has to pay that
> > price
> > of storing messages, there are no other solutions to that.
> >
> > So in that case, the handler configuration explained by Ruchith should
> > work.
> >
> > Thanks,
> >
> > Jaliya
> > ----- Original Message -----
> > From: Deepal Jayasinghe
> > To: sandesha-dev@ws.apache.org
> > Sent: Thursday, December 08, 2005 11:10 PM
> > Subject: Re: Supporting permanent storage based reliability
> >
> >
> > Hi Chamikara
> >
> > If you are going to save everything in the first place it will slow dow=
n
> > 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 ; sandesha-dev@ws.apache.org
> > 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 decryptin=
g
> >
> > them. So the security handler has to be present before the RMPersister
> > handler. But if Security IN Handler edit the SOAP envelope, it could ge=
t
> > 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, jaliya@opensource.lk <jaliya@opensource.lk> 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 th=
e
> > 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: sandesha-dev@ws.apache.org
> > 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 ide=
a
> > 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 lik=
e
> > to continue correctly Axis2 will need the contexts to come back with th=
e
> > 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
> >
> >
> >
> >
>
[Attachment #3 (text/html)]
+1.<br>
<br>
Chamikara<br><br>
<br><div><span class="gmail_quote">On 12/10/05, <b class="gmail_sendername">Paul \
Fremantle</b> <<a href="mailto:pzfreo@gmail.com">pzfreo@gmail.com</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Ruchith<br><br>I really \
like your suggestion. My only comment is that we should NOT inject an RM handler into \
a "security" phase. That would confuse everyone - me included. So can I \
suggest we add a "Persistence" or RM phase directly after security and \
inject the RM persistence handler there.
<br><span class="sg"><br>Paul</span><div><span class="e" \
id="q_10815773ddf82f10_2"><br><br><div><span class="gmail_quote">On 12/10/05, <b \
class="gmail_sendername"><a href="mailto:jaliya@opensource.lk" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)"> jaliya@opensource.lk</a></b> \
<<a href="mailto:jaliya@opensource.lk" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">jaliya@opensource.lk </a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Deepal and \
All,<br><br>Yes, storing of messages should only happen for the RM enabled services. \
<br>In any case if someone needs failover persistence he has to pay that price<br>of \
storing messages, there are no other solutions to that.<br><br>So in that case, the \
handler configuration explained by Ruchith should work. \
<br><br>Thanks,<br><br>Jaliya<br>----- Original Message -----<br>From: Deepal \
Jayasinghe<br>To: <a href="mailto:sandesha-dev@ws.apache.org" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">sandesha-dev@ws.apache.org \
</a><br>Sent: Thursday, December 08, 2005 11:10 PM<br>Subject: Re: Supporting \
permanent storage based reliability <br><br><br>Hi Chamikara<br><br>If you are going \
to save everything in the first place it will slow down<br>the system , all our OM \
stuff wont be useless if we are going to do so. If<br>and only if we want to save the \
message we do that , so I do not mind when <br>RM is turn on particular service then \
all the message come to that service<br>save some where , not other \
messages.<br><br>I think we need to take this issue into Aixs2 mailing \
list.<br><br>Thanks,<br> \
Deepal<br>................................................................ \
<br>~Future is Open~<br><br>----- Original Message -----<br>From: Chamikara \
Jayalath<br>To: Jaliya Ekanayaka ; <a href="mailto:sandesha-dev@ws.apache.org" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> \
sandesha-dev@ws.apache.org</a><br>Sent: Thursday, December 08, 2005 1:21 AM \
<br>Subject: Re: Supporting permanent storage based reliability<br><br><br>Hi \
Jaliya,All,<br><br>hmm. Very Good point.<br>We can easily put a handler that does \
this (lets call this RMPersister).<br>It seems like this has to be the very first \
handler of the inFlow. But <br>since we are after the transport level we will have to \
save any changes<br>that happened there. At a glance it seems like we should save \
following<br><br>SOAPEnvelope -> We can easily save this in a \
database.<br>Transport Information -> We have to save the name of in and out \
<br>transports. And transport \
header<br> &nbs \
p; information.<br><br><br>If \
we try to save every message this could greatly reduce the performance.<br>So we \
could try to detect the messages that go towards RM enabled <br>services. We could \
identify them by inspecting the SOAP envelope.<br><br>But When security is present \
and messages come in an encrypted form a<br>major problem could arise. We cannot \
inspect messages without decrypting <br>them. So the security handler has to be \
present before the RMPersister<br>handler. But if Security IN Handler edit the SOAP \
envelope, it could get<br>confused when we re-inject message when recovering. But if \
we have the <br>original SOAP Envelope available (without decrypting), we \
can inject that.<br>But we need some help from the security \
guys :)<br><br>Thanx,<br>Chamikara<br><br><br><br><br>On 12/8/05, <a \
href="mailto:jaliya@opensource.lk" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">
jaliya@opensource.lk</a> <<a href="mailto:jaliya@opensource.lk" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">jaliya@opensource.lk</a>> \
wrote:<br>Hi Chamikara and all<br><br>I was thinking this sometimes back and had this \
kind of idea. Need to <br>clarify regarding the feasibility with other modules.
<br>If we need to provide failure safe RM then we need to store messages.<br>So if we \
store them just after the transport level with some id then in a<br>crash, RM can \
make that message to inject into axis2 engine at the module <br>initialization \
method. (That is why we add the module init method in the<br>initial design of \
Axis2)<br>Since we store messages before they get processed, we do not want to \
store<br>the context information( assume that RM store everything in a DB) \
<br><br>Please comment.<br><br>Thanks,<br><br>Jaliya<br><br><br><br>----- Original \
Message -----<br>From: Chamikara Jayalath<br>To: <a \
href="mailto:sandesha-dev@ws.apache.org" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> sandesha-dev@ws.apache.org</a><br>Sent: \
Tuesday, December 06, 2005 6:23 AM <br>Subject: Supporting permanent storage based \
reliability<br><br><br>Hi all,<br><br>I'm trying to implement failure safe \
reliability for Sandesha2. The idea<br>is to allow a Axis2+Sadesha2 system to \
continue a reliable message <br>sequence even after a failure (may be due to a sudden \
shutdown of<br>Sandesha2, or may be due to power failure). Since Sandesha2 itself \
is<br>going to be based on a database, it can protect its state from a crash.<br>
<br>However protecting the state of Axis2 system is a problem. It seems like<br>to \
continue correctly Axis2 will need the contexts to come back with the<br>same \
relationships and state ( flow information ect. ) it had before . <br><br>Does this \
mean that we have to ask axis2-devs to bring back the Context<br>Hierarchy \
Serialization methods we agreed to remove from it sometime back.<br>Or is there a \
better/different way?<br><br>Thanx,<br>Chamikara \
<br><br><br><br></blockquote></div><br>
</span></div></blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic