|
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 -----
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
|
