March 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBCACHE-11) Memory based eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ] Manik Surtani reassigned JBCACHE-11: ------------------------------------ Assignee: Mircea Markus (was: Manik Surtani) > Memory based eviction policy > ---------------------------- > > Key: JBCACHE-11 > URL: http://jira.jboss.com/jira/browse/JBCACHE-11 > Project: JBoss Cache > Issue Type: Feature Request > Components: Eviction > Reporter: Bela Ban > Assigned To: Mircea Markus > Fix For: 2.2.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > (maybe only in JDK 1.5, which has > triggers for low memory) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-881) Action component: loadTaskDefinition

by David Lloyd (JIRA)

Action component: loadTaskDefinition ------------------------------------ Key: JBPM-881 URL: http://jira.jboss.com/jira/browse/JBPM-881 Project: JBoss jBPM Issue Type: Sub-task Reporter: David Lloyd Assigned To: David Lloyd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-745) NullPointerException in modifyObject

by Dirk Bergstrom (JIRA)

NullPointerException in modifyObject ------------------------------------ Key: JBRULES-745 URL: http://jira.jboss.com/jira/browse/JBRULES-745 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1-m2 Environment: Trunk (revision 10170) Reporter: Dirk Bergstrom Assigned To: Edson Tirelli Fix For: 3.1-m2 I'm getting an exception while asserting objects into the working memory. Depending on the timing, I get different stacktraces leading up the same exception on the same generated class. I have 15 rules and three types of objects in the working memory. 2500 User objects, 37 Milestone objects, and 2000 RLI objects. If I assert all the Users and Milestones first, I get the first exception below during assertion of the RLI objects, at the 257th object asserted. If I arrange to skip that particular record, I can assert a few more before another record trips the bug. If I put a try/catch block around the assertion and continue after hitting an exception, I can assert about 1600 of the records successfully, and the others reliably throw (ie. if I try to assert them later). If I assert RLIs first, I get the second stacktrace during assertion of Milestones. Looks like the problem happens during execution of one or more rules. I'll attach the RLI class, and its parent class (which is also the parent of the other two classes). Exception in thread "RLIs Processor" java.lang.IncompatibleClassChangeError at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source) at java.util.HashMap.put(HashMap.java:418) at java.util.HashSet.add(HashSet.java:194) at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135) at org.drools.reteoo.CollectNode.assertObject(CollectNode.java:212) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145) at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:304) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176) at org.drools.reteoo.Rete.assertObject(Rete.java:121) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68) at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729) at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548) Exception in thread "Milestones and NPI Processor" java.lang.IncompatibleClassChangeError at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source) at java.util.HashMap.put(HashMap.java:418) at java.util.HashSet.add(HashSet.java:194) at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135) at org.drools.reteoo.CompositeTupleSinkAdapter.propagateAssertTuple(CompositeTupleSinkAdapter.java:30) at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:116) at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55) at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:147) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176) at org.drools.reteoo.Rete.assertObject(Rete.java:121) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196) at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68) at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729) at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548) at net.juniper.dash.data.DataSource.reconcileAssertedRecords(DataSource.java:190) at net.juniper.dash.data.DataSource.populateRecords(DataSource.java:150) at net.juniper.dash.Updater$DataSourceProcessor.work(Updater.java:181) at net.juniper.dash.Refresher.run(Refresher.java:70) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBCACHE-11) Memory based eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ] Manik Surtani updated JBCACHE-11: --------------------------------- Fix Version/s: 2.2.0.GA (was: 2.1.0.GA) Affects Version/s: (was: 2.0.0.GA) Assignee: Manik Surtani (was: Ben Wang) Complexity: Medium > Memory based eviction policy > ---------------------------- > > Key: JBCACHE-11 > URL: http://jira.jboss.com/jira/browse/JBCACHE-11 > Project: JBoss Cache > Issue Type: Feature Request > Components: Eviction > Reporter: Bela Ban > Assigned To: Manik Surtani > Priority: Optional > Fix For: 2.2.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > (maybe only in JDK 1.5, which has > triggers for low memory) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-11) Memory based eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ] Manik Surtani updated JBCACHE-11: --------------------------------- Priority: Major (was: Optional) > Memory based eviction policy > ---------------------------- > > Key: JBCACHE-11 > URL: http://jira.jboss.com/jira/browse/JBCACHE-11 > Project: JBoss Cache > Issue Type: Feature Request > Components: Eviction > Reporter: Bela Ban > Assigned To: Manik Surtani > Fix For: 2.2.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > (maybe only in JDK 1.5, which has > triggers for low memory) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-847) When a suspended workflow is resumed, all its finished are getting opened.

by Syed Arshad (JIRA)

When a suspended workflow is resumed, all its finished are getting opened. -------------------------------------------------------------------------- Key: JBPM-847 URL: http://jira.jboss.com/jira/browse/JBPM-847 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1 Environment: Linux, Tomcat and Java Reporter: Syed Arshad Assigned To: Tom Baeyens Priority: Critical When suspended workflow is resumed, all it is existing tasks which are already completed are getting reopended. What i see the details in jbpm_taks table during its suspended state is: isSuspended = true and isOpen=false BUT after resuming the status is isSuspended=false and isOpen=true. The system is in production and this is really panicy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBCACHE-194) Provide configurable eviction thread priority boost

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-194?page=all ] Manik Surtani updated JBCACHE-194: ---------------------------------- Component/s: Eviction > Provide configurable eviction thread priority boost > --------------------------------------------------- > > Key: JBCACHE-194 > URL: http://jira.jboss.com/jira/browse/JBCACHE-194 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3 > Reporter: Brian Dueck > Assigned To: Manik Surtani > Fix For: 2.1.0.GA > > Attachments: LRUPolicy.java, LRUPolicy.java, LRUPolicy.java > > > In environments where there there are many TreeCache client threads accessing the cache concurrently, the eviction thread may become starved. In this situation, even setting the wakeupInterval to 1 or 2 seconds does not help because the OS won't allocate proportionally very much time to the waiting eviction thread in comparison to the other TreeCache client threads. > While there are some "fancy" solutions to this problem involving client threads being put to work to perform eviction, or having multiple eviction threads, one solution that help partially alleviate the problem is to boost the thread priority of the eviction thread. > This provides a clue to the OS that allows the eviction thread to be scheduled more CPU time relative to other threads in a CPU resource constrained situation. > This change involves switching from using the Java Timer object to using the Oswego ClockDaemon class instead. I've attached here a protoype implementation that reads a new XML configuration parameter (evictionPriorityBoost - if you can think of a better name, go ahead and rename it) and then boosts the eviction thread priority accordingly. > Here's an example of the new config param: > <attribute name="EvictionPolicyConfig"> > <config> > <attribute name="wakeUpIntervalSeconds">5</attribute> >  > <attribute name="evictionPriorityBoost">2</attribute> >  > <region name="/_default_"> > <attribute name="maxNodes">5000000</attribute> > <attribute name="timeToLiveSeconds">10</attribute> > </region> > </config> > </attribute> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-11) Memory based eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=all ] Manik Surtani updated JBCACHE-11: --------------------------------- Component/s: Eviction > Memory based eviction policy > ---------------------------- > > Key: JBCACHE-11 > URL: http://jira.jboss.com/jira/browse/JBCACHE-11 > Project: JBoss Cache > Issue Type: Feature Request > Components: Eviction > Affects Versions: 2.0.0.GA > Reporter: Bela Ban > Assigned To: Ben Wang > Priority: Optional > Fix For: 2.1.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > (maybe only in JDK 1.5, which has > triggers for low memory) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-552) Use "/" to replace "__DEFAULT__" in eviction policy

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-552?page=all ] Manik Surtani updated JBCACHE-552: ---------------------------------- Component/s: Eviction > Use "/" to replace "__DEFAULT__" in eviction policy > --------------------------------------------------- > > Key: JBCACHE-552 > URL: http://jira.jboss.com/jira/browse/JBCACHE-552 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Eviction > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.1.0.GA > > Original Estimate: 4 days > Remaining Estimate: 4 days > > Came up with a suggestion from Bela's training course. Currently since the region specification is order important, so use of "/" can be dangerours if not specified correctly. Btu can we order it internally during eviction policy specification such that user can order them randomly? What's the implication for troubleshooting? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4222) Add support for stopping ILs triggering the ExceptionListener - UIL2

by Adrian Brock (JIRA)

Add support for stopping ILs triggering the ExceptionListener - UIL2 -------------------------------------------------------------------- Key: JBAS-4222 URL: http://jira.jboss.com/jira/browse/JBAS-4222 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.0.4RC1 Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-4.2.1.CR1 As per the super task which is a fix to make sure client exception listeners get triggered if somebody stops the server, this same behaviour should occur if somebody just stops the IL. This involves making each IL keep track of their respective connections. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
3
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 March 2007