[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1268) Activation.remove() is removing the WRONG activation when used in events

[Edson Tirelli (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBRULES-1268?page=comments#action_12381830 ] 
            
Edson Tirelli commented on JBRULES-1268:
----------------------------------------

There are 2 problems. The first problem is easy to fix: an Activation that is not queued anymore, should never call dequeue on itself again. This is fixed by nulling out the queue reference in the dequeue method:

    public void dequeue() {
        if ( this.queue != null ) {
            // will only be null if the AgendaGroup is locked when the activation add was attempted
            this.queue.dequeue( this.index );
            this.queue = null;
        }
        this.activated = false;
    }

The second problem is more subtle: is it a valid use case to try to cancel (dequeue) an activation from inside a listener? I don't think we should allow this, since listeners are supposed to be read-only and not influence the rule engine execution.

Ideas?




> Activation.remove() is removing the WRONG activation when used in events
> ------------------------------------------------------------------------
>
>                 Key: JBRULES-1268
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1268
>             Project: JBoss Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>    Affects Versions: 4.0.2
>            Reporter: Michael Neale
>         Assigned To: Edson Tirelli
>            Priority: Critical
>             Fix For: 4.1.0
>
>
> Check out FIXME_testActivationCancellation in MiscTest.java.
> It shows how a call to activation.remove() for a given rule (in an event) actually removed the wrong rule.
> The reason for this is that fireNextItem in DefaultAgenda uses BinaryHeapQueueAgendaGroup.getNext().
> This poorly named "getNext()" actually calls dequeue on the queue, so when the event is called, the activation has ALREADY been dequeued. 
> Not sure of best solution, other then a queue "peek()" and then dequeue() to be called after then event is fired (if it wasn't called already). 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira