Bug 735732 - Expiration is counted wrong for events in different package in CLOUD mode
Summary: Expiration is counted wrong for events in different package in CLOUD mode
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion)
Version: BRMS 5.2.0.GA
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: BRMS 5.2.0.GA
Assignee: Edson Tirelli
QA Contact: Tomas Schlosser
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-05 08:49 UTC by Tomas Schlosser
Modified: 2011-09-30 08:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-20 09:53:36 UTC
Type: Bug


Attachments (Terms of Use)
Simple test case (1.93 KB, application/zip)
2011-09-05 08:49 UTC, Tomas Schlosser
no flags Details

Description Tomas Schlosser 2011-09-05 08:49:56 UTC
Created attachment 521450 [details]
Simple test case

Description of problem:
When an event is inserted into StatefulKnowledgeSession working in CLOUD mode, the event's expiration is wrongly counted as 0ms. The event is then retracted after fireAllRules() is called. If the fact is in the same package, the expiration offset is -1 as it should be.

Version-Release number of selected component (if applicable):
BRMS-5.3.0-ER3

How reproducible:
every time

Steps to Reproduce:
1. run the attached example
  
Actual results:
[EntryPointNode(4) EntryPoint::entryPoint ]
    [ObjectTypeNode(9)::EntryPoint::entryPoint objectType=[ClassObjectType event=org.jboss.qa.drools.expirescloud.TestEvent] expiration=0ms ]

Expected results:
[EntryPointNode(4) EntryPoint::entryPoint ]
    [ObjectTypeNode(9)::EntryPoint::entryPoint objectType=[ClassObjectType event=org.jboss.qa.drools.expirescloud.TestEvent] expiration=-1ms ]

Additional info:
If you change package in DRL file to org.jboss.qa.drools.expirescloud and change the value of pkg constant in ExpiresTest.java you get the correct result.

Comment 1 Lukáš Petrovický 2011-09-05 08:57:37 UTC
This breaks the expected behavior. Requesting blocker status.

Comment 2 Tihomir Surdilovic 2011-09-14 18:59:45 UTC
[from edson]

Lukas/Thomas

In CLOUD mode, expiration offset is completely ignored by the engine, because there is no event garbage collection. It is a STREAM mode exclusive feature.

Comment 3 Tomas Schlosser 2011-09-14 20:43:36 UTC
Well as it shows up it isn't ignored. Unless I explicitly specify @expires(1m) the events (declared in different) inserted into working memory are swept after calling fireAllRules(). I'll add listing of objects after tomorrow and add results. I think the right expiration offset for events in CLOUD mode is -1 (meaning it should never expire), but is 0 (therefore expires right away and is swept from memory).

Comment 4 Lukáš Petrovický 2011-09-15 04:53:07 UTC
The test case (attachment 521450 [details]) makes the bug quite obvious, please take a look at that.

Comment 5 Edson Tirelli 2011-09-20 00:36:30 UTC
Lukas, Tomas,

I am not sure what the problem here is... as per my previous comment, in CLOUD mode, the expiration offset is completely ignored by the runtime engine. It does not matter what value the attribute holds. 

I checked the attached test case and I don't see how that test shows any bug. Can you please clarify?

Comment 6 Tomas Schlosser 2011-09-20 09:53:36 UTC
This bug disappeared in BRMS-5.2.0.ER4. I'm therefore closing this bug.

Comment 7 Edson Tirelli 2011-09-27 18:32:08 UTC
I am reopening this ticket because Bug 724788 reintroduced this problem.

Comment 9 Tomas Schlosser 2011-09-30 08:07:05 UTC
This bug was fixed in BRMS-5.2.0.ER5, marking it verified.


Note You need to log in before you can comment on or make changes to this bug.