Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 9676 invoked from network); 9 Dec 2005 05:24:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Dec 2005 05:24:23 -0000 Received: (qmail 41926 invoked by uid 500); 9 Dec 2005 05:23:54 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 41706 invoked by uid 500); 9 Dec 2005 05:23:53 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 41688 invoked by uid 99); 9 Dec 2005 05:23:53 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2005 21:23:53 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of chamikaramj@gmail.com designates 66.249.82.202 as permitted sender) Received: from [66.249.82.202] (HELO xproxy.gmail.com) (66.249.82.202) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Dec 2005 21:23:51 -0800 Received: by xproxy.gmail.com with SMTP id i27so536420wxd for ; Thu, 08 Dec 2005 21:23:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JysVlV9km6W8njYlMnXRHlwjiXwPxbsB2VgihJGDMrG+n4dyXn6ERmnz6a2OVFPwp3FmJ7+GSeveXoxsWAAG5Xe5O4BjlwyAHZaIwTEvO/cR+JD4aA67o+eQ5LfCuehbLXzZTL2CqQv++1PkuxruvgmMpeszT7i/uXEFGJpKvlc= Received: by 10.70.14.11 with SMTP id 11mr4893673wxn; Thu, 08 Dec 2005 21:23:30 -0800 (PST) Received: by 10.70.18.15 with HTTP; Thu, 8 Dec 2005 21:23:30 -0800 (PST) Message-ID: <9d4ec10b0512082123m2105a0c9p6ff1786f7c5f5305@mail.gmail.com> Date: Fri, 9 Dec 2005 11:23:30 +0600 From: Chamikara Jayalath To: Deepal Jayasinghe Subject: Re: Supporting permanent storage based reliability Cc: sandesha-dev@ws.apache.org, axis-dev@ws.apache.org In-Reply-To: <033f01c5fc76$970efed0$fa00d20a@Deepal> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_27647_1963194.1134105810371" References: <1519.149.159.3.192.1134020272.squirrel@webmail3.pair.com> <9d4ec10b0512080121x137f848ck5cd85e30efb9b330@mail.gmail.com> <033f01c5fc76$970efed0$fa00d20a@Deepal> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_27647_1963194.1134105810371 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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. I= f > and only if we want to save the message we do that , so I do not mind whe= n > RM is turn on particular service then all the message come to that servic= e > 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.or= g > *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 si= nce > 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 service= s. > 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, 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 > > > > ------=_Part_27647_1963194.1134105810371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 <deep= alk@gmail.com> wrote:
Hi Chamikara
 
If you are going to save everything in= the first=20 place it will slow down the system , all our OM stuff wont be useless if we= are=20 going to do so. If and only if we want to save the message we do that , so = I do=20 not mind when RM is turn on particular service then all the message come to= that=20 service save some where , not other messages.
 
I think we need to take this issue int= o Aixs2=20 mailing list.

Thanks,
 Deepal
.......................................= .........................
~Future=20 is Open~
----- Original Message = -----=20
Sent: Thursday, December 08, 2005 = 1:21=20 AM
Subject: Re: Supporting permanent = storage=20 based reliability

Hi Jaliya,All,

hmm. Very Good point.
We can eas= ily=20 put a handler that does this (lets call this RMPersister). It seems like = this=20 has to be the very first handler of the inFlow. But since we are after th= e=20 transport level we will have to save any changes that happened there. At = a=20 glance it seems like we should save following

SOAPEnvelope -> W= e can=20 easily save this in a database.
Transport Information -> We have to= save=20 the name of in and out transports. And transport header
   = =20                     &nb= sp;=20           information.


If we try to s= ave=20 every message this could greatly reduce the performance. So we could try = to=20 detect the messages that go towards RM enabled services. We could identif= y=20 them by inspecting the SOAP envelope.

But When security is present= and=20 messages come in an encrypted form a major problem could arise. We cannot= =20 inspect messages without decrypting them. So the security handler has to = be=20 present before the RMPersister handler. But if Security IN Handler edit t= he=20 SOAP envelope, it could get confused when we re-inject message when=20 recovering. But if we have  the original SOAP Envelope available (wi= thout=20 decrypting), we can inject that. But we need some help from the security= =20 guys  :)

Thanx,
Chamikara



On 12/8/05, jaliya@opensource.lk = < jaliya@opensource.lk> wrote:
Hi=20 Chamikara and all

I was thinking this sometimes back and had thi= s=20 kind of idea. Need to
clarify regarding the feasibility with other= =20 modules.
If we need to provide failure safe RM then we need to store= =20 messages.
So if we store them just after the transport level with s= ome=20 id then in a
crash, RM can make that message to inject into axis2 en= gine=20 at the module
initialization method. (That is why we add the module = init=20 method in the
initial design of Axis2)
Since we store messages b= efore=20 they get processed, we do not want to store
the context information(= =20 assume that RM store everything in a DB)

Please=20 comment.

Thanks,

Jaliya



----- Original Mes= sage=20 -----
From: Chamikara Jayalath
To: sandesha-dev@ws.apache.org
Sent:=20 Tuesday, December 06, 2005 6:23 AM
Subject: Supporting permanent sto= rage=20 based reliability


Hi all,

I'm trying to implement fa= ilure=20 safe reliability for Sandesha2. The idea
is to allow a Axis2+Sadesha= 2=20 system to continue a reliable message
sequence even after a failure = (may=20 be due to a sudden shutdown of
Sandesha2, or may be due to power=20 failure). Since Sandesha2 itself is
going to be based on a database,= it=20 can protect its state from a crash.

However protecting the state= of=20 Axis2 system is a problem. It seems like
to continue correctly Axis= 2=20 will need the contexts to come back with the
same relationships and = state=20 ( flow information ect. ) it had before .

Does this mean that we= have=20 to ask axis2-devs to bring back the Context
Hierarchy Serialization= =20 methods we agreed to remove from it sometime back.
Or is there a=20 better/different=20 way?

Thanx,
Chamikara


------=_Part_27647_1963194.1134105810371--