Bug 724788 (BRMS-627) - When inspecting KnowledgeBase through JConsole events declared in different package have expiration offset -1
Summary: When inspecting KnowledgeBase through JConsole events declared in different p...
Keywords:
Status: VERIFIED
Alias: BRMS-627
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: unspecified
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: BRMS 5.2.0.GA
Assignee: Nobody
QA Contact:
URL: http://jira.jboss.org/jira/browse/BRM...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-12 07:16 UTC by Tomas Schlosser
Modified: 2023-05-31 23:39 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged to correct the expiration offset bug, and the correct expiration offset is now calculated.
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Test case (1.66 KB, application/zip)
2011-08-17 11:02 UTC, Tomas Schlosser
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker BRMS-627 0 None Closed Event expiration offset 2012-05-07 17:03:27 UTC
Red Hat Issue Tracker JBRULES-2994 0 None Closed Event expiration offset 2012-05-07 17:03:27 UTC

Description Tomas Schlosser 2011-07-12 07:16:08 UTC
securitylevel_name: Public

See JBRULES-2994

Comment 1 Tomas Schlosser 2011-07-12 07:16:25 UTC
Link: Added: This issue depends JBRULES-2994


Comment 2 Edson Tirelli 2011-08-16 20:53:57 UTC
As detailed in JBRULES-2994, I added a simple unit test and was unable to reproduce the problem.

https://github.com/droolsjbpm/drools/commit/412e757542300ebf7974bae3a622e09efe562160

Can you please provide additional info on how to reproduce it?

Thanks,
Edson

Comment 3 Tomas Schlosser 2011-08-17 11:02:18 UTC
The problem occurs only when the event is declared in different package (see the example included).

Comment 4 Tomas Schlosser 2011-08-17 11:02:58 UTC
Created attachment 518653 [details]
Test case

Comment 5 Edson Tirelli 2011-08-17 16:50:19 UTC
Fixed. Thanks for the additional information. 

Commit was applied to both master and 5.2.x branches:

https://github.com/droolsjbpm/drools/commit/09196b15f018f43c9589111557ef834c9cf1adc1

Comment 6 lcarlon 2011-08-25 03:43:47 UTC
Edson, please check the release notes content (technical notes field) for accuracy.

Thanks
Lee

Comment 7 lcarlon 2011-08-25 03:43:47 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Events declared in different packages had an expiration offset of -1 when inspecting the KnowledgeBase through JConsole. The issue was fixed by changing the way multiple type declarations are handled.

Comment 8 lcarlon 2011-08-25 04:23:47 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1,3 @@
+https://bugzilla.redhat.com/show_bug.cgi?id=724788
+
 Events declared in different packages had an expiration offset of -1 when inspecting the KnowledgeBase through JConsole. The issue was fixed by changing the way multiple type declarations are handled.

Comment 9 Edson Tirelli 2011-08-25 14:01:52 UTC
Hi Lee,

I am still getting the hang of the BZ process here, so bear with me... :)

Just to clarify, this was a regression more serious than it looked at first sight. There was a bug that was preventing the proper calculation of expiration offsets. So the Drools MBeans were presenting to the JMX console the actual expiration offset that was being used by the engine (-1 meaning those events would never expire). The fix I did was to properly merge type declarations (and expiration policies) from different packages so that the correct expiration offset is now calculated.

How is this usually worded for technical notes?

Thanks,
Edson

Comment 10 lcarlon 2011-08-29 01:23:27 UTC
Hi Edson, 

thanks for the info. 

The guideline we are using for release notes is to provide: Cause, Consequence, Fix, and Result[1].

What you have provided is perfect, thank you :) 

For future reference it is also fine to provide the information in bullet points, I will always go through and edit (if needed) whatever content is provided, that way you don't need to worry so much about the specific wording, just the information.

The release note text has been added:

A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged properly to correct the expiration offset bug, and the correct expiration offset is now calculated.


Thanks
Lee


[1]https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes

Comment 11 lcarlon 2011-08-29 01:23:27 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1,3 @@
 https://bugzilla.redhat.com/show_bug.cgi?id=724788
 
-Events declared in different packages had an expiration offset of -1 when inspecting the KnowledgeBase through JConsole. The issue was fixed by changing the way multiple type declarations are handled.+A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged properly to correct the expiration offset bug, and the correct expiration offset is now calculated.

Comment 12 Tomas Schlosser 2011-08-29 05:46:56 UTC
Yes, this is fixed now.

Comment 13 lcarlon 2011-09-14 04:27:27 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,3 +1 @@
-https://bugzilla.redhat.com/show_bug.cgi?id=724788
-
 A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged properly to correct the expiration offset bug, and the correct expiration offset is now calculated.

Comment 14 lcarlon 2011-10-10 03:12:12 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged properly to correct the expiration offset bug, and the correct expiration offset is now calculated.+A bug prevented the proper calculation of expiration offsets, resulting in the Drools MBeans being presented to the JMX console with no expiration. Type declarations (and expiration policies) from different packages have been merged to correct the expiration offset bug, and the correct expiration offset is now calculated.


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