Issue 19842: Bad event accepter removed from the waitingEventAccepter list (fuml-rtf) Source: Commissariat a l Energie Atomique-CEA (Dr. Jeremie Tatibouet, jeremie.tatibouet(at)cea.fr) Nature: Revision Severity: Significant Summary: Consider the case where an active class that has two classifier behaviors is instantiated. Each classifier behavior start on a run-to-completion step to completion step. This step is triggered by the consumption of “InvocationEventOccurrence” that was previously registered into the event pool of the object activation of the instantiated active object. When the first classifier behavior executes it suspends on a accept event action “Wait(Start)”. This provokes the registration in the waiting event accepter list of an “accepter” for the signal “Start”. The run-to-completion steps completes. waitingEventAccepters [ AcceptEventActionEventAccepter ] To start the second classifier behavior in a RTC step an “ClassifierBehaviorInvocationEventAccepter” is placed in the list of the waiting event accepters. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] The RTC steps starts when the “InvocationEventOccurrence” placed in the event pool gets consumed. The match between the event and the accepter is determined as being at index 1 of the list of waitingEventAccepters. matchingEventAccepterIndexes [ 1 ] The choice strategy returns 1. Consequently the selected event accepter becomes the one which is at j ­ 1 position the “matchingEventAccepterIndexes” list; so 1. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] However the event accepter that is removed is the one at j-1. Therefore the ClassifierBehaviorInvocationEventAccepter remains in the waiting event accepter list while the AcceptEventActionAccepter is removed. The assumption is that this.waitingEventAccepters.remove(j - 1); should be replaced by this.waitingEventAccepters.remove(matchingEventAccepterIndexes.get(j - 1)); to ensure the deletion of the right event accepter. Resolution: Correct dispatchNextEvent The issue is indeed a serious bug that has lurked in the specification since version 1.0. Revised Text: In 8.4.3.2.7 ObjectActivation, in operation dispatchEvent, near the end, replace the statements EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(matchingEventAccepterIndexes.getValue(j-1)); this.waitingEventAccepters.removeValue(j-1); with int k = matchingEventAccepterIndexes.getValue(j - 1); EventAccepter selectedEventAccepter = this.waitingEventAccepters.getValue(k); this.waitingEventAccepters.removeValue(k); Also update this in the normative XMI.] Actions taken: October 22, 2015: received issue April 6, 2017: Resolved June 22, 2017: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 22 Oct 2015 10:58:01 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Jeremie Tatibouet Employer: CEA mailFrom: jeremie.tatibouet@cea.fr Terms_Agreement: I agree Specification: fUML 1.2 Section: 8.4.3.2.7 FormalNumber: ptc/2015-09-09 Version: 1.2 Doc_Year: 2015 Doc_Month: September Doc_Day: 09 Page: 194 Title: Bad event accepter removed from the waitingEventAccepter list Nature: Revision Severity: Significant CODE: 3TMw8 B1: Report Issue Remote Name: napsaci011.intra.cea.fr Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 Time: 10:58 AM Description: Consider the case where an active class that has two classifier behaviors is instantiated. Each classifier behavior start on a run-to-completion step to completion step. This step is triggered by the consumption of “InvocationEventOccurrence” that was previously registered into the event pool of the object activation of the instantiated active object. When the first classifier behavior executes it suspends on a accept event action “Wait(Start)”. This provokes the registration in the waiting event accepter list of an “accepter” for the signal “Start”. The run-to-completion steps completes. waitingEventAccepters [ AcceptEventActionEventAccepter ] To start the second classifier behavior in a RTC step an “ClassifierBehaviorInvocationEventAccepter” is placed in the list of the waiting event accepters. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] The RTC steps starts when the “InvocationEventOccurrence” placed in the event pool gets consumed. The match between the event and the accepter is determined as being at index 1 of the list of waitingEventAccepters. matchingEventAccepterIndexes [ 1 ] The choice strategy returns 1. Consequently the selected event accepter becomes the one which is at j ­ 1 position the “matchingEventAccepterIndexes” list; so 1. waitingEventAccepters [ AcceptEventActionEventAccepter, ClassifierBehaviorInvocationEventAccepter ] However the event accepter that is removed is the one at j-1. Therefore the ClassifierBehaviorInvocationEventAccepter remains in the waiting event accepter list while the AcceptEventActionAccepter is removed. The assumption is that this.waitingEventAccepters.remove(j - 1); should be replaced by this.waitingEventAccepters.remove(matchingEventAccepterIndexes.get(j - 1)); to ensure the deletion of the right event accepter.