March 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-2238) Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/JBRULES-2238?page=com.atlassian.jira.plug... ] Geoffrey De Smet resolved JBRULES-2238. --------------------------------------- Fix Version/s: 6.0.0.Alpha1 (was: FUTURE) Resolution: Done Could reproduce performance loss with a recent version of drools > Accumulate should be implemented with left-input incremental so they don't start from scratch on every left-input retraction/assertion > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBRULES-2238 > URL: https://issues.jboss.org/browse/JBRULES-2238 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: drools-core (expert) > Affects Versions: 5.0.1.FINAL > Reporter: Geoffrey De Smet > Assignee: Edson Tirelli > Fix For: 6.0.0.Alpha1 > > > The current accumulate implementation has a severe performance loss in the drools-solver context. > Edson said that this issue could be the culprit. > However, for this to be implemented the true modify feature should first be implemented. > See the discussion "Why is this DRL twice as slow?" on the dev user list. > From IRC: > <ge0ffrey> more and more of my experiments show the poisones nature of accumulate for drools-solver. Probably because they are backwards chained (as I understand it?). Of course accummulate is great for many use cases, just not drools-solver. > <ge0ffrey> The problem is, I have no way to workaround them. I need the sum of my logically inserted objects. > <etirelli> ge0ffrey: no, accumulate are implemented as forward chain as usual > <etirelli> the problem is that a left-input retraction on an accumulate node will throw away any result and a leftinput assert will recalculate everything from scratch > <ge0ffrey> What do you mean by "must fully recalculate"? > <etirelli> mean from scratch > <ge0ffrey> Why does it do that? > <etirelli> remember that modify = retract+assert > <ge0ffrey> And right-input retractions won't recalculate everything from scratch? > <etirelli> no... right input are incremental > <ge0ffrey> would making leftinput assert incremental too be possible? > <etirelli> ge0ffrey: the only way to do left-input incremental is with a feature called "true modify" -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6778) Configure EJB3/MDB with an individual thread pool for each EJB.

by Weixing Sun (JIRA)

[ https://issues.jboss.org/browse/AS7-6778?page=com.atlassian.jira.plugin.s... ] Weixing Sun commented on AS7-6778: ---------------------------------- Thanks for your comments, David! it sounds strange to know JBoss is showing JBossThread.run() instead of the real logical code in my profiling tools(visualvm). Then, would you please let me know how I can see what's happening after the run() method called? > Configure EJB3/MDB with an individual thread pool for each EJB. > --------------------------------------------------------------- > > Key: AS7-6778 > URL: https://issues.jboss.org/browse/AS7-6778 > Project: Application Server 7 > Issue Type: Feature Request > Components: EJB > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Jeremy Whiting > Assignee: jaikiran pai > > For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application. > For example > PoolA - EJB Dog > PoolB - EJB Cat > To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBRULES-3657) Eval bytecode not correctly generated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3657?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on JBRULES-3657: -------------------------------------------------- Radovan Synek <rsynek(a)redhat.com> made a comment on [bug 860698|https://bugzilla.redhat.com/show_bug.cgi?id=860698] Verified on 5.3.1.BRMS roll-up #1 > Eval bytecode not correctly generated > ------------------------------------- > > Key: JBRULES-3657 > URL: https://issues.jboss.org/browse/JBRULES-3657 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.3.1.Final > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 5.3.2.Final > > > When a declaration does a double dereferencing, with the value of the method returned by the second dereferencing being a primitive type, the bytecode of the eval class using it is not correctly generated and causes, when instanced, an Exception like the following: > Exception in thread "main" java.lang.VerifyError: (class: gov/ssa/asa/rules/Rule_vhrGroupingByLocationEval0Invoker, method: evaluate signature: (Lorg/drools/spi/Tuple;[Lorg/drools/rule/Declaration;Lorg/drools/WorkingMemory;Ljava/lang/Object;)Z) Expecting to find integer on stack > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > at java.lang.Class.getConstructor0(Class.java:2699) > at java.lang.Class.newInstance0(Class.java:326) > at java.lang.Class.newInstance(Class.java:308) > at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:413) -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBRULES-3657) Eval bytecode not correctly generated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3657?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on JBRULES-3657: -------------------------------------------------- Radovan Synek <rsynek(a)redhat.com> changed the Status of [bug 860698|https://bugzilla.redhat.com/show_bug.cgi?id=860698] from ON_QA to VERIFIED > Eval bytecode not correctly generated > ------------------------------------- > > Key: JBRULES-3657 > URL: https://issues.jboss.org/browse/JBRULES-3657 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.3.1.Final > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 5.3.2.Final > > > When a declaration does a double dereferencing, with the value of the method returned by the second dereferencing being a primitive type, the bytecode of the eval class using it is not correctly generated and causes, when instanced, an Exception like the following: > Exception in thread "main" java.lang.VerifyError: (class: gov/ssa/asa/rules/Rule_vhrGroupingByLocationEval0Invoker, method: evaluate signature: (Lorg/drools/spi/Tuple;[Lorg/drools/rule/Declaration;Lorg/drools/WorkingMemory;Ljava/lang/Object;)Z) Expecting to find integer on stack > at java.lang.Class.getDeclaredConstructors0(Native Method) > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389) > at java.lang.Class.getConstructor0(Class.java:2699) > at java.lang.Class.newInstance0(Class.java:326) > at java.lang.Class.newInstance(Class.java:308) > at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:413) -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6778) Configure EJB3/MDB with an individual thread pool for each EJB.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6778?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6778: ---------------------------------- The reason you see 90% of CPU cycles being spent in JBossThread.run() is that nearly all of our threads are JBossThreads, thus all work that the server does will ultimately show up as being in this method one way or another. It is not indicative of a problem - indeed if you saw 0% usage in JBossThread.run(), it would mean that the server isn't doing anything at all. > Configure EJB3/MDB with an individual thread pool for each EJB. > --------------------------------------------------------------- > > Key: AS7-6778 > URL: https://issues.jboss.org/browse/AS7-6778 > Project: Application Server 7 > Issue Type: Feature Request > Components: EJB > Affects Versions: EAP 6.1.0.Alpha (7.2.0.Final) > Reporter: Jeremy Whiting > Assignee: jaikiran pai > > For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application. > For example > PoolA - EJB Dog > PoolB - EJB Cat > To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5884) CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5884?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5884: ---------------------------------------------- Martin Simka <msimka(a)redhat.com> changed the Status of [bug 901159|https://bugzilla.redhat.com/show_bug.cgi?id=901159] from ON_QA to VERIFIED > CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1 > ------------------------------------------------------------------------------------------------------------ > > Key: AS7-5884 > URL: https://issues.jboss.org/browse/AS7-5884 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Wolf-Dieter Fink > Assignee: Kabir Khan > Priority: Critical > Labels: deployers, domain, eap, jboss > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > If a deployment in a domain is the same file, deployed with different names to different server-groups, it become the same SHA1. > In that case the stored content will not be updated and the <deployments> section become a new entry which is used by the second server group. > But if one of the deployments will be undeployed or updated the content is complete removed but the second deployment entry is still available. > The second deployment can be used as long as there is a action to it (e.g. restart). > In that case a FATAL error is thrown: > [Host Controller] 11:43:36,493 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "prod.ear")]) - failure description: "JBAS010876: No deployment content with hash 0807c2c28e5feebb8dfb905788e53b104ecb89fc is available in the deployment content repository for deployment 'prod.ear'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 11:43:36,496 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5884) CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5884?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5884: ---------------------------------------------- Martin Simka <msimka(a)redhat.com> made a comment on [bug 901159|https://bugzilla.redhat.com/show_bug.cgi?id=901159] verified 6.1.0.ER3 > CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1 > ------------------------------------------------------------------------------------------------------------ > > Key: AS7-5884 > URL: https://issues.jboss.org/browse/AS7-5884 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.3.Final (EAP) > Reporter: Wolf-Dieter Fink > Assignee: Kabir Khan > Priority: Critical > Labels: deployers, domain, eap, jboss > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > If a deployment in a domain is the same file, deployed with different names to different server-groups, it become the same SHA1. > In that case the stored content will not be updated and the <deployments> section become a new entry which is used by the second server group. > But if one of the deployments will be undeployed or updated the content is complete removed but the second deployment entry is still available. > The second deployment can be used as long as there is a action to it (e.g. restart). > In that case a FATAL error is thrown: > [Host Controller] 11:43:36,493 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "prod.ear")]) - failure description: "JBAS010876: No deployment content with hash 0807c2c28e5feebb8dfb905788e53b104ecb89fc is available in the deployment content repository for deployment 'prod.ear'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 11:43:36,496 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5976) The command :reload does not check the new configuration, and will cause server crashes if that config is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5976?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5976: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> changed the Status of [bug 901192|https://bugzilla.redhat.com/show_bug.cgi?id=901192] from ON_QA to ASSIGNED > The command :reload does not check the new configuration, and will cause server crashes if that config is broken > ---------------------------------------------------------------------------------------------------------------- > > Key: AS7-5976 > URL: https://issues.jboss.org/browse/AS7-5976 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > Priority: Critical > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > The command :reload does not check the new configuration, and will cause server crashes if that config is broken -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5976) The command :reload does not check the new configuration, and will cause server crashes if that config is broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-5976?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-5976: ---------------------------------------------- Jakub Cechacek <jcechace(a)redhat.com> made a comment on [bug 901192|https://bugzilla.redhat.com/show_bug.cgi?id=901192] Unless I'm doing something wrong the behavior in ER3 is exactly the same as described in bug report. After performing /host=master:reload with the corrupted host.xml server process will quit with ConfigurationPersistenceException. Changing status back to assigned > The command :reload does not check the new configuration, and will cause server crashes if that config is broken > ---------------------------------------------------------------------------------------------------------------- > > Key: AS7-5976 > URL: https://issues.jboss.org/browse/AS7-5976 > Project: Application Server 7 > Issue Type: Bug > Components: Domain Management > Affects Versions: 7.1.2.Final (EAP) > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > Priority: Critical > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > The command :reload does not check the new configuration, and will cause server crashes if that config is broken -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-6814) JBOSS 7.1.1 server /tmp/vfs folder gets full

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6814?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6814: ---------------------------------- Is this bug a duplicate of AS7-1805? > JBOSS 7.1.1 server /tmp/vfs folder gets full > -------------------------------------------- > > Key: AS7-6814 > URL: https://issues.jboss.org/browse/AS7-6814 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate, JSF > Affects Versions: 7.1.1.Final > Reporter: Mahesh Khatal > Assignee: David Lloyd > -- 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, 1 month

1
0
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 2013