FUML13 — Bad event accepter removed from the waitingEventAccepter list

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.

Correct dispatchNextEvent

The issue is indeed a serious bug that has lurked in the specification since version 1.0.