axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jal...@opensource.lk
Subject Re: Supporting permanent storage based reliability
Date Sat, 10 Dec 2005 16:04:11 GMT
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 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 ; 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 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 <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 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: 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 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




Mime
View raw message