[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaginginthe1.0.5 draft
I don't think the connection needs to be persisted. An implementation can simply keep an in-memory table relating synchronous connections (pending for replies) with their corresponding RefToMessageIds. When an application sends a response message for a synchronous request, its RefToMessageId can be used to look up the synchronous connection(s) which should be used for returning the response. If the receiving MSH has not detected that the initial HTTP connection has been closed, it will attempt to send using that connection and likely encounter an error. If it detects the closure at an earlier point, then presumably the table can be cleaned up earlier and no attempt will be made to send the response over the broken connection when the response becomes available. By recording the new connection (corresponding to the retry) in the in-memory table, the response from the application when it eventually arrives can be returned properly. It is not acceptable to present the retried message to the application a second time. -Arvola -----Original Message----- From: David Fischer <email@example.com> To: Dale Moberg <firstname.lastname@example.org>; Arvola Chan <email@example.com>; firstname.lastname@example.org <email@example.com>; firstname.lastname@example.org <email@example.com> Date: Tuesday, October 16, 2001 6:18 PM Subject: RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging inthe1.0.5 draft Yes, I think this answers the question. I suppose you could have an application level retry which could be either a new message or a signal to the MSH to retry a previous message -- but I don't think we are talking about that. This is an MSH level retry -- same Message, same MessageId same exact bytes pulled out of "storage" where it is saved until the appropriate Ack is returned. I guess we are down to what happens if syncReply is true but the connection closes unexpectedly. There will be a Message (with this MessageId) in persistent storage but no Acknowledgment will have been sent back. When the retry arrives, it will find the previous message in persistent storage but no connection waiting and no Acknowledgment returned. The current spec says to ignore the message since a previous message is already waiting but now I think that is wrong. Sounds like the connection needs to be persisted at this point and the message needs to be presented to the Application (again). This presents a problem since the Application will now have duplicate messages. Am I getting this right? Do we need a new signal to the Application in this case? Regards, David Fischer Drummond Group. -----Original Message----- From: Dale Moberg [mailto:firstname.lastname@example.org] Sent: Tuesday, October 16, 2001 7:40 PM To: David Fischer; Arvola Chan; email@example.com; firstname.lastname@example.org Subject: RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging in the1.0.5 draft Whew. A lot of TCP connection questions today. Is this the issue: If a sender MSH is waiting for a HTTP Reply, and meanwhile the sender MSH is told to do an application level retry, should the sender drop the initial connection? If so, what happens at the Receiver end? (Basically, dropping the TCP connection at the sender end will cause an IO exception at the other end, that will in production code lead to some clean up procedures being run that should probably include forgetting about doing any HTTP reply-- no point to reply on a closed connection obviously. A lot of stuff about FIN and ACK and TIMEWAIT2 omitted-- see Stevens.) If this is the question, I have some other questions and remarks. Is the application level retry to be a new message (with a new message id, and so on)? Or is retrying a message an implicit service that a MSH offers the application level, so that the same message (with same message id) is pulled out of an archive or cache or queue and resent? If the same message is resent, why can't the currently pending wait for a response continue? Why put on more load, scrap an underway handling of the request, just to adhere to an additional retry request? Something sounds funny in what is being done in this case by scrapping an already underway service in order to start again and encounter the processing overhead anew. If this is a way to try to deal with "hangs," and to distinguish hangs from slow response, "good luck!" No good way to sort that one out without humans--even adding a forward progress indicator every 10 seconds ("100 Continue" or something like it) only gets you so far. I really get the feeling that we are adding level 2.0 or beyond exception handling for situations that, if they are to be dealt with at a protocol level, need some really new state machines. Checkpoint/restart, rendezvous logic, forward progress-- is not the kind of stuff for a 1.1 spec. Wait until SOAP over BEEP and add on a BEEP Channel with all those embellishments.. HTTP is just not general purpose enough to bother trying to put all this stuff on top of it. Also, mixing retry of RM with application level retry seems to be an area for new tangles. Is application level retry something that can be mixed with RM or should an application choose best effort if it is doing A.L. retry? I realize RosettaNet has application level retries. Is this functionality something beyond what RM can provide? Couldn't moving to RM, using PIP parameter values in the RM parameters, satisfy RosettaNet retry requirements? (If a new MessageId is to be used when doing application level retries, then that would be another story.) Finally, why is this on a blue-greenish background?!!? -----Original Message----- From: David Fischer [mailto:email@example.com] Sent: Tuesday, October 16, 2001 4:39 PM To: Arvola Chan; firstname.lastname@example.org Cc: email@example.com Subject: RE: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging in the1.0.5 draft OK, I agree. How do we tell the MSH to use this new sync connection instead of the old one which is holding? Just because the Sender decides to drop the connection, does not mean the Receiver actually realizes that. I am not a packet expert but, isn't the the Receiving end still waiting? I don't think there is anything like a "keep-alive" packet going back and forth. The connection is literally doing nothing. Regards, David. -----Original Message----- From: Arvola Chan [mailto:firstname.lastname@example.org] Sent: Tuesday, October 16, 2001 2:43 PM To: email@example.com Cc: firstname.lastname@example.org Subject: [ebxml-msg] Re: [ebxml-cppa] Comments on reliable messaging in the 1.0.5 draft David: The purpose of a sender retrying is not only to solicit for acknowledgment from the receiver, but also to solicit for the business level response. Therefore, if the Acknowledgment message is piggybacked on the business level response, then the latter compound message must be resent by the receiver in response to the duplicate message. Regards, -Arvola -----Original Message----- From: David Fischer <email@example.com> To: David Fischer <firstname.lastname@example.org>; Arvola Chan <email@example.com>; firstname.lastname@example.org <email@example.com> Cc: firstname.lastname@example.org <email@example.com> Date: Tuesday, October 16, 2001 12:10 PM Subject: RE: [ebxml-cppa] Comments on reliable messaging in the 1.0.5 draft Let me take some of that back. If we find an Acknowledgment Message in persistent storage, we can only reuse it if it is not piggybacked on another message. Is this really too much complexity? Should we just create a new Acknowledgment Message? This kind of search probably takes more cycles then just creating from scratch. . . Regards, David Fischer Drummond Group. -----Original Message----- From: David Fischer [mailto:firstname.lastname@example.org] Sent: Tuesday, October 16, 2001 1:40 PM To: Arvola Chan; email@example.com Cc: firstname.lastname@example.org Subject: RE: [ebxml-cppa] Comments on reliable messaging in the 1.0.5 draft Arvola, I think I need some clarification. <<comments inline>> David. -----Original Message----- From: Arvola Chan [mailto:email@example.com] Sent: Tuesday, October 16, 2001 12:39 PM To: firstname.lastname@example.org Cc: email@example.com Subject: [ebxml-cppa] Comments on reliable messaging in the 1.0.5 draft David: Here are some inlined comments on section 7.5 ebXML Reliable Messaging Protocol. Regards, -Arvola 7.5.2 Receiving Message Behavior If this is an Acknowledgment Message as defined in section 7 then: 1 Look for a message in persistent storage that has a MessageId that is the same as the value of RefToMessageId on the received Message 2 If a message is found in persistent storage then mark the persisted message as delivered If an AckRequested element is present that is targeted to a role in which the Receiving MSH is acting (see section 2.2.10 and 2.2.11) then do the following: 1 If the message is a duplicate (i.e. there is a MessageId held in persistent storage that was received earlier that contains the same value as the MessageId in the received message) generate an Acknowledgment Message (see section 7). The Receiving MSH MUST NOT deliver the message to the application interface. The above paragraph does not clearly explain how duplicate request messages are to be handled. The pointer to section 7 is imprecise. The section 7.5.3 Generating an Acknowledgment Message also does not provide information on how Acknowledgment messages for duplicate messages should be generated. The required information is actually included in section 7.5.2 but in a rather convoluted form (see below). <<The second paragraph is section 7 defines what an Acknowledgment Message is -- which is the intention of this link.>> 2 If the message is not a duplicate (there is no MessageId held in persistent storage that corresponds to the MessageId in the received message) then do the following: a Save the MessageId of the received message in persistent storage. As an implementation decision, the whole message MAY be stored if there are other reasons for doing so b Generate an Acknowledgment Message in response (this may be as part of another message). The Receiving MSH MUST NOT send an Acknowledgment Message until the message has be safely stored in persistent storage. Delivery of an Acknowledgment Message constitutes an obligation by the Receiving MSH to deliver the message to the application or forward to the next MSH in the message path as appropriate. Look in persistent storage for the first response to the received message (i.e. it contains a RefToMessageId that matches the MessageId of the received message). (1) If a response message was found in persistent storage then resend the persisted message back to the MSH that sent the received message The above discussions (in red) are really in the wrong place as the enclosing item #2 indicates that the message is not a duplicate. <<we are not looking for a duplicate here. We are looking to see if a response (Acknowledgment Message) has previously been sent. If so, send the same one again. If not, do the following. Maybe it would help to say "Acknowledgment Message" instead of "response".>> (2) If no response message was found in persistent storage, then: (a) if syncReply is set to true and if the CPA indicates an application response is included, ignore the received message (i.e. no message was generated in response to the received message, or the processing of the earlier message is not yet complete) If the incoming message message is a duplicate and syncReply is true but no message has been returned in response to the received message, then it must be the case that processing of the earlier message is not yet complete. In that case, the received message cannot be ignored. Instead, it is necessary to wait for completion of the earlier message and then return the response synchronously. (By the way, this clarification does not belong in this section because of the inconsistency (cited in red) above. <<Somehow just saying ignore seems wrong, I know. However, we certainly do not need to contact the Application and request a business reply again. Either the first message is still doing that or the whole thing is hung and there is nothing the MSH can do. I don't know what else to do besides ignore the resent message and wait for the completion of the old -- which will send an Acknowledgment when it is finished (if it ever finishes).>> (b) Otherwise, generate an Acknowledgment Message . A Receiving MSH node is NOT participating in the reliable messaging protocol for a received message if that message either; does not contain an AckRequested element, or does contain an AckRequested element that is not targeted at the Receiving MSH, because it is acting in a role other than that specified in the SOAP actor attribute of the received message. If the Receiving MSH node is operating as an intermediary along the message's message path, then it MAY use store-and-forward behavior. However, it MUST NOT filter out perceived duplicate messages from their normal processing at that node. (see section 11.2) 7.5.3 Generating an Acknowledgment Message An Acknowledgment Message MUST be generated whenever a message is received with an AckRequested element that has a SOAP actor URI which targets the Receiving MSH node. As a minimum, it MUST contain a MessageData element with a RefToMessageId that contains the same value as the MessageId element in the message being acknowledged and an Acknowledgment element. The above paragraph contradicts an earlier statement in section 7.5 (before 7.5.1): <<agreed. Actually, the RefToMessageId is now in the Acknowledgment element.>> An Acknowledgment Message MUST contain a MessageData element with a RefToMessageId that contains the same value as the MessageId element in the message being acknowledged and an Acknowledgment element as described in section 7.3.1. It is important to reiterate that the Acknowledgment message must be persisted before being sent. Need to say something about the persist duration for this message. Presumably, this can be the same as the persist duration for the incoming message. In fact, the definition of PersistDuration in section 7.4.6 needs to be expanded to cover "first response" messages. <<PersistDuration on the response message should be the same as on the First Message. OK, persistDuration is an interval. Is this since the original timestamp or since the timestamp on the response message?>> Depending on the value of the syncReply parameter, the Acknowledgment Message can be sent at the same time as the response to the received message. In this case, the values for the MessageHeader elements of the Acknowledgment Message are determined by the Service and Action associated with the business response. If syncReply is not specified in the incoming message or is not applicable to the delivery channel being used, then the CPA must be consulted to determine the delivery channel that is suitable for the Acknowledgment action. This delivery channel must not specify the use of Reliable Messaging! <<OK, what if there is no CPA? Can I change the above to say "if there is a CPA, then...">> If an Acknowledgment Message is being sent on its own, then the value of the MessageHeader elements MUST be set as follows: · The Service element MUST be set to: uri:www.oasis-open.org/messageService/ · The Action element MUST be set to Acknowledgment. · The From element MAY be populated with the To element extracted from the message received and all child elements from the To element received SHOULD be included in this From element. · The To element MAY be populated with the From element extracted from the message received and all child elements from the From element received SHOULD be included in this To element. · The RefToMessageId element MUST be set to the MessageId of the message received. 7.5.6 Failed Message Delivery If a message sent with an AckRequested element cannot be delivered, the MSH or process handling the message (as in the case of a routing intermediary) SHALL send a delivery failure notification to the From Party. The delivery failure notification message contains: · a From element that identifies the Party who detected the problem · a To element that identifies the From Party that created the message that could not be delivered · a Service element and Action element set as described in 220.127.116.11. · an Error element with a severity of: - Error if the party who detected the problem could not transmit the message (e.g. the communications transport was not available) - Warning if the message was transmitted, but an Acknowledgment Message was not received. This means the message probably was not delivered. · an ErrorCode of DeliveryFailure It is possible that an error message with an Error element with an ErrorCode set to DeliveryFailure cannot be delivered successfully for some reason. If this occurs, then the From Party that is the ultimate destination for the error message MUST be informed of the problem by other means. How this is done is outside the scope of this specification Note: If the From Party MSH receives an Acknowledgment Message from the To Party MSH, it SHOULD ignore all other DeliveryFailure or Acknowledgment Messages. If syncReply is in use, then the error message should be returned synchronously. Otherwise, the CPA needs to be consulted to determine the appropriate delivery channel for the MessageError action.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC