April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola commented on DROOLS-775: ----------------------------------------- After further investigation (profiling) I found that if I stub the {{ClassObjectTypeConf#checkPropertyListenerSupport}} method (which uses reflection internally) I experience a noticeable performance increase. The field {{supportsPropertyListeners}} is not used anywhere else. There's something I'm missing? > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-393) Clone a profile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-393?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-393: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Clone a profile > --------------- > > Key: WFCORE-393 > URL: https://issues.jboss.org/browse/WFCORE-393 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 2.0.0.Beta1 > > > Add the ability to clone a profile. > This could be a new "clone" operation on the existing profile resource, or perhaps a "clone-from" parameter on the existing "add" operation. Probably the former, as that will be more transformation-friendly. > Implementation will likely involve using the "describe" operation used for configuring managed domain servers and adding steps from the describe results directly on the HC instead of passing them to a server. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-401) Consider using a "describe" notion for providing the model to slaves on registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-401?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-401: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Consider using a "describe" notion for providing the model to slaves on registration > ------------------------------------------------------------------------------------ > > Key: WFCORE-401 > URL: https://issues.jboss.org/browse/WFCORE-401 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 2.0.0.Beta1 > > > When a slave HC registers, the master provides it a copy of the domain-wide model as a DMR tree. This has a weakness in that the Resource impl types that comprise that tree on the master side are not transmitted. If custom Resource impls are used, they may not be recreated on the slave. > Consider instead sending a list of mgmt ops, a la what we do with servers when starting from an HC. > This could potentially be limited to subsystems, with the core model sent as it is now. The core model is handled by core-AS code on the slave side, so we can reasonably ensure that code always uses the correct Resource type. There are places where we already do that. The bigger problem is subsystems. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 2.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-431) CLI should WARN about usage deprecated api

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-431?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-431: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > CLI should WARN about usage deprecated api > ------------------------------------------ > > Key: WFCORE-431 > URL: https://issues.jboss.org/browse/WFCORE-431 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Tomaz Cerar > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Beta1 > > > We added support for deprecating resources/attributes/operations/parameters some time ago. > I would be a good thing that we would warn users if they are using deprecated API. > Every resource/attribute/operation/param that is deprecated has extra element "deprecated" in metadata > With sub elements > - "since", which tells in what version it was deprecated > - "reason", text description why it is deprecated. > Reason in most cases also tells what is new replacement. > This should be only displayed in case of interactive shell usage. > Unless there is also some special CLI log file, it could be part of that even for non-interactive usage -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-459: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 1.0.0.CR1) > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 2.0.0.Beta1 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-553) Allow for alternative access control providers to be plugged into management.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-553?page=com.atlassian.jira.plugin.s... ] Brian Stansberry resolved WFLY-553. ----------------------------------- Fix Version/s: (was: 10.0.0.Alpha1) Resolution: Done I'm closing this as a presumed duplicate. > Allow for alternative access control providers to be plugged into management. > ----------------------------------------------------------------------------- > > Key: WFLY-553 > URL: https://issues.jboss.org/browse/WFLY-553 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Authorization, Realm_Management > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-775) Performance degradation with objects with many properties in working memory.

by Federico Bertola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-775?page=com.atlassian.jira.plugin... ] Federico Bertola updated DROOLS-775: ------------------------------------ Affects Version/s: (was: 6.3.0.Final) > Performance degradation with objects with many properties in working memory. > ---------------------------------------------------------------------------- > > Key: DROOLS-775 > URL: https://issues.jboss.org/browse/DROOLS-775 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Environment: Ubuntu 14.10 x64, jdk 8 > Reporter: Federico Bertola > Assignee: Mario Fusco > Labels: regression > Attachments: drools-test.zip > > > I experience some major performance degradation while migrating from drools 5.0.1 to 6.x. I'm inserting objects with many properties into the working memory and firing some very basic rules which will match against a very small subset of those properties. I expected that the older version of Drools, which uses pure reflection, to be somewhat slower than the newer, which uses some clever ASM optimization., but this is not the case. I've also noticed that if the required properties are scattered across multiple level of hierarchy, the performance issue will aggravate. > For example, after 100k iterations: > droosl 5.0.1 > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools5.DroolsPerformance.analized > count = 100000 > mean rate = 549.27 events/second > ... > drools 6.2.0.Final > -- Meters ---------------------------------------------------------------------- > org.acme.test.drools6.DroolsPerformance.analized > count = 100000 > mean rate = 198.58 events/second > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4569) EntityBean instances are leaked from pool on certain exceptions

by Alexey Makhmutov (JIRA)

[ https://issues.jboss.org/browse/WFLY-4569?page=com.atlassian.jira.plugin.... ] Alexey Makhmutov updated WFLY-4569: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7394 > EntityBean instances are leaked from pool on certain exceptions > --------------------------------------------------------------- > > Key: WFLY-4569 > URL: https://issues.jboss.org/browse/WFLY-4569 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final, 9.0.0.Beta2, 9.0.0.CR1 > Reporter: Alexey Makhmutov > > Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion. > Currently, following two cases are discovered: > # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won’t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call. > # If runtime exception (such as EJBException) is thrown from business method, then instance won’t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call. > These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ‘Failed to acquire permit’ exceptions. > Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4569) EntityBean instances are leaked from pool on certain exceptions

by Alexey Makhmutov (JIRA)

Alexey Makhmutov created WFLY-4569: -------------------------------------- Summary: EntityBean instances are leaked from pool on certain exceptions Key: WFLY-4569 URL: https://issues.jboss.org/browse/WFLY-4569 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.0.Beta2, 8.2.0.Final, 9.0.0.CR1 Reporter: Alexey Makhmutov Entity beans instances may not be returned to the pool after certain exceptions, which may lead to pool exhaustion. Currently, following two cases are discovered: # If any exception is thrown from ejbCreate method (e.g. duplicate record was found in the database), then bean instance won’t be returned to the pool, as there are no try-finally statements around call to ejbCreate in EntityBeanEjbCreateMethodInterceptor/EntityBeanRemoteViewInstanceFactory classes for this call. # If runtime exception (such as EJBException) is thrown from business method, then instance won’t be returned to the pool, as it will be marked as discarded by EntityBeanAssociatingInterceptor and both ReferenceCountingEntityCache/TransactionLocalEntityCache cache implementations just ignores discarded instance on release call. These problems actually make impossible using of pooled instances with Entity beans, as number of used beans from pool will be steadily increasing in production until pool is exhausted and clients start getting ‘Failed to acquire permit’ exceptions. Here is the set of integration tests, which examines the described behavior: https://github.com/Lerm/jboss-as/commit/f3eadd96d84dabc0a8b9c6c866ccfd5fe... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

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 April 2015