[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)
11 years
[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)
11 years
[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)
11 years
[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:
------------------------------------
Description:
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
...
was:
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 that 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
...
> 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, 6.3.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)
11 years
[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:
------------------------------------
Description:
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 that 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
...
was:
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 that 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 10ok 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
...
> 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, 6.3.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 that 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)
11 years