[
http://issues.apache.org/jira/browse/AXIS2-1567?page=comments#action_12446104 ]
Rajith Attapattu commented on AXIS2-1567:
-----------------------------------------
Hi Ann,
My comments are about the whole process (not the patch) of persisting the
MessageContext ( and it's related object graph even if we use
java.io.Externalizable). I haven't looked at the code completely, so pardon me
if I say something that is already covered by the code and I would appreciate
if u can point it out if I have done so.
I still disagree with this approach (not the implementation, but the idea) for
the following reasons.
In general I think this can be used as an alternative stratergy inside
Sandesha2 which handles reliable messaging, but I am not happy about baking
this into the kernal.
1.) The cost of persisting a message while in progress (having to take
snapshots), far outweighs the benifit of restarting a message from the
begining. Besides we are trying to do part of Relaible Messaging inside axis2
kernal.
Have you tried to compare the two scenarios with some bench marking ?
2.) In a high traffic senario the cost of persisting the message contexts can
be significant. We are doing all this unessacery persistance, anticipating a
server crash.
I would rather loose some data during a server crash which maybe rare, than
make my system do complicated stuff acticipating a server crash. But ymmv.
3.) Assuming we want to restart a message from a particular position in the
chain (instead of starting from the begining). In this case do we need to
persist some state associated with the handler as well ??
If soI don't like the idea if having state in the handlers. If we can keep the
handlers stateless, then all the better. Axis2 will scale better with the
engine being stateless.
4) As I mentioned above reliable messaging should handle this problem outside
the core of Axis2. And we already have a Reliable Messaging impl that really
works. So I see this as a potential alternative to the persistance we have for
Sandesha2.
5) What about the users who don't care about reliable messaging. If we bake
this into the kernal then we are forcing them to use persistance whether want
it or not. Of course we can make this configurable. But IMHO we shouldn't be
introducing this level complexicity to the kernal.
Comments are appreciated.
Regards,
Rajith
> Need to save and restore the AXIS2 MessageContext
> -------------------------------------------------
>
> Key: AXIS2-1567
> URL: http://issues.apache.org/jira/browse/AXIS2-1567
> Project: Apache Axis 2.0 (Axis2)
> Issue Type: New Feature
> Components: kernel
> Reporter: Ann Robinson
> Attachments: patch.txt
>
>
> There is an AXIS2 requirement to save the message context at some point in
> the handler chain, store it away, and restore it later. This requirement
> also includes the need to let handlers manage message-specific data when the
> message context is saved and restored.
> In particular, this feature can be used by a WS-ReliableMessaging
> implementation to persist and re-send messages and to recover from a server
> restart. The idea being to save a message context, then later restore the
> message context and pick up the message processing at the point at which the
> message context was saved (that is, without having to completely restart the
> message from the beginning).
> Refer to the wiki page
> http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore
> for a description of a proposal on how to accomplish this feature.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
