October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] Fixed in EAP 6.2.0.ER1. > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] from NEW to ON_QA > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-281: ------------------------------------------------ Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109] from NEW to ASSIGNED > no reevaluation of 'from collect' is performed > ---------------------------------------------- > > Key: DROOLS-281 > URL: https://issues.jboss.org/browse/DROOLS-281 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Richard Bourner > Assignee: Mark Proctor > Priority: Critical > Attachments: Drools6FromCollectIssue.zip > > > Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. > A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-275) RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)

by Tanguy Leroux (JIRA)

[ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin... ] Tanguy Leroux commented on DROOLS-275: -------------------------------------- Hi, Just to let you know, we encountered the same issue on 6.0.0.Beta2: java.lang.NullPointerException at org.drools.core.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedLeft(BeforeEvaluatorDefinition.java:318) at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67) at org.drools.core.common.TripleBetaConstraints.isAllowedCachedLeft(TripleBetaConstraints.java:91) at org.drools.core.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:183) at org.drools.core.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:243) at org.drools.core.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:125) at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:230) at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:498) at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:383) at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:365) at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:296) at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:265) at org.drools.core.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:469) at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:446) at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:249) at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:154) at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:114) at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:56) > RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock) > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-275 > URL: https://issues.jboss.org/browse/DROOLS-275 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR3 > Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40 > Reporter: Duncan Doyle > Assignee: Mario Fusco > Fix For: 6.0.0.CR5 > > > I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule: > rule "SimpleFactTimeWindow" > when > $s1: SimpleFact() from entry-point LinkyStream > $s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream > then > System.out.println("Rule fired, found 2 Facts within the time window."); > end > I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak: > java.lang.reflect.InvocationTargetException > 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:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:724) > Caused by: java.lang.NullPointerException > at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304) > at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80) > at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117) > at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150) > at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:547) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:533) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:335) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936) > at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233) > at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142) > at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7) > ... 6 more > Exception in ReteOO: > java.lang.reflect.InvocationTargetException > 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:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:724) > Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction@2e3aeda > at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131) > at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56) > at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140) > at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7) > ... 6 more > Caused by: java.lang.NullPointerException > at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324) > at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67) > at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108) > at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147) > at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99) > at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213) > at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73) > at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135) > at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125) > at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47) > at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502) > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387) > at org.drools.core.reteoo.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430) > at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266) > at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592) > at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223) > ... 12 more > What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected). > I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/ > I've added some Maven profiles so you can easily observe the behaviour: > - mvn -PallRuns exec:java : this runs both the persistence and the reload in the same JVM, no exception, everything works fine. > - mvn -PfirstRun exec:java : this runs the first part of the test, and saves the KieSession to a file. > - mvn -PsecondRun exec:java : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE. > All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-281: ------------------------------------------------ Richard Bourner <rbourner(a)redhat.com> made a comment on [bug 1015109|https://bugzilla.redhat.com/show_bug.cgi?id=1015109] Description of problem: Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. Version-Release number of selected component (if applicable): 6.0.0.CR4 How reproducible: Run the unit test in the attached project. 2 POM are provided: - 1 for 6.0.0.Beta2 : no problem with this one - 1 for 6.0.0.CR4 that reproduces the problem Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: > no reevaluation of 'from collect' is performed > ---------------------------------------------- > > Key: DROOLS-281 > URL: https://issues.jboss.org/browse/DROOLS-281 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Richard Bourner > Assignee: Mark Proctor > Priority: Critical > Attachments: Drools6FromCollectIssue.zip > > > Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. > A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-281: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1015109 > no reevaluation of 'from collect' is performed > ---------------------------------------------- > > Key: DROOLS-281 > URL: https://issues.jboss.org/browse/DROOLS-281 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Richard Bourner > Assignee: Mark Proctor > Priority: Critical > Attachments: Drools6FromCollectIssue.zip > > > Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. > A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2210) fix message endpoint isDeliveryTransacted

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-2210: --------------------------------- Summary: fix message endpoint isDeliveryTransacted Key: WFLY-2210 URL: https://issues.jboss.org/browse/WFLY-2210 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 8.0.0.Alpha4 Reporter: Jeff Mesnil Assignee: Jeff Mesnil Priority: Blocker Fix For: 8.0.0.Beta1 The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1713) MERGE3: view in header is too big in large clusters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1713?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1713. ---------------------------- Resolution: Done > MERGE3: view in header is too big in large clusters > --------------------------------------------------- > > Key: JGRP-1713 > URL: https://issues.jboss.org/browse/JGRP-1713 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > In MERGE3, as a response to a VIEW_REQ, a VIEW_RSP contains the entire view (not a delta view), and because this is returned in the header, we might run into the same issue as in https://issues.jboss.org/browse/JGRP-1710. > SOLUTION: > Move the view carried with a VIEW_RSP into the message body and add FRAG2 over the transport to fragment this message. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed

by Richard Bourner (JIRA)

[ https://issues.jboss.org/browse/DROOLS-281?page=com.atlassian.jira.plugin... ] Richard Bourner updated DROOLS-281: ----------------------------------- Attachment: Drools6FromCollectIssue.zip Maven Eclipse project demonstrating the issue with 2 rules and 1 unit test. > no reevaluation of 'from collect' is performed > ---------------------------------------------- > > Key: DROOLS-281 > URL: https://issues.jboss.org/browse/DROOLS-281 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.CR4 > Reporter: Richard Bourner > Assignee: Mark Proctor > Priority: Critical > Attachments: Drools6FromCollectIssue.zip > > > Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. > A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-281) no reevaluation of 'from collect' is performed

by Richard Bourner (JIRA)

Richard Bourner created DROOLS-281: -------------------------------------- Summary: no reevaluation of 'from collect' is performed Key: DROOLS-281 URL: https://issues.jboss.org/browse/DROOLS-281 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR4 Reporter: Richard Bourner Assignee: Mark Proctor Priority: Critical Using Drools 6.0.0.CR4, a problem has been found related to reevaluation of a condition that contains a 'from collect' statement. A unit test is provided demonstrating the issue using 2 rules. This unit test works fine using 6.0.0.Beta2. -- 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

12 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013