January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-34) IllegalArgumentException while creating a new JPA knowledge session

by Lukáš Petrovický (JIRA)

[ https://issues.jboss.org/browse/DROOLS-34?page=com.atlassian.jira.plugin.... ] Lukáš Petrovický updated DROOLS-34: ----------------------------------- Labels: reported-by-qe (was: ) > IllegalArgumentException while creating a new JPA knowledge session > ------------------------------------------------------------------- > > Key: DROOLS-34 > URL: https://issues.jboss.org/browse/DROOLS-34 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Alpha9 > Reporter: Ivo Bek > Assignee: Mario Fusco > Labels: reported-by-qe > > Here (https://github.com/droolsjbpm/drools/blob/master/drools-persistence-jpa/s...) is incompatible constructor with KnowledgeBase instead of KieBase which causes the exception. Other methods that are using the constructor should be fixed as well. > FYI I create the session this way: > ksession = JPAKnowledgeService.newStatefulKnowledgeSession(kbase, null, env); // where kbase is instance of injected KieBase -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-760) Code style formatters are not actual

by Lukáš Petrovický (JIRA)

[ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin... ] Lukáš Petrovický updated DROOLS-760: ------------------------------------ Labels: reported-by-qe (was: ) > Code style formatters are not actual > ------------------------------------ > > Key: DROOLS-760 > URL: https://issues.jboss.org/browse/DROOLS-760 > Project: Drools > Issue Type: Task > Reporter: Tibor Zimányi > Assignee: Petr Široký > Priority: Minor > Labels: reported-by-qe > Attachments: code-styleQE.zip > > > Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. > There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. > Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-751) Different threads accessing LeftTuple fields that reference LeftTupleSet

by Lukáš Petrovický (JIRA)

[ https://issues.jboss.org/browse/DROOLS-751?page=com.atlassian.jira.plugin... ] Lukáš Petrovický updated DROOLS-751: ------------------------------------ Labels: reported-by-qe (was: ) > Different threads accessing LeftTuple fields that reference LeftTupleSet > ------------------------------------------------------------------------ > > Key: DROOLS-751 > URL: https://issues.jboss.org/browse/DROOLS-751 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final, 6.1.0.Final, 6.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Priority: Critical > Labels: reported-by-qe > Fix For: 6.3.0.Beta1 > > > In class LeftTupleSetsImpl there are missing nullchecks in some methods that contains handling LeftTuple instances. I.e. in method removeInsert there is LeftTuple variable previous that is not nullchecked. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-927) Persistence tests don't support Postgres Plus

by Lukáš Petrovický (JIRA)

[ https://issues.jboss.org/browse/DROOLS-927?page=com.atlassian.jira.plugin... ] Lukáš Petrovický updated DROOLS-927: ------------------------------------ Labels: reported-by-qe (was: ) > Persistence tests don't support Postgres Plus > --------------------------------------------- > > Key: DROOLS-927 > URL: https://issues.jboss.org/browse/DROOLS-927 > Project: Drools > Issue Type: Feature Request > Reporter: Tibor Zimányi > Assignee: Mark Proctor > Priority: Minor > Labels: reported-by-qe > > In drools-persistence-jpa module in PersistenceUtil, there is a method setupPoolingDataSource which sets up data source properties based on JDBC driver class. This method should be also aware of Postgres Plus driver, because it is also a supported database system. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-748) MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1).

by Lukáš Petrovický (JIRA)

[ https://issues.jboss.org/browse/DROOLS-748?page=com.atlassian.jira.plugin... ] Lukáš Petrovický updated DROOLS-748: ------------------------------------ Labels: reported-by-qe (was: ) > MultithreadTest.testSlidingTimeWindows() uses unreliable Thread.sleep(1). > ------------------------------------------------------------------------- > > Key: DROOLS-748 > URL: https://issues.jboss.org/browse/DROOLS-748 > Project: Drools > Issue Type: Bug > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Priority: Minor > Labels: reported-by-qe > > In MultithreadTest classes (there are two of them) method testSlidingTimeWindows() uses unreliable Thread.sleep(1) call for waiting for fact insertion. Thread.sleep(1) doesn't wait for exactly 1 millisecond, because there is overhead from thread scheduler. This overhead can be pretty large in contrast to expected 1ms sleep. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[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 commented on WFLY-5921: ----------------------------------- [~stianst] that is up to component lead, Paul, to which i assigned the issue. > 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)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1017: ----------------------------------- Summary: NPE deleting an expired event in equality mode Key: DROOLS-1017 URL: https://issues.jboss.org/browse/DROOLS-1017 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco Trying to delete an already expired event in equality mode causes the following NPE in the TMS: {code} java.lang.NullPointerException at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506) at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442) at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120) at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274) at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[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)

8 years, 4 months

1
0
0 / 0

[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)

8 years, 4 months

1
0
0 / 0

[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)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016