April 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2953) AccumulateNode runs into NPE

by Alessandro Lazarotti (JIRA)

AccumulateNode runs into NPE ---------------------------- Key: JBRULES-2953 URL: https://issues.jboss.org/browse/JBRULES-2953 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Alessandro Lazarotti Assignee: Edson Tirelli Priority: Critical Fix For: 5.2.0.M1 Attachments: DroolsTest.java, JB2887.zip, SampleAlarmRules.drl A rule such as rule "average" when B( id < 10 ) $list: List() from collect ( A() over window:time(10s) ) Number( $avg: doubleValue ) from accumulate( A( $id : id ) from $list, average( $id ) ) then System.out.println( "average = " + $avg ); end runs into a NPE Caused by: java.lang.NullPointerException at org.drools.reteoo.AccumulateNode.getFirstMatch(AccumulateNode.java:967) at org.drools.reteoo.AccumulateNode.splitList(AccumulateNode.java:920) at org.drools.reteoo.AccumulateNode.removePreviousMatchesForLeftTuple(AccumulateNode.java:874) at org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:205) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateRetractLeftTuple(CompositeLeftTupleSinkAdapter.java:238) at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateRetractLeftTupleDestroyRightTuple(CompositeLeftTupleSinkAdapter.java:138) at org.drools.reteoo.AccumulateNode.retractLeftTuple(AccumulateNode.java:212) at org.drools.reteoo.ModifyPreviousTuples.retractTuples(ModifyPreviousTuples.java:111) at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:176) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:450) at org.drools.common.NamedEntryPoint.update(NamedEntryPoint.java:361) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183) at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196) at event.Rule_launch_0.defaultConsequence(Rule_launch_0.java:7) at event.Rule_launch_0DefaultConsequenceInvoker.evaluate(Rule_launch_0DefaultConsequenceInvoker.java:33) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:913) A null Parameter accctx is passed down from retractLeftTuple. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBJCA-546) Add creation time metrics to statistics

by Jesper Pedersen (JIRA)

Add creation time metrics to statistics --------------------------------------- Key: JBJCA-546 URL: https://issues.jboss.org/browse/JBJCA-546 Project: IronJacamar Issue Type: Task Components: Core Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.0.Beta6 Add * AverageCreationTime * MaxCreationTime * TotalCreationTime metrics to the statistics. These measures the time spent on physical connection creation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Deleted: (JGRP-694) Convert documentation to new DocBook format

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-694?page=com.atlassian.jira.plugin.s... ] Bela Ban deleted JGRP-694: -------------------------- > Convert documentation to new DocBook format > ------------------------------------------- > > Key: JGRP-694 > URL: https://issues.jboss.org/browse/JGRP-694 > Project: JGroups > Issue Type: Task > Reporter: Richard Achmatowicz > > Convert existing JGroups documentation shipped with the release to the new DocBook format. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2246) Incorrect business interface name passed to SingletonBeanRemoteInvocationHandler

by jaikiran pai (JIRA)

Incorrect business interface name passed to SingletonBeanRemoteInvocationHandler --------------------------------------------------------------------------------- Key: EJBTHREE-2246 URL: https://issues.jboss.org/browse/EJBTHREE-2246 Project: EJB 3.0 Issue Type: Bug Components: singleton Affects Versions: depchain-1.0.0-alpha-47 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: depchain-1.0.0 Creating this JIRA to track the fix that was done for JBCTS-1073. SingletonBeanRemoteInvocationHandler was being passed an incorrect business interface type name during construction. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2916) Unsupported Operation Exception crash due to (invalid) multi-restriction

by Wolfgang Laun (JIRA)

Unsupported Operation Exception crash due to (invalid) multi-restriction ------------------------------------------------------------------------ Key: JBRULES-2916 URL: https://issues.jboss.org/browse/JBRULES-2916 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M1 Reporter: Wolfgang Laun Assignee: Mark Proctor class Assignment { Class target; Class source; } rule isAssignable when Assignment( $target: target == (java.lang.Object.class) || == source ) then end Exception in thread "main" java.lang.UnsupportedOperationException: does not support method call isAllowed(Object object, InternalWorkingMemory workingMemoiry) at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:246) at org.drools.rule.OrCompositeRestriction.isAllowed(OrCompositeRestriction.java:41) at org.drools.rule.MultiRestrictionFieldConstraint.isAllowed(MultiRestrictionFieldConstraint.java:113) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:141) at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:378) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:335) at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:296) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:868) at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-9151) Need the ability to specify the bind address on interface criteria

by Scott Stark (JIRA)

Need the ability to specify the bind address on interface criteria ------------------------------------------------------------------ Key: JBAS-9151 URL: https://issues.jboss.org/browse/JBAS-9151 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Beta1 Reporter: Scott Stark Assignee: Scott Stark Fix For: 7.0.0.Beta2 There can be situations where an interface allows multiple bind addresses (loopback for example), but does not list all the bind addresses it allows. For example, setting up the default interface to use the loopback interface with an ip4 address of 127.0.250.5: <interfaces> <interface name="default"> <loopback value="127.0.250.5"/> </interface> ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1858) DLQ handling on JCA side causes duplicate redelivery to DLQ

by Toshiya Kobayashi (JIRA)

DLQ handling on JCA side causes duplicate redelivery to DLQ ----------------------------------------------------------- Key: JBMESSAGING-1858 URL: https://issues.jboss.org/browse/JBMESSAGING-1858 Project: JBoss Messaging Issue Type: Bug Components: AS Integration, Messaging Core Affects Versions: 1.4.7.GA Reporter: Toshiya Kobayashi JCA DLQ handling with JBM may end up with unexpected results. ==================== - Download and unzip attached reproducer.zip - Edit build.properties - ant deployQueue - ant deploy - ant run A client sends a meesage. The MDB causes rollback and then the messege goes to DLQ by JCA DLQ handling - Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console You will see MessageCount=1 (OK) - Check jboss.messaging.destination:name=A,service=Queue via jmx-console You will see MessageCount=1 and DeliveringCount = 1 (Not OK) - Stop and start jboss.messaging.destination:name=A,service=Queue via jmx-console You will see MessageCount=2 and DeliveringCount = 2 (Not OK) - Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console You will see MessageCount=2 (Not OK) ===================== You can find some discussions in JBAS-7465 and JBPAPP-3352. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Deleted: (JGRP-1275) Message: create enum for flags (OOB, NO_RELAY etc)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1275?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-1275: --------------------------- > Message: create enum for flags (OOB, NO_RELAY etc) > -------------------------------------------------- > > Key: JGRP-1275 > URL: https://issues.jboss.org/browse/JGRP-1275 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-1057) GroupRequest: turn mode (GET_ALL, GET_FIRST etc) into an enum

by Bela Ban (JIRA)

GroupRequest: turn mode (GET_ALL, GET_FIRST etc) into an enum ------------------------------------------------------------- Key: JGRP-1057 URL: https://jira.jboss.org/jira/browse/JGRP-1057 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 enum Mode {GET_FIRST, GET_ALL, GET_N, GET_MJORITY, GET_NONE} // etc Potentially move mode out of GroupRequest (to Global ?) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1303) JGroups 2.10 - Clustered Gossip Routers not working with TUNNEL

by vivek v (JIRA)

JGroups 2.10 - Clustered Gossip Routers not working with TUNNEL --------------------------------------------------------------- Key: JGRP-1303 URL: https://issues.jboss.org/browse/JGRP-1303 Project: JGroups Issue Type: Bug Affects Versions: 2.10 Environment: Linux, Windows Reporter: vivek v Assignee: Bela Ban We are using Tunnel protocol in JGroups 2.10 GA. I noticed sometimes nodes don't rejoin after GR has gone down and come back. Here is our scenario, 1) Two nodes: A, B 2) Two Gossip Routers: GR1 (port 4575), GR2 (4574) - only GR1 is up 3) Initially A and B are taking 4) Bring down GR1 5) Both A and B become singleton nodes 6) Bring back up GR1 7) Node A keep getting GR2 in its stubs list, {code} 2011-03-07 16:30:00,263 WARN [Timer-2,vivek,manager_172.16.4.29:3010] TUNNEL - failed sending a message to all members, GR used lt-vivek01.us.packetmotion.com/172.16.4.29:4574 2011-03-07 16:30:01,103 WARN [Timer-2,vivek,manager_172.16.4.29:3010] TUNNEL - failed sending a message to all members, GR used lt-vivek01.us.packetmotion.com/172.16.4.29:4574 2011-03-07 16:30:01,103 ERROR [Timer-2,vivek,manager_172.16.4.29:3010] TUNNEL - failed sending message to null (99 bytes): java.lang.Exception: None of the available stubs [RouterStub[localsocket=0.0.0.0/0.0.0.0:55732,router_host=lt-vivek01.us.packetmotion.com::4574,connected=false], RouterStub[localsocket=0.0.0.0/0.0.0.0:55732,router_host=lt-vivek01.us.packetmotion.com::4574,connected=false]] accepted a multicast message {code} Note, above Node A has GR2 twice in its stubs list. This causes node A to continue try sending message from the down GR and thus, we never get a new view with both nodes in it. I tried this test 5 times and out of that 3 failed and 2 passed (got new view after GR was up). In failed cases node A and B remained singleton even after the GR1 was up. I'm not sure where this is happening, the only place in Tunnel where we register GR is in "handleDownEvent(..)" {code} for (InetSocketAddress gr : gossip_router_hosts) { RouterStub stub = stubManager.createAndRegisterStub(gr.getHostName(), gr.getPort(), bind_addr); stub.setTcpNoDelay(tcp_nodelay); } {code} I looked at RouterSubManager code, but don't see how we would get two GR stubs for the same address. Looks like the RouterStub object itself might be getting changed at run-time - I don't see where, but that seems to be most obvious conclusion from this behavior. Looks like this will cause fail over not to work in a clustered GR setup. I would think if one GR goes down all the communication should start flowing through the second one, but for some reason this is not happening in certain scenarios. This becomes even more critical when using Tunnel protocol as now all traffic need to pass through GRs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
12
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2011