[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
13 years
[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
13 years
[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
13 years
[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
13 years
[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
13 years
[JBoss JIRA] (AS7-5620) @Resource injection isn't done on static members
by John Doyle (JIRA)
[ https://issues.jboss.org/browse/AS7-5620?page=com.atlassian.jira.plugin.s... ]
John Doyle commented on AS7-5620:
---------------------------------
David, it did get opened as an RFE. Can you give me some info or a link on "Jaikiran's component-level interceptor functionality". Is that something that the customer implements, or a new feature?
> @Resource injection isn't done on static members
> -------------------------------------------------
>
> Key: AS7-5620
> URL: https://issues.jboss.org/browse/AS7-5620
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Miroslav Novak
> Assignee: Stuart Douglas
>
> There is a change in behaviour of:
> {code}
> @Resource(mappedName = "java:/JmsXA")
> private static ConnectionFactory cf;
> {code}
> In EAP6/AS7.1.2.Final this property is initialized but in EAP6.0.1.ER2/AS7.1.3.Final is not.
> This could also break backward compatibility. Is there a reason why this feature should not work?
> Used MDB:
> {code}
> import java.util.concurrent.atomic.AtomicInteger;
> import javax.annotation.Resource;
> import javax.ejb.*;
> import javax.jms.*;
> import org.apache.log4j.Level;
> import org.apache.log4j.Logger;
> @MessageDriven(name = "mdb",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue = "jms/queue/InQueue")})
> @TransactionManagement(value = TransactionManagementType.CONTAINER)
> @TransactionAttribute(value = TransactionAttributeType.REQUIRED)
> public class LocalMdbFromQueue implements MessageDrivenBean, MessageListener {
> @Resource(mappedName = "java:/JmsXA")
> private static ConnectionFactory cf;
> @Resource(mappedName = "java:/jms/queue/OutQueue")
> private static Queue queue;
> public static AtomicInteger globalCounter = new AtomicInteger();
> private static final long serialVersionUID = 2770941392406343837L;
> private static final Logger log = Logger.getLogger(LocalMdbFromQueue.class.getName());
> private MessageDrivenContext context = null;
> public LocalMdbFromQueue() {
> super();
> }
> @Override
> public void setMessageDrivenContext(MessageDrivenContext ctx) {
> this.context = ctx;
> }
> public void ejbCreate() {
> }
> @Override
> public void ejbRemove() {
> }
> @Override
> public void onMessage(Message message) {
> Connection con = null;
> Session session;
> try {
> long time = System.currentTimeMillis();
> int counter = 0;
> try {
> counter = message.getIntProperty("count");
> } catch (Exception e) {
> log.log(Level.ERROR, e.getMessage(), e);
> }
> String messageInfo = message.getJMSMessageID() + ", count:" + counter;
> log.log(Level.INFO, " Start of message: " + globalCounter.incrementAndGet() + ", message info:" + messageInfo);
> con = cf.createConnection();
> con.start();
> session = con.createSession(false, Session.AUTO_ACKNOWLEDGE);
> String text = message.getJMSMessageID() + " processed by: " + hashCode();
> MessageProducer sender = session.createProducer(queue);
> TextMessage newMessage = session.createTextMessage(text);
> newMessage.setStringProperty("inMessageId", message.getJMSMessageID());
> sender.send(newMessage);
> log.log(Level.INFO, " End of " + messageInfo + " in " + (System.currentTimeMillis() - time) + " ms");
> } catch (Exception t) {
> t.printStackTrace();
> log.log(Level.FATAL, t.getMessage(), t);
> } finally {
> if (con != null) {
> try {
> con.close();
> } catch (JMSException e) {
> log.log(Level.FATAL, e.getMessage(), e);
> }
> }
> }
> }
> }
> {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
13 years