Bug 1275378 - Missing new drl file after calling KieScanner.scanNow
Summary: Missing new drl file after calling KieScanner.scanNow
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: BRE
Version: 6.2.0
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ER5
: 6.2.0
Assignee: Mario Fusco
QA Contact: Marek Winkler
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-26 17:40 UTC by Oscar Molina
Modified: 2020-03-27 19:08 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:08:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Reproducer (192.60 KB, application/zip)
2015-10-26 17:41 UTC, Oscar Molina
no flags Details

Description Oscar Molina 2015-10-26 17:40:45 UTC
Description of problem:

When you use KieScanner.scanNow() to load an updated kjar, after updating, the rules are not firing as expected. The server has to be restarted and then the rules are firing as expected.

Given a simple project which contains some rules (a DRL file for each rule). If you deploy the project and run a test which fires those rules, it works fine. If you add a new rule, build and deploy and run the test after executing KieScanner.scanNow(), the new rule is fired as well. If you modify one of the rules so that it won't be matched, build and deploy and run again, then only the one rule will match and fire.

However, if you have one rule that matches, then modify this rule so that it won't match, and also add a new rule which will match, build and deploy and run the test after executing Kiescanner.scanNow(), then the modified one won't be matched but the new rule will not be fired.

If you restart the server, rules are firing as expected. It is a problem because each time that a new rule is created, the server has to be restarted the server and it is bad.

Steps to Reproduce:

1. Use the .niogit + repositories folder for the BRMS 6.1.x installation located in the attached reproducer.zip.
2. Build + deploy the bpms-util project in the BRMS 6.1.x installation located in the attached reproducer.zip.
3. Start the BRMS 6.1.x + EAP 6.4 with the steps before.
4. Add a new rule with the following code:
~~~
package example.simple;

rule "rule1"
when
then
    System.out.println("Rule1 fired!!!");
end
~~~
5. Build and deploy and then hit http://localhost:8080/bpms-util/test?scan=true to invoke the scan method. The new rule is fired.
6. Add a new rule with the following code:
~~~
package example.simple;

rule "rule2"
when
then
    System.out.println("Rule2 fired!!!");
end
~~~
7. Modify the first one so that it won't be matched.
8. Build and deploy and then hit http://localhost:8080/bpms-util/test?scan=true to invoke the scan method.

Actual results:

After step 8, the modified one won't be matched, but the new rule will not be fired.

Expected results:

After step 8, the modified rule won't be matched and the new rule should be fired.

Comment 1 Oscar Molina 2015-10-26 17:41:55 UTC
Created attachment 1086563 [details]
Reproducer

Comment 3 Mario Fusco 2015-10-27 13:36:35 UTC
Fixed by https://github.com/droolsjbpm/drools/commit/b15532936

Comment 4 Marek Winkler 2015-11-06 14:44:47 UTC
Verified in BRMS 6.2.0 ER5.


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