[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] reliable messaging
Engkee,
You are proposing an ACK to an ACK ("UNTIL the ack has been successfully
sent to Party A and confirmed accordingly..."). Some kind of ACK to an ACK
seems to be needed as part of any solution. Anything involving an ACK to an
ACK would require added function in the MSG specification. I don't see a
way around doing that.
Solutions based on status request protocols might allow most system
failure/recovery cases to be recovered without having to start from the
beginning.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Engkee Kwang"
<ekwang@vitria.co To: Martin W Sachs/Watson/IBM@IBMUS
m> cc: <ebxml-msg@lists.oasis-open.org>
Subject: RE: [ebxml-msg] reliable messaging
10/15/2002 11:54
AM
Marty,
i'm sure that i'm out of sync and missing some detail here but it would
seem that at least this problem can be avoid IF
- Party B's MSH persist the message BUT DO NOT pass it to the application
UNTIL the ack has been successfully sent to Party A and confirmed
accordingly...
- then when Party B's MSH comes back up, it should try to send the ack
AFTER checking that the time allowed has not expired. Since in this case,
the time has expired, it should consider the message to be invalid and not
pass it to the application
Engkee
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Monday, October 14, 2002 8:46 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] reliable messaging
>
>
>
>
>
>
> It has been pointed out to me that ebXML reliable messaging
> is not reliable
> under system failure. At least one person who mentioned it
> considers ebXML
> messaging to be broken as a result. Here is a scenario:
>
> Party A send a message reliably to Party B.
>
> Party B's MSH receives and persists the message.
>
> Party B's MSH attempts to send the reliable-messaging
> acknowledgment but
> Party B's system goes down before the acknowledgment gets on the wire.
>
> Party A exhausts its retries and concludes that the message was not
> delivered.
>
> Party B eventually comes up and the destination application
> processes the
> persisted message as prescribed in the MSG specification.
>
> Parties A and B are now out of sync with respect to that
> transaction and do
> not know they are out of sync. Party A believes that the transaction
> failed. Party B has in fact processed the message that it
> received from
> Party A. Reliable messaging has failed to deliver on its promise.
>
> The solution to this problem is not trivial and the MSG team
> needs to give
> it a lot of thought. At a minimum, the following are needed
> in the spec:
>
> 1. Both parties to the message exchange MUST persist enough
> state to allow
> recovery and getting back in sync. Specific state variables must be
> prescribed. They are at least those variables needed to
> restore the state
> of the transaction and conversation after system recovery, such as the
> conversation ID, CPA Id, service, action, and perhaps other
> parts of the
> message header.
>
> 2. Timeouts and retries, as prescribed in the MSG spec, are
> not sufficient
> to cover system failures since the failure could last a very
> long time.
> Instead, if the party that sent the message doesn't receive a
> reply in a
> reasonable time, it must be able to send a status query to
> the other party
> and keep requesting status periodically until it receives a
> response. The
> status query protocol must be defined in the MSG specification. If the
> appropriate state information is persisted at both ends, when
> party B comes
> up, it will receive and respond properly to the status query.
> The timeouts
> could be retained in the spec but their main use would be to
> signal the
> "attached human" to make a phone call.
>
> The MSG team should consider this a work item for version 3.
> Should the
> team not wish to solve this problem, at the very least, a
> caveat should be
> added to the MSG specification that messaging reliability
> under conditions
> of system failure is outside the scope of the MSG team.
>
> Regards,
> Marty
>
>
>
> **************************************************************
> ***********************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287; IBM tie line 863-7287
> Notes address: Martin W Sachs/Watson/IBM
> Internet address: mwsachs @ us.ibm.com
> **************************************************************
> ***********************
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC