Issue 4256: The need for a default system SignalSet for failure scenarios. (ots-structs-ftf) Source: International Business Machines (Dr. Ian Robinson, ian_robinson@uk.ibm.com) Nature: Uncategorized Issue Severity: Summary: The need for a default system SignalSet for failure scenarios. Malik originally requested this function so I'm raising it as an issue on his behalf. The following section is taken from the Activity srevice specification orbos/2000-06-19. P47: "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the completion status of the Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator should act accordingly." What does it mean by "should act accordingly", and what should be sent to registered Actions if the (remote) SignalSet cannot be reached to produce Signals? Malik proposes a default SignalSet such as org.omg.SignallingFailure with the signal "Failure", which should be sent to any Actions involved with the unavailable SignalSet. This would require all Actions that cared about such failure scenarios to be able to react to such a Signal. All Actions would at least need to tolerate receiving such a Signal. We could go further and define system Outcomes that Actions could return to the SignallingFailure SignalSet and which could be percolated back up to Current::complete or just define a new exception that could be thrown back up to Current::complete. The important behaviour to provide is the ability for the Actions in the failing Activity to be given the chance to register or drive compensations or whatever recovery is necessary. Resolution: see above Revised Text: Section 2.2.1 currently states "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the completion status of the Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator should act accordingly." This text should be replaced with the following: "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the pre-defined org.omg.CosActivity.Failure SignalSet should be used instead. All pre-defined SignalSets are restricted to being located in the same domain as the ActivityCoordinator using them. Any Actions registered with an interest in the unreachable SignalSet will be sent Signals produced from the Failure SignalSet. " The following pre-defined SignalSet should be added to the specification and described in section 2.2.1. org.omg.CosActivity.Failure: initialFailure, finalFailure The Failure SignalSet is used by the ActivityCoordinator if an application SignalSet cannot be reached during Signaling. The Failure SignalSet produces two signals - initialFailure and finalFailure. initialFailure indicates that the application SignalSet could not be contacted but that the problem may be transient. An Action that receives the initialFailure signal should respond with one of two pre-defined Outcomes: "Failed" or "FailureRetry". Any Action that responds with "Failed" will not receive any further signals. Any Action that responds with FailureRetry is indicating that it wishes the ActivityCoordinator to continue to retry contacting the application SignalSet. If contact is subsequently made, signaling with the application SignalSet may continue. An Activity service implementation may chose at which point, if any, to abandon its attempt to contact the application SignalSet. At this point the Failure SignalSet is asked to produce the finalFailure Signal which is distributed to any remaining Actions for them to perform whatever processing is appropriate to them in this situation. The Failure SignalSet ignores any Outcome returned in response to this Signal. The Activity service changes the Activity status to StatusUnknown prior to distributing the initialFailure signal. The Activity service changes the Activity status to StatusError prior to distributing the initialFailure signal. If the application SignalSet does not complete its signaling, the ActivityCoordinator raises the org.omg.CosActivity.ActvityNotProcessed exception on the complete_activity or process_signal_set method that triggered the signaling and this exception is returned to the application through the Current complete, complete_with_status or broadcast methods. A new CosActivity::Status of StatusError is required. StatusError: An Activity is associated with the target object but it is unable to proceed as one or more of its entities are not available. The Activity may be in an inconsistent state. An ActivityNotProcessed exception should be added to the CosActivity module with the following description: The ActivityNotProcessed exception is raised to indicate that it was not possible to complete the processing of signals from a completion or broadcast SignalSet. This exception should be added to the following methods: ActivityCoordinator::complete_activity, ActivityCoordinator::process_signal_set Current::complete, Current::complete_with_status, Current::broadcast Each of these method descriptions should add: The ActivityNotProcessedException is raised in the event that the signals required to complete this operation could not be produced. In addition, the Current::complete and Current::complete_with_status method descriptions should further add: The Activity is completed in final status StatusError. Actions taken: April 5, 2001: received issue May 2, 2003: closed issue Discussion: Resolution: Although the earlier discussion of this issue suggested that it was never intended for SignalSets to be physically remote from the ActivityCoordinator with which they are registered, the specification should not introduce such a restriction. End of Annotations:===== From: ian_robinson@uk.ibm.com Received: from d06mta05.portsmouth.uk.ibm.com (d06mta05_cs0 [9.180.35.3]) by d06relay01.portsmouth.uk.ibm.com (8.8.8m3/NCO v4.95) with SMTP id IAA23638; Fri, 6 Apr 2001 08:40:25 +0100 Received: by d06mta05.portsmouth.uk.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 80256A26.002A2435 ; Fri, 6 Apr 2001 08:40:17 +0100 X-Lotus-FromDomain: IBMGB To: ots-structs-ftf@omg.org cc: issues@omg.org, Malik.saheb@inria.fr Message-ID: <80256A26.002A112D.00@d06mta05.portsmouth.uk.ibm.com> Date: Thu, 5 Apr 2001 21:40:59 +0100 Subject: Activity service Issue: The need for a default system SignalSet for failure scenarios. Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: A=#e9f&jd9Q6D!!B((!! Juergen, please open an issue for the following: The need for a default system SignalSet for failure scenarios. Malik originally requested this function so I'm raising it as an issue on his behalf. The following section is taken from the Activity srevice specification orbos/2000-06-19. P47: "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the completion status of the Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator should act accordingly." What does it mean by "should act accordingly", and what should be sent to registered Actions if the (remote) SignalSet cannot be reached to produce Signals? Malik proposes a default SignalSet such as org.omg.SignallingFailure with the signal "Failure", which should be sent to any Actions involved with the unavailable SignalSet. This would require all Actions that cared about such failure scenarios to be able to react to such a Signal. All Actions would at least need to tolerate receiving such a Signal. We could go further and define system Outcomes that Actions could return to the SignallingFailure SignalSet and which could be percolated back up to Current::complete or just define a new exception that could be thrown back up to Current::complete. The important behaviour to provide is the ability for the Actions in the failing Activity to be given the chance to register or drive compensations or whatever recovery is necessary. Regards...Ian Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com Importance: Normal Subject: Issue 4256: proposal To: ots-structs-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Tue, 17 Jul 2001 22:39:10 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 08:14:49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: 7S]!!=W5!!Zpfd9b*p!! Proposal for resolution of 4256. Although the earlier discussion of this issue suggested that it was never intended for SignalSets to be physically remote from the ActivityCoordinator with which they are registered, the specification should not introduce such a restriction. Following on from the discusion in Danvers, I suggest the following resolution. Section 2.2.1 currently states "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the completion status of the Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator should act accordingly." This text should be replaced with the following: "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the pre-defined org.omg.CosActivity.Failure SignalSet should be used instead. All pre-defined SignalSets are restricted to being located in the same domain as the ActivityCoordinator using them. Any Actions registered with an interest in the unreachable SignalSet will be sent Signals produced from the Failure SignalSet. " The following pre-defined SignalSet should be added to the specification and described in section 2.2.1. org.omg.CosActivity.Failure: initialFailure, finalFailure The Failure SignalSet is used by the ActivityCoordinator if an application SignalSet cannot be reached during Signaling. The Failure SignalSet produces two signals - initialFailure and finalFailure. initialFailure indicates that the application SignalSet could not be contacted but that the problem may be transient. An Action that receives the initialFailure signal should respond with one of two pre-defined Outcomes: "Failed" or "FailureRetry". Any Action that responds with "Failed" will not receive any further signals. Any Action that responds with FailureRetry is indicating that it wishes the ActivityCoordinator to continue to retry contacting the application SignalSet. If contact is subsequently made, signaling with the application SignalSet may continue. An Activity service implementation may chose at which point, if any, to abandon its attempt to contact the application SignalSet. At this point the Failure SignalSet is asked to produce the finalFailure Signal which is distributed to any remaining Actions for them to perform whatever processing is appropriate to them in this situation. The Failure SignalSet ignores any Outcome returned in response to this Signal. The Activity service changes the Activity status to StatusUnknown prior to distributing the initialFailure signal. The Activity service changes the Activity status to StatusError prior to distributing the initialFailure signal. If the application SignalSet does not complete its signaling, the ActivityCoordinator raises the org.omg.CosActivity.ActvityNotProcessed exception on the complete_activity or process_signal_set method that triggered the signaling and this exception is returned to the application through the Current complete, complete_with_status or broadcast methods. A new CosActivity::Status of StatusError is required. StatusError: An Activity is associated with the target object but it is unable to proceed as one or more of its entities are not available. The Activity may be in an inconsistent state. An ActivityNotProcessed exception should be added to the CosActivity module with the following description: The ActivityNotProcessed exception is raised to indicate that it was not possible to complete the processing of signals from a completion or broadcast SignalSet. This exception should be added to the following methods: ActivityCoordinator::complete_activity, ActivityCoordinator::process_signal_set Current::complete, Current::complete_with_status, Current::broadcast Each of these method descriptions should add: The ActivityNotProcessedException is raised in the event that the signals required to complete this operation could not be produced. In addition, the Current::complete and Current::complete_with_status method descriptions should further add: The Activity is completed in final status StatusError. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com From: "Mark Little" To: "XOTS" Subject: FTF meeting summary Date: Wed, 18 Jul 2001 10:05:44 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Filter-Version: 2.1 (cheviot3) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: *%D!!CL[d9H0jd9D]:!! Just a quick note to report on the meeting we had at Danvers. We managed to work through all of the issues that were reported prior to Danvers, though some have come up since. A brief summary of the issues we discussed, and the resolutions follows (the individuals who will write up the final proposed resolutions are also indicated). Proposal for 4256: adding Failure SignalSet (*must* be local to SignalSet, as are *all* system signalsets), which has two Signals: TransientFailed (up to implementation), DefiniteFailed. Action can return an outcome to indicate that is shouldn't be called on the second Signal. Also add StatusError to Status which is where the ActivityCoordinator goes when it cannot contact the SignalSet. StatusUnknown on first Signal generation, and only StatusError on second Signal generation. Need a default Outcome that the Action can produce which means "don't send me any more Signals". Client gets an exception (UserException). [Ian Robinson to write up.] Importance: Normal Subject: initialFailure, finalFailure signals To: ots-structs-ftf@omg.org Cc: "Alex Mulholland" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Ian Robinson" Date: Wed, 5 Sep 2001 15:54:13 +0100 X-MIMETrack: Serialize by Router on d06ml007/06/M/IBM(Release 5.0.8 |June 18, 2001) at 05/09/2001 15:59:24 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: l:'!!"#Xd9^JVd9%%ad9 Issue 4256 addressed the problem of a physically remote SignalSet not being contactable by introducing a local SignalSet that produces initialFailure and finalFailure signals. These Signals should carry the name of the failed application SignalSet rather than org.omg.CosActivity.Failure in the signal_set_name of the Signal structure in order that a subordinate Coordinator-Action be able to determine which Actions to forward such a signal on to. Otherwise, a subordinate that is registered back with its superior as either a global action or an Action with an interest in a set of SignalSets will not know which SignalSet has failed. Ian Robinson, WebSphere Transactions Architecture IBM Hursley Lab Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com ---------------------- Forwarded by Ian Robinson/UK/IBM on 05/09/2001 15:43 --------------------------- Ian Robinson 17/07/2001 22:39 To: ots-structs-ftf@omg.org cc: From: Ian Robinson/UK/IBM@IBMGB Subject: Issue 4256: proposal Proposal for resolution of 4256. Although the earlier discussion of this issue suggested that it was never intended for SignalSets to be physically remote from the ActivityCoordinator with which they are registered, the specification should not introduce such a restriction. Following on from the discusion in Danvers, I suggest the following resolution. Section 2.2.1 currently states "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the completion status of the Activity is set to CompletionStatusFailOnly, and the ActivityCoordinator should act accordingly." This text should be replaced with the following: "If a SignalSet fails to produce Signals (e.g., it is physically remote from the ActivityCoordinator and fails to respond to invocations), then the pre-defined org.omg.CosActivity.Failure SignalSet should be used instead. All pre-defined SignalSets are restricted to being located in the same domain as the ActivityCoordinator using them. Any Actions registered with an interest in the unreachable SignalSet will be sent Signals produced from the Failure SignalSet. " The following pre-defined SignalSet should be added to the specification and described in section 2.2.1. org.omg.CosActivity.Failure: initialFailure, finalFailure The Failure SignalSet is used by the ActivityCoordinator if an application SignalSet cannot be reached during Signaling. The Failure SignalSet produces two signals - initialFailure and finalFailure. initialFailure indicates that the application SignalSet could not be contacted but that the problem may be transient. An Action that receives the initialFailure signal should respond with one of two pre-defined Outcomes: "Failed" or "FailureRetry". Any Action that responds with "Failed" will not receive any further signals. Any Action that responds with FailureRetry is indicating that it wishes the ActivityCoordinator to continue to retry contacting the application SignalSet. If contact is subsequently made, signaling with the application SignalSet may continue. An Activity service implementation may chose at which point, if any, to abandon its attempt to contact the application SignalSet. At this point the Failure SignalSet is asked to produce the finalFailure Signal which is distributed to any remaining Actions for them to perform whatever processing is appropriate to them in this situation. The Failure SignalSet ignores any Outcome returned in response to this Signal. The Activity service changes the Activity status to StatusUnknown prior to distributing the initialFailure signal. The Activity service changes the Activity status to StatusError prior to distributing the initialFailure signal. If the application SignalSet does not complete its signaling, the ActivityCoordinator raises the org.omg.CosActivity.ActvityNotProcessed exception on the complete_activity or process_signal_set method that triggered the signaling and this exception is returned to the application through the Current complete, complete_with_status or broadcast methods. A new CosActivity::Status of StatusError is required. StatusError: An Activity is associated with the target object but it is unable to proceed as one or more of its entities are not available. The Activity may be in an inconsistent state. An ActivityNotProcessed exception should be added to the CosActivity module with the following description: The ActivityNotProcessed exception is raised to indicate that it was not possible to complete the processing of signals from a completion or broadcast SignalSet. This exception should be added to the following methods: ActivityCoordinator::complete_activity, ActivityCoordinator::process_signal_set Current::complete, Current::complete_with_status, Current::broadcast Each of these method descriptions should add: The ActivityNotProcessedException is raised in the event that the signals required to complete this operation could not be produced. In addition, the Current::complete and Current::complete_with_status method descriptions should further add: The Activity is completed in final status StatusError. Ian Robinson, Senior Software Engineer, WebSphere Development IBM UK Laboratories, Hursley MP 189 Tel (Ext) +44-1962-818626 (Int) 7-248626 ian_robinson@uk.ibm.com