Created attachment 524877 [details] Class to reproduce bug Description of problem: When trying to start scanner service, then an exception is thrown: Exception in thread "Thread-3" java.lang.IllegalStateException: reader does have a modified date at org.drools.io.impl.ReaderResource.getLastModified(ReaderResource.java:64) at org.drools.io.impl.ResourceChangeScannerImpl.scan(ResourceChangeScannerImpl.java:166) at org.drools.io.impl.ResourceChangeScannerImpl$ProcessChangeSet.run(ResourceChangeScannerImpl.java:311) at java.lang.Thread.run(Thread.java:679) So change of the XLS resource is not noticed by the scanner. This issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=733008. Version-Release number of selected component (if applicable): BRMS 5.2.0 ER4 How reproducible: Start scan service on XLS resource. You can use provided test case. Steps to Reproduce: 1. Unzip provided test case. 2. Run Java application to reproduce bug. Actual results: Scanner fails to scan XLS resource. Expected results: Scanner should notice change of the XLS resource. Additional info:
Drools-compiler's org.drools.compiler.PackageBuilder#addKnowledgeResource method for some types (such as DTABLE, PKG, CHANGE_SET, ..) replaces the original resource with a ReaderResource. Part 1, adding delegateToResource code to the ReaderResource fixes the getLastModified() problem, but it causes Exception in thread "Thread-7" java.lang.RuntimeException: Unknown resource type: null at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:699) because somehow the ReaderResource and the original Resource have added to KnowledgeAgentImpl.registeredResources.
I tried simplifying the testcase while making sure it fails if the scanner-thread throws an exception, but JBRULES-3287 prevented me from doing so.
Created attachment 532778 [details] Fixes the lastModified date delegation Of the attached patch, run org.drools.decisiontable.ChangeSetTest#testCSVByKnowledgeAgentWithFileReader That testcase will succeed, but in the logging you 'll see a stacktrace which means it actually didn't succeed, but the off-thread exceptions are ignored. The patch fixes the lastModified problem, but that just surfaces the "Unknown resource type: null" which is due to a deeper architectural problem as far as I can tell.
Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3287 to Resolved
Edson Tirelli <ed.tirelli> made a comment on jira JBRULES-3287 Geoffrey, I am trying to get my head around this ticket and all the related ones. I applied your test case and after removing a couple lines from the test that I think were wrong, the test no longer fails. I added the test to both master and 5.3.x branches anyway and I am closing this ticket. Please let me know if you think there is still a problem here.
Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3287 to Closed
Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3282 to Closed
Jiri, Geoffrey, I am trying to identify (and fix if necessary) the problems related in this and related tickets, but I am not seeing the failure. Can one of you confirm that the failure still happens in either 5.3.x branch or master branch and if so, give me a test case or a description on how to reproduce? Both community JIRAS are closed. Thank you
Hello Edson, I have created pull request https://github.com/droolsjbpm/drools/pull/82 with test case for https://bugzilla.redhat.com/show_bug.cgi?id=751326 which has the same root cause. The problem persists with multiple resources in BRMS 5.3 and in current Drools master.
Thanks Jiri. With your test case I was able to see the problems. I sent out an e-mail to Mark and Geoffrey to discuss it. I pasted the e-mail bellow as well: ==== Hi guys, I am a bit new to this part of the code, so I would like to run something by you. https://bugzilla.redhat.com/show_bug.cgi?id=751326 I fixed a few problems in the code and I believe now I reached the bottom of issue. It seems it is a conceptual problem that we need to address. Basically, a changeset for us serves both as a kbase descriptor (if a new kbase is created with it) AND a change set descriptor (if there is a kbase and changes will be made to it). Now, imagine that we have an agent configured to always create a new instance of the kbase when anything changes. Then we apply changeset CS1 that loads resources A and B. After that, we apply changeset CS2 that does anything to B (update/remove). At this point, the agent will recreate a knowledge base and will identify that A did not change, and will try to re-load A, but A was loaded from a stream/reader/whatever that is no longer available (for instance, the stream was closed). The agent then raises an IOException and it blows up. I am not sure what approach we should take here? Probably the safest approach would be to define that, if the new instance option is set into the agent, then it will always only load what it is in the new change set being applied (CS2), completely ignoring anything that existed before (CS1)? In this case, the change set would really be a kbase descriptor. If the new instance option is off, then the change set will be handled as a change set and do an incremental change of the content of the kbase. Thoughts? ====
This is fixed for XLS, CSV and BPMN. Working on the PKG under the other open ticket for this.
Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3358 to Resolved
Edson Tirelli <ed.tirelli> updated the status of jira JBRULES-3358 to Closed
Please verify the issue on 5.3 ER4.
Verified in 5.3 ER4.
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: The KnowledgeAgent's ResourceChangeScanner failed to scan XLS resources and threw a illegalStateException. This has been resolved and error no longer occurs.