[JBoss JIRA] (JBRULES-3385) Rule not fired depending on the class loading order
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3385?page=com.atlassian.jira.plug... ]
Davide Sottara commented on JBRULES-3385:
-----------------------------------------
It works correctly in 5.5.0+
> Rule not fired depending on the class loading order
> ---------------------------------------------------
>
> Key: JBRULES-3385
> URL: https://issues.jboss.org/browse/JBRULES-3385
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.2.0.Final, 5.3.0.Final
> Environment: SLES11 SP1 with java 1.6.0_14-b08 (32bit and 64bit) or XP with jdk1.6.0_22 (32 or 64 bit)
> Reporter: Manuel Reinaldo Falagan
> Assignee: Mark Proctor
> Priority: Blocker
> Attachments: DROOLS_ERROR.zip, LeftTupleIndexHashTable.java, RightTupleIndexHashTable.java
>
>
> A very simple example "FailTest" triggers a rule only 15 times when it should trigger it 16 times.
> The same example with almost any change to the class model or to the order in loading the classes or the input data or the version of java it works.
> The Class FailTest contains only a main method calling the main method of the Class HelloWorldExample. Running directly the main method in the class HelloWorldExample does work.
> Any change fixes the problem in the example but it moves the error to other part. We have set a test testing more than 2000 million cases of rules/inputs and no matter how we write the rules or the code, we end up finding a case that fails, making the software not usable, as it is not predictable were it is going to fail.
> The case has been uner study for more than a year and we have tried AIX, Linux and XP with DROOLS 5.1, 5.2, 5.3 and the trial of Enterprise edition. The example provided has only been tested to fail for DROOLS 5.3.0 final and Enterprise edition for SLES11 SP1 with the SUN virtual machine (not the IBM one) and for XP but there is no combination for which DROOLS work for the 2000 million cases.
> The example provided is a 7kb example self-contained ( attached file DROOLS_ERROR.zip )
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (JBRULES-3612) Prevent a trait from being applied to a given object
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3612?page=com.atlassian.jira.plug... ]
Davide Sottara resolved JBRULES-3612.
-------------------------------------
Fix Version/s: FUTURE
Resolution: Out of Date
Obsolete. Will be managed in 6.x using strong negation and TMS
> Prevent a trait from being applied to a given object
> ----------------------------------------------------
>
> Key: JBRULES-3612
> URL: https://issues.jboss.org/browse/JBRULES-3612
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Optional
> Fix For: FUTURE
>
>
> For various reasons, a rule may want to prevent the future "don" of a given trait for a given object.
> I propose the use of the "ward" macro, as follows:
> Thing t = ward( $core, BannedTrait.class );
> If another rule, at a later point, will try to apply the BannedTrait or any of its subtypes to $core, that trait will not be applied to $core and (potentially) an exception will be thrown.
> Details:
> $core can be a @Traitable object or a Thing (i.e. an instance of a trait proxy). THe "ward" operation automatically applies the "Thing" trait to $core in case it has not been done yet.
> Optionally, one might use the "grant" macro to undo a ward (suggestions for a better name are encouraged).
> This feature will help in the implementation of "disjunct" or "mutually exclusive" traits, which are incompatible and can't be applied to the same
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (JBRULES-2792) Provide accessability of types and metadata for declare-d types
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-2792?page=com.atlassian.jira.plug... ]
Davide Sottara closed JBRULES-2792.
-----------------------------------
Resolution: Done
> Provide accessability of types and metadata for declare-d types
> ---------------------------------------------------------------
>
> Key: JBRULES-2792
> URL: https://issues.jboss.org/browse/JBRULES-2792
> Project: JBRULES
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: drools-api
> Affects Versions: 5.1.1.FINAL
> Reporter: Wolfgang Laun
> Assignee: Davide Sottara
> Fix For: 6.0.0.Alpha1
>
>
> * All types created or enhanced by a DRL declare construct must be retrievable from the KnowledgeBase using
> Declare getDeclare( String pkg, String name )
> * A Declare object must provide getters String getPackageName(), getName(), Map<String,Object> getMetaData() (same as Rule)
> * A Declare object must provide Class<?> getFactClass() returning the created or enhanced java-lang.Class.
> * A Declare object must provide long getInferredExpires() returning (for @role(event)) the inferred expiration offset or -1 if none.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (JBRULES-3662) Rule activation error using length sliding window
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3662?page=com.atlassian.jira.plug... ]
Davide Sottara commented on JBRULES-3662:
-----------------------------------------
After trying to fix 3201 in 5.5.1-SNAPSHOT, I can run the NewTest without errors.
> Rule activation error using length sliding window
> -------------------------------------------------
>
> Key: JBRULES-3662
> URL: https://issues.jboss.org/browse/JBRULES-3662
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core
> Affects Versions: 5.3.0.Final, 5.4.0.Final, 5.5.0.Beta1
> Environment: Mac OS X, running Apple Java 1.6, Maven2, Eclipse Juno
> Reporter: Vítor Moreira
> Assignee: Mark Proctor
> Fix For: 6.0.0.Alpha1
>
> Attachments: droolsTest.zip
>
>
> When using "window:length", some rules are activated twice, when it should be only activated once.
> The uploaded example reproduces the error: we insert Transactions, which has a field "problem" inside: 1 for problem, 0 for OK. The rules calculates the percent of transactions with problems. If the percentage>=40%, raises an alarm. If it's below 40%, removes the alarm (if there's an alarm). There is a minimum of 5 transactions to trigger/rearm.
> The test case simulates a raise to 40% (alarm is trigged), continues high (until 60%) and starts to fall down to 20% (alarm is removed).
> Drools version 5.2.0.Final: alarm is trigged *once*, removed *once*
> Drools version 5.3.0.Final: alarm is trigged *once*, removed *twice*
> Drools version 5.4.0.Final: alarm is trigged *once*, removed *twice*
> Drools version 5.5.0.Beta1: alarm is trigged *once*, removed *twice*
> Since there's only one alarm and drools tries to remove twice, there's a NullPointerException.
> *NOTE:* the attached zip file has code to test issue 3564 because I first though that could be a reopen issue but no, it's not the same issue (issue 3564 is resolved in 5.5.0.Beta1).
> *NOTE2:* I don't know if it's related to issue 3201...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (DROOLS-112) Allow join constraints in sliding windows
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-112:
-------------------------------------
Summary: Allow join constraints in sliding windows
Key: DROOLS-112
URL: https://issues.jboss.org/browse/DROOLS-112
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.Beta1, 6.0.0.Alpha9, 5.5.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Critical
Fix For: 6.0.0.Final
When using a sliding window, alpha constraints are evaluated before the window is considered, but beta (join) constraints are evaluated afterwards.
While it does not usually make a difference when time windows are concerned,
it DOES make a difference with length windows.
Imho, a clear warning should be added in the documentation to clarify
the current behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (JBRULES-3201) Sliding windows - Rule is being fired even when LHS is false
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3201?page=com.atlassian.jira.plug... ]
Davide Sottara commented on JBRULES-3201:
-----------------------------------------
sorry for overlooking this, it is actually a very bad bug.
I have reproduced it and proposed a solution. Hopefully 5.6 and 6.x will include a fix for it
> Sliding windows - Rule is being fired even when LHS is false
> ------------------------------------------------------------
>
> Key: JBRULES-3201
> URL: https://issues.jboss.org/browse/JBRULES-3201
> Project: JBRULES
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: drools-core (fusion)
> Affects Versions: 5.3.0.Beta1
> Environment: Linux
> Reporter: eyal rahamim
> Assignee: Mark Proctor
> Labels: `
> Attachments: windowLength.drl, WindowLength.java
>
>
> I have a rule that accumulate fact into sliding window. When the count get to a certain threshold the rule should be activated. After the window time is over, I expect that the rule will not fired anymore. The counter of the fact is report as 0, but still the rule is being executed.
> drl :
> package com.sample;
> import com.sample.WindowLength.FactTest;
> declare FactTest
> @role( event )
> end
>
> rule "A500 : test"
> when
> // count devices per tag id
> $counter : Number( intValue >= 2 ) from accumulate (
> $d : FactTest() over window:time(1m), count($d))
>
> then
> System.out.println("A500: Rule is fired, count = " + $counter + " *********");
> end
> scenario:
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime(1, TimeUnit.MINUTES );
> ksession.fireAllRules();
> Result:
> A500: Rule is fired, count = 2 *********
> A500: Rule is fired, count = 3 *********
> A500: Rule is fired, count = 0 *********
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (DROOLS-78) NullPointerException in windows eviction
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-78?page=com.atlassian.jira.plugin.... ]
Davide Sottara commented on DROOLS-78:
--------------------------------------
I tried to run the test case you provided after the patch and I don't get any exception
> NullPointerException in windows eviction
> ----------------------------------------
>
> Key: DROOLS-78
> URL: https://issues.jboss.org/browse/DROOLS-78
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Radai Rosenblatt
> Assignee: Mark Proctor
> Priority: Blocker
> Attachments: droolsIssue.zip
>
>
> when writing a (fusion) rule with a length window and inserting more events than the window size drools produces a null pointer exception on the 1st event over the window size.
> the exception produced is:
> java.lang.NullPointerException
> at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
> at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> at org.drools.rule.SlidingLengthWindow.assertFact(SlidingLengthWindow.java:116)
> at org.drools.rule.BehaviorManager.assertFact(BehaviorManager.java:94)
> at org.drools.reteoo.WindowNode.assertObject(WindowNode.java:167)
> at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
> a similar exception happens when the rule is re-written to use a time window (and the test updated to overflow that window):
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction@1dc39fc3
> at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:127)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:55)
> at TestBug2.testBug(TestBug2.java:96)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:76)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:195)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
> Caused by: java.lang.NullPointerException
> at org.drools.core.util.index.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:363)
> at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:189)
> at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:471)
> at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993)
> ... 31 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (JBJCA-1027) com.github.fungal.impl.KernelImpl.recursiveDelete cannot delete temporary jar file on Windows
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1027?page=com.atlassian.jira.plugin... ]
Jesper Pedersen commented on JBJCA-1027:
----------------------------------------
Could you create a forum post, and run https://github.com/kohsuke/file-leak-detector/commits/master on it
> com.github.fungal.impl.KernelImpl.recursiveDelete cannot delete temporary jar file on Windows
> ---------------------------------------------------------------------------------------------
>
> Key: JBJCA-1027
> URL: https://issues.jboss.org/browse/JBJCA-1027
> Project: IronJacamar
> Issue Type: Bug
> Components: Fungal
> Environment: Windows 7; Windows 2008 Server
> Reporter: Gytis Trikleris
> Assignee: Jesper Pedersen
>
> {code}
> -------------------------------------------------------------------------------
> Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest
> -------------------------------------------------------------------------------
> Tests run: 10, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.32 sec <<< FAILURE!
> org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0.063 sec <<< ERROR!
> java.io.IOException: Could not delete C:\Users\hudson\AppData\Local\Temp\2\iron.jacamar\tmp\jdbc-xa.rar\ironjacamar-jdbc.jar
> at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1520)
> at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1515)
> at com.github.fungal.impl.KernelImpl.recursiveDelete(KernelImpl.java:1515)
> at com.github.fungal.impl.KernelImpl.shutdown(KernelImpl.java:850)
> at org.jboss.jca.embedded.EmbeddedJCA.shutdown(EmbeddedJCA.java:158)
> at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:146)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
> at $Proxy0.invoke(Unknown Source)
> at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:145)
> at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:87)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
> {code}
> It works fine on Linux. However, it fails on both Windows 7 and Windows 2008 server.
> This simple test class also fails during shutdown with the same error:
> {code}
> public class SimpleTest {
> private static final String JDBC_RAR_FILE_PATH = "src/main/resources/jdbc-xa.rar";
> private static Embedded EMBEDDED;
> @Test
> public void test() throws Throwable {
> EMBEDDED = EmbeddedFactory.create();
> EMBEDDED.startup();
> EMBEDDED.deploy(getURL(JDBC_RAR_FILE_PATH));
> System.out.println("Test...");
> EMBEDDED.undeploy(getURL(JDBC_RAR_FILE_PATH));
> EMBEDDED.shutdown();
> }
> private static URL getURL(final String path) throws MalformedURLException {
> final File f = new File(path);
> return f.toURI().toURL();
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months