[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1016.
---------------------------------
Resolution: Rejected
The increased requirement in term of the occupied permgen space is not caused by the new phreak algorithm, but mainly by the fact that in drools 6 constraints are jitted, i.e. converted in bytecode and then evaluated in compiled mode instead of keep using mvel for each evaluation. You can have finer grained control over the permgen space used by drools setting the "drools.permgenThreshold" system property. This property represents the threshold of PermGen usage (in percentage) above which the engine stops JITting constraints and let them run in interpreted mode. In particular setting this property to 0 will completely turn off this optimization, but I don't suggest you to do so because the performance gain derived from evaluating the constraints in compiled mode is really relevant. My suggestion, at least on the long term, is to migrate to JDK 8 that no longer has a PermGen space separated from the normal heap space.
> Too much memory consumption while running code on drools6.
> ----------------------------------------------------------
>
> Key: DROOLS-1016
> URL: https://issues.jboss.org/browse/DROOLS-1016
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Vivek Hingorani
> Assignee: Mario Fusco
>
> The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm?
> We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same.
> Drools5 memory usage was 0.5GB per node with 0.5GB permgen space
> Drools6 memory usage is 1.3GB per node with 1GB permgen space.
> Node here is a jvm as we are using oracle coherence.
> If further details are needed , let me know.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1993) ENCRYPTAsymmetricTest fails on IBM jdk 1.8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1993?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1993:
---------------------------
Fix Version/s: 3.6.7
(was: 3.6.8)
> ENCRYPTAsymmetricTest fails on IBM jdk 1.8
> ------------------------------------------
>
> Key: JGRP-1993
> URL: https://issues.jboss.org/browse/JGRP-1993
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.6
> Environment: IBM jdk 1.8
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange fails on IBM jdk 1.8 (JGroups 3.6.6.Final):
> {code}
> Error Message
> expected [javax.crypto.spec.SecretKeySpec@174de] but found [com.ibm.crypto.provider.AESSecretKey@e562eaa8]
> Stacktrace
> java.lang.AssertionError
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:496)
> at org.testng.Assert.assertEquals(Assert.java:125)
> at org.testng.Assert.assertEquals(Assert.java:167)
> at org.jgroups.protocols.ENCRYPTAsymmetricTest.testKeyChangesDuringKeyServerChange(ENCRYPTAsymmetricTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1124)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.TestNG.privateMain(TestNG.java:1355)
> at org.testng.TestNG.main(TestNG.java:1324)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1982 at 1/4/16 5:54 AM:
--------------------------------------------------------
Even better: a ring buffer with {{high}} and {{low}} markers: unless {{low +1 > high}}, we never have to shift (copy) data toward the left. If that condition is true, we have to grow the buffer. Also consider shrinking (compacting) the ring buffer.
was (Author: belaban):
Even better: a ring buffer with {{high}} and {{llow}} markers: unless {{low +1 > high}}, we never have to shift (copy) data toward the left. If that condition is true, we have to grow the buffer. Also consider shrinking (compacting) the ring buffer.
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Stian Thorgersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Stian Thorgersen commented on WFLY-5921:
----------------------------------------
[~ctomc] can we make sure this makes it into 10.0.0.Final (or CR6 if there's one)? We need to upgrade to WF 10 and without this fixed the only solution I can see is that we need to stop using map-reduce with non-HA config and that will be a lot of work.
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5919) Wildfly 10 CR5 Regression - Schema not added to query
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5919?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5919:
------------------------------
Component/s: JPA / Hibernate
> Wildfly 10 CR5 Regression - Schema not added to query
> -----------------------------------------------------
>
> Key: WFLY-5919
> URL: https://issues.jboss.org/browse/WFLY-5919
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.CR5
> Reporter: John Ament
> Assignee: Scott Marlow
>
> My app, working fine in Wildfly 9.0.2 now fails in 10.0.0.CR5 (it was fine in earlier CR's)
> {code}
> 2016-01-03 08:30:43,626 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 87) SQL Error: 1046, SQLState: 3D000
> 2016-01-03 08:30:43,626 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ServerService Thread Pool -- 87) No database selected
> 2016-01-03 08:30:43,627 INFO [org.hibernate.event.internal.DefaultLoadEventListener] (ServerService Thread Pool -- 87) HHH000327: Error performing load command : org.hibernate.exception.GenericJDBCException: could not extract ResultSet
> {code}
> I turned on query debug, and the query being generated is now skipping the schema name defined in my entity's schema (I'm using MySQL)
> The config looks like this
> {code}
> @Table(name = "types", schema = "config")
> {code}
> I have an orm.xml file, I tried removing the default schema stanza without luck.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5921:
------------------------------
Component/s: Clustering
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Jason Greene
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-5921:
---------------------------------
Assignee: Paul Ferraro (was: Jason Greene)
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5921:
------------------------------
Affects Version/s: 10.0.0.CR5
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Jason Greene
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5921:
------------------------------
Fix Version/s: (was: 10.0.0.Final)
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Jason Greene
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Stian Thorgersen (JIRA)
Stian Thorgersen created WFLY-5921:
--------------------------------------
Summary: Locale cache set to simple cache automatically breaks map reduce
Key: WFLY-5921
URL: https://issues.jboss.org/browse/WFLY-5921
Project: WildFly
Issue Type: Bug
Reporter: Stian Thorgersen
Assignee: Jason Greene
Priority: Critical
Fix For: 10.0.0.Final
We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years