+1 for sure... a separate phase will cartainly make it clearer. On 12/10/05, Paul Fremantle <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED] > 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: [email protected] > > 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 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
