[JBoss JIRA] (DROOLS-1002) Drools Persist does not work with kmodule.xml configuration
by Artur Kronenberg (JIRA)
Artur Kronenberg created DROOLS-1002:
----------------------------------------
Summary: Drools Persist does not work with kmodule.xml configuration
Key: DROOLS-1002
URL: https://issues.jboss.org/browse/DROOLS-1002
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
Reporter: Artur Kronenberg
Assignee: Mario Fusco
Priority: Minor
Hi,
I ran into an issue yesterday that I believe to be a bug.
The persistence configuration through
ks.getStoreServices().newKieSession(kieBase, ksConf, env);
does not seem to be considering the configuration set on the kmodule. The kieBase in question is taken from the kmodule.xml configuration. The ksConf and environment are set up to support persistence.
I also wrote this up here with maybe some more detail and a workaround I am using: http://stackoverflow.com/questions/34134678/drools-kmodule-persistence-co...
It would be nice to be able to use Kmodule configuration (through xml) in combination with persistent sessions, and preferably maybe configure persistence on a per-session bases in the module. (I hope this makes sense, I am still fairly new to the drools world)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1001) Tabled Logic Programming-like mechanism to avoid infinite query recursion
by Fabian Meyer (JIRA)
Fabian Meyer created DROOLS-1001:
------------------------------------
Summary: Tabled Logic Programming-like mechanism to avoid infinite query recursion
Key: DROOLS-1001
URL: https://issues.jboss.org/browse/DROOLS-1001
Project: Drools
Issue Type: Feature Request
Reporter: Fabian Meyer
Assignee: Mark Proctor
Priority: Optional
Queries, such as a transitive closure, will lead to an infinite query recursion in PHREAK:
{code:drl}
declare Resource
name : String @key
end
declare partOf
subject : Resource @key
object : Resource @key
end
rule "init"
when
then
Resource a = new Resource("a");
Resource b = new Resource("b");
Resource c = new Resource("c");
insert (new partOf(a,b));
insert (new partOf(a,c));
end
rule "print container"
when
trans_partOf(part, container;)
then
System.out.println(part + " partOf " + container);
end
query trans_partOf(Resource part, Resource container)
// Find direct asserted fact
partOf(part,container;)
or
// Find the transitive closure
trans_partOf(part, p;)
and
trans_partOf(p, container;)
end
{code}
The algorithm can easily be rewritten as a production rule, resulting in a huge amount of materialized facts in large knowledge bases, which are probably never needed.
In Logic Programming, a mechanism called Tabled Logic Programming is used to avoid such infinite recursion. Maybe the tabling mechanism can be adapted to PHREAK, in order to avoid fact materilization when using production rules instead of queries.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1001) Tabled Logic Programming-like mechanism to avoid infinite query recursion
by Fabian Meyer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1001?page=com.atlassian.jira.plugi... ]
Fabian Meyer updated DROOLS-1001:
---------------------------------
Description:
Queries, such as a transitive closure, will lead to an infinite query recursion in PHREAK:
{code:drools}
declare Resource
name : String @key
end
declare partOf
subject : Resource @key
object : Resource @key
end
rule "init"
when
then
Resource a = new Resource("a");
Resource b = new Resource("b");
Resource c = new Resource("c");
insert (new partOf(a,b));
insert (new partOf(a,c));
end
rule "print container"
when
trans_partOf(part, container;)
then
System.out.println(part + " partOf " + container);
end
query trans_partOf(Resource part, Resource container)
// Find direct asserted fact
partOf(part,container;)
or
// Find the transitive closure
trans_partOf(part, p;)
and
trans_partOf(p, container;)
end
{code}
The algorithm can easily be rewritten as a production rule, resulting in a huge amount of materialized facts in large knowledge bases, which are probably never needed.
In Logic Programming, a mechanism called Tabled Logic Programming is used to avoid such infinite recursion. Maybe the tabling mechanism can be adapted to PHREAK, in order to avoid fact materilization when using production rules instead of queries.
was:
Queries, such as a transitive closure, will lead to an infinite query recursion in PHREAK:
{code:drl}
declare Resource
name : String @key
end
declare partOf
subject : Resource @key
object : Resource @key
end
rule "init"
when
then
Resource a = new Resource("a");
Resource b = new Resource("b");
Resource c = new Resource("c");
insert (new partOf(a,b));
insert (new partOf(a,c));
end
rule "print container"
when
trans_partOf(part, container;)
then
System.out.println(part + " partOf " + container);
end
query trans_partOf(Resource part, Resource container)
// Find direct asserted fact
partOf(part,container;)
or
// Find the transitive closure
trans_partOf(part, p;)
and
trans_partOf(p, container;)
end
{code}
The algorithm can easily be rewritten as a production rule, resulting in a huge amount of materialized facts in large knowledge bases, which are probably never needed.
In Logic Programming, a mechanism called Tabled Logic Programming is used to avoid such infinite recursion. Maybe the tabling mechanism can be adapted to PHREAK, in order to avoid fact materilization when using production rules instead of queries.
> Tabled Logic Programming-like mechanism to avoid infinite query recursion
> -------------------------------------------------------------------------
>
> Key: DROOLS-1001
> URL: https://issues.jboss.org/browse/DROOLS-1001
> Project: Drools
> Issue Type: Feature Request
> Reporter: Fabian Meyer
> Assignee: Mark Proctor
> Priority: Optional
>
> Queries, such as a transitive closure, will lead to an infinite query recursion in PHREAK:
> {code:drools}
> declare Resource
> name : String @key
> end
> declare partOf
> subject : Resource @key
> object : Resource @key
> end
> rule "init"
> when
> then
> Resource a = new Resource("a");
> Resource b = new Resource("b");
> Resource c = new Resource("c");
>
> insert (new partOf(a,b));
> insert (new partOf(a,c));
> end
> rule "print container"
> when
> trans_partOf(part, container;)
> then
> System.out.println(part + " partOf " + container);
> end
> query trans_partOf(Resource part, Resource container)
> // Find direct asserted fact
> partOf(part,container;)
> or
> // Find the transitive closure
> trans_partOf(part, p;)
> and
> trans_partOf(p, container;)
> end
> {code}
> The algorithm can easily be rewritten as a production rule, resulting in a huge amount of materialized facts in large knowledge bases, which are probably never needed.
> In Logic Programming, a mechanism called Tabled Logic Programming is used to avoid such infinite recursion. Maybe the tabling mechanism can be adapted to PHREAK, in order to avoid fact materilization when using production rules instead of queries.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-4941) WFLYCLEJBINF0005: Failed to cancel expiration/passivation of bean UnknownSessionID on primary owner.: ExecutionException: TimeoutException: timeout sending message
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4941?page=com.atlassian.jira.plugin.... ]
Michal Vinkler reopened WFLY-4941:
----------------------------------
[~pferraro] can you please respond to Ladislav's comment?
> WFLYCLEJBINF0005: Failed to cancel expiration/passivation of bean UnknownSessionID on primary owner.: ExecutionException: TimeoutException: timeout sending message
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4941
> URL: https://issues.jboss.org/browse/WFLY-4941
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha6, 10.0.0.Beta1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> Seen in our failover tests - this warning message is present in each server log in each test we have run so far.
> When each server in cluster is restarting after failover, other servers get CacheTopology change (the starting server is added) and the servers log this warning message many times:
> (for http session tests, the error identificator is WFLYCL*WEB*INF0005 rather than WFLYCL*EJB*INF0005)
> {code}
> [JBossINF] [0m[0m11:32:27,681 INFO [org.infinispan.CLUSTER] (remote-thread--p5-t12) ISPN000336: Finished cluster-wide rebalance for cache dist, topology id = 10
> [JBossINF] [0m[0m11:32:27,809 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t2) ISPN000310: Starting cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology CacheTopology{id=10, rebalanceId=5, currentCH=DefaultConsistentHash{ns=80, owners = (3)[perf19: 26+28, perf20: 27+26, perf21: 27+26]}, pendingCH=DefaultConsistentHash{ns=80, owners = (4)[perf19: 20+20, perf20: 20+20, perf21: 20+20, perf18: 20+20]}, unionCH=null, actualMembers=[perf19, perf20, perf21, perf18]}
> [JBossINF] [0m[0m11:32:28,347 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t6) ISPN000336: Finished cluster-wide rebalance for cache clusterbench-ee7.ear/clusterbench-ee7-ejb.jar, topology id = 10
> [JBossINF] [0m[33m11:32:28,624 WARN [org.wildfly.clustering.ejb.infinispan] (EJB default - 4) WFLYCLEJBINF0005: Failed to cancel expiration/passivation of bean UnknownSessionID [6855655451695655554868505252524957485470656956657048536848556569] on primary owner.: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException: timeout sending message to perf18
> [JBossINF] at org.jgroups.blocks.UnicastRequest.getValue(UnicastRequest.java:203)
> [JBossINF] at org.jgroups.blocks.UnicastRequest.get(UnicastRequest.java:212)
> [JBossINF] at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnNode(ChannelCommandDispatcher.java:151)
> [JBossINF] at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager$6.call(InfinispanBeanManager.java:237)
> [JBossINF] at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager$6.call(InfinispanBeanManager.java:232)
> [JBossINF] at org.wildfly.clustering.ee.infinispan.RetryingInvoker.invoke(RetryingInvoker.java:70)
> [JBossINF] at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.executeOnPrimaryOwner(InfinispanBeanManager.java:240)
> [JBossINF] at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.cancel(InfinispanBeanManager.java:217)
> [JBossINF] at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:267)
> [JBossINF] at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115)
> [JBossINF] at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> [JBossINF] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:635)
> [JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> [JBossINF] at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> [JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:331)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:69)
> [JBossINF] at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:202)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> [JBossINF] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [JBossINF] Caused by: java.util.concurrent.TimeoutException: timeout sending message to perf18
> [JBossINF] ... 54 more
> [JBossINF]
> {code}
> Server log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
> Client log:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-5588) DefaultContextServiceServletTestCase fails on IBM jdk
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-5588?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFLY-5588:
--------------------------------------
I am starting to doubt I'll ever get an answer for this - https://developer.ibm.com/answers/questions/240589/comibmenableclasscachi...
> DefaultContextServiceServletTestCase fails on IBM jdk
> -----------------------------------------------------
>
> Key: WFLY-5588
> URL: https://issues.jboss.org/browse/WFLY-5588
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.CR4
> Environment: java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480-20150129_02)
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150116_231420 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_GA_20150116_2030_B231420
> JIT - tr.r14.java_20150109_82886.02
> GC - R28_Java8_GA_20150116_2030_B231420_CMPRSS
> J9CL - 20150116_231420)
> JCL - 20150123_01 based on Oracle jdk8u31-b12
> Reporter: Petr Kremensky
> Assignee: Dominik Pospisil
> Attachments: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase-output.txt, org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.txt, TEST-org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.xml
>
>
> org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.testServlet fails on IBM jdk.
> {noformat}
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.182 sec <<< FAILURE! - in org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase
> testServlet(org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase) Time elapsed: 0.142 sec <<< ERROR!
> java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: HTTP Status 500 Response: <html><head><title>ERROR</title><style>body {
> font-family: "Lucida Grande", "Lucida Sans Unicode", "Trebuchet MS", Helvetica, Arial, Verdana, sans-serif;
> margin: 5px;
> }
> .header {
> background-image: linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -o-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -moz-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -webkit-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -ms-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
>
> background-image: -webkit-gradient(
> linear,
> left bottom,
> left top,
> color-stop(0.08, rgb(153,151,153)),
> color-stop(0.54, rgb(199,199,199))
> );
> color: black;
> padding: 2px;
> font-weight: normal;
> border: solid 1px;
> font-size: 170%;
> text-align: left;
> vertical-align: middle;
> height: 32px;
> }
> .error-div {
> display: inline-block; width: 32px; height: 32px; background: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAgAAAAIACH+pydAAAGGElEQVRYw8WXW2wcVxnHf+fM7NXrdXbdtZ3ipGqCEzvQKmlFoUggwkvvGBoaqVVV5Y0nkCoQPPCAhMQbQlzUh/IWHoh6QUVKZVLxUCGogKZRW9uJkyg0iVzZ2dhre9c7u7M7c87hYWc2M7t2bBASI306O/85+v7/7zLn24H/8yV2u/EcFNvwVNK2X0DKw1qpYaX1gCWlY0m5arRe8JQ6I2DmaVj/nwk4CxO2Zf1aw9dKo6N67+eOZHN7x0gViiSHBmlXa7hrazjLt1i+eKmxUi5bwpg/e8a8PA3X/msBr0MyJ+WvgFOffehY8v7HH5OW78HqGjgOtNrge2AnIJWAgQEYLqBsm3/NvKM/mZ1rYczpRa2/9x3w/iMBM1BCiHfuGRmZevClF9NJ5cP1m9B0+/aa3t/ZDNw3TtuSfPy737trK6sXtTGPPwOruxLwNhSEEHMHpqZGDz93wubKFdio3ZXUGNOHs2cIDh/g6pt/9G8uXLnlGPP5k1Dt5bN60m6lhXj34OTkxKET37SZm4d6oz/KgFRH7yOrBozbwlTWGf7ql6RZrWTcytrxaTj9Ro9OGb3JS/mz0nDxgYnnvmWbuUsdJ6FTY2JmImShqZA83N90UbOXOXDiG4nCcPFoTsqfbluCP8DenJQLx1/+7pBcXILaZl9qo2svFmalb48xkM9hxkf5+29+u9HSenIayn0ZyEr5i0NHpnKy7aGrtW6UehsLozRBRlRQEh3BwzLpWh3h++yfPJRLSvnzvhK8DkPamOl7n3nCUjcXtyXuK0X0WViaAFc9QtSNJe594uu2MubZGcjHBGTgqeFiQQml0K12nDgSpd4iyi4uRMci6Q8xJSWq7SGEZCg/qD14LCYgIcTzoxMHc6qygYk40aETKTFSdh2aANOWhbEsjJSYCK6C/V0LcH+9xvCB/TlbiBdCAXbQMJPZ/fvQjUbXEULAa6/1deyuh0dwNU+e7DSzEOhmi8xn9iI+ujgVE6ChlBwpYcqVjuIgA3IXBMYYtNbd30IIpJQI0ZEa+gPQnk9ieA8GSrESaGNyiWIBrVQntUHqdrq01iiluo0WilBK4fs+WutOr4S9YAyJoRzamMGYAClEve046ETyTr13EKCU6kZ+N4GNCxfwKpVOryQSuOUVhBCbsRIIuN1cWRkaSCfRrdaOTncijgltNPDn5xHZLIn7x3GNh4CVmADgcv3a9YmBY0cxm06nAQH31KlOao3BL5fxbtzAOE73hAt7JXb6RU7PGO44WK5Do1ZHw6WYAN+YM+X5S8dLXziWizVNvY5aWcFfWuq8Idsctb1Yr8DwmRwrUr1yfVMbcyYmwIWZ2mbdai9+gvfBAsaAbrUwrrtllLuJPibIGGQ2hUlIHLdlA+diTXgSqkKIt5b/OevL+8bwqlWU63anW3jyhaa4c9T2Hs0hrsL5EOCJQ/sov7/gS8Mb07AZEwDgav2D5aVy3eSziEL+Dllk0PSRcmcMqx6BUeGykINsksrttboPP4w2aVfACVhGiFevvft+I/XwJCad3DF6tc2MiD4zmRSZhyZY/OusI4V4JTqKYwIA6lr/2Gm6s5/+7UMv/egDmEyqL7VbRR/LViR6sikGvniYpffm2m6r/VFd65/0vqZ9R/tbsMeG+WKpMDL+lWMJ58Jl/NVqvOG26PAoDmCXhhg4epDl9+a9zUp1uQkPbvWfcMvZchbuEXAuk0kf2X/84YxpuDQv3kA5zW1fw9CswSyZyXFEJsmnf/m46bntuTY8+SxUtuLadri9CokxeEUK8WJhtJgaeeSIxG3RurWGv+Gg3RbaU5CwkOkU1lCWxFgBmbS4ff6qX7297rXh9Gn4/llobMcjtsFywACQ+zZMTsOP8vBIOpNS+bFiJj2cxx7MYg+k8ZwmrWqD9lqNjVvrTc9tWRtw/k345dtwFagDTmTdUUA2EDAYXffB2JPw6FH4ch7GUpCzIemD50J9A1Y+hH/8Cc4vdTq9Tud9D9dNOt+MajclyNL53xZmIhusmcBSQJLOd4UJnHqACzTppDy0kHizl/yuPRB5nggIM0A6IE4GuA34EQFtoBUQuwGm7kbwb+eaEEXmuV5dAAAAJXRFWHRjcmVhdGUtZGF0ZQAyMDA5LTExLTEwVDE5OjM4OjI0LTA3OjAwdDKp4gAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxMC0wMi0yMFQyMzoyNjoyNC0wNzowMC7DUNYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTAtMDEtMTFUMDg6NTc6MzUtMDc6MDCruapPAAAAMnRFWHRMaWNlbnNlAGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUHVibGljX2RvbWFpbj/96s8AAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMTEtMTBUMTk6Mzg6MjQtMDc6MDArg9/WAAAAGXRFWHRTb3VyY2UAVGFuZ28gSWNvbiBMaWJyYXJ5VM/tggAAADp0RVh0U291cmNlX1VSTABodHRwOi8vdGFuZ28uZnJlZWRlc2t0b3Aub3JnL1RhbmdvX0ljb25fTGlicmFyebzIrdYAAAAASUVORK5CYII=') left center no-repeat;
> }.error-text-div {
> display: inline-block; vertical-align: top; height: 32px;}.label { font-weight:bold; display: inline-block;}.value { display: inline-block;}</style></head><body><div class="header"><div class="error-div"></div><div class="error-text-div">Error processing request</div></div><div class="label">Context Path:</div><div class="value">/war-example</div><br/><div class="label">Servlet Path:</div><div class="value">/simple</div><br/><div class="label">Path Info:</div><div class="value">null</div><br/><div class="label">Query String:</div><div class="value">null</div><br/><b>Stack Trace</b><br/>javax.servlet.ServletException: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal<br/>org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestServlet.doGet(DefaultContextServiceTestServlet.java:74)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:687)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:790)<br/>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)<br/>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)<br/>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)<br/>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)<br/>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)<br/>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)<br/>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)<br/>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)<br/>io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)<br/>io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)<br/>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)<br/>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)<br/>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)<br/>io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)<br/>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)<br/>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)<br/>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)<br/>java.lang.Thread.run(Thread.java:785)<br/></body></html>
> at java.util.concurrent.FutureTask.report(FutureTask.java:133)
> at java.util.concurrent.FutureTask.get(FutureTask.java:217)
> at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:51)
> at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:81)
> at org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase.testServlet(DefaultContextServiceServletTestCase.java:67)
> Caused by: java.io.IOException: HTTP Status 500 Response: <html><head><title>ERROR</title><style>body {
> font-family: "Lucida Grande", "Lucida Sans Unicode", "Trebuchet MS", Helvetica, Arial, Verdana, sans-serif;
> margin: 5px;
> }
> .header {
> background-image: linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -o-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -moz-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -webkit-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
> background-image: -ms-linear-gradient(bottom, rgb(153,151,153) 8%, rgb(199,199,199) 54%);
>
> background-image: -webkit-gradient(
> linear,
> left bottom,
> left top,
> color-stop(0.08, rgb(153,151,153)),
> color-stop(0.54, rgb(199,199,199))
> );
> color: black;
> padding: 2px;
> font-weight: normal;
> border: solid 1px;
> font-size: 170%;
> text-align: left;
> vertical-align: middle;
> height: 32px;
> }
> .error-div {
> display: inline-block; width: 32px; height: 32px; background: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAABmJLR0QAAAAAAAD5Q7t/AAAACXBIWXMAAABIAAAASABGyWs+AAAACXZwQWcAAAAgAAAAIACH+pydAAAGGElEQVRYw8WXW2wcVxnHf+fM7NXrdXbdtZ3ipGqCEzvQKmlFoUggwkvvGBoaqVVV5Y0nkCoQPPCAhMQbQlzUh/IWHoh6QUVKZVLxUCGogKZRW9uJkyg0iVzZ2dhre9c7u7M7c87hYWc2M7t2bBASI306O/85+v7/7zLn24H/8yV2u/EcFNvwVNK2X0DKw1qpYaX1gCWlY0m5arRe8JQ6I2DmaVj/nwk4CxO2Zf1aw9dKo6N67+eOZHN7x0gViiSHBmlXa7hrazjLt1i+eKmxUi5bwpg/e8a8PA3X/msBr0MyJ+WvgFOffehY8v7HH5OW78HqGjgOtNrge2AnIJWAgQEYLqBsm3/NvKM/mZ1rYczpRa2/9x3w/iMBM1BCiHfuGRmZevClF9NJ5cP1m9B0+/aa3t/ZDNw3TtuSfPy737trK6sXtTGPPwOruxLwNhSEEHMHpqZGDz93wubKFdio3ZXUGNOHs2cIDh/g6pt/9G8uXLnlGPP5k1Dt5bN60m6lhXj34OTkxKET37SZm4d6oz/KgFRH7yOrBozbwlTWGf7ql6RZrWTcytrxaTj9Ro9OGb3JS/mz0nDxgYnnvmWbuUsdJ6FTY2JmImShqZA83N90UbOXOXDiG4nCcPFoTsqfbluCP8DenJQLx1/+7pBcXILaZl9qo2svFmalb48xkM9hxkf5+29+u9HSenIayn0ZyEr5i0NHpnKy7aGrtW6UehsLozRBRlRQEh3BwzLpWh3h++yfPJRLSvnzvhK8DkPamOl7n3nCUjcXtyXuK0X0WViaAFc9QtSNJe594uu2MubZGcjHBGTgqeFiQQml0K12nDgSpd4iyi4uRMci6Q8xJSWq7SGEZCg/qD14LCYgIcTzoxMHc6qygYk40aETKTFSdh2aANOWhbEsjJSYCK6C/V0LcH+9xvCB/TlbiBdCAXbQMJPZ/fvQjUbXEULAa6/1deyuh0dwNU+e7DSzEOhmi8xn9iI+ujgVE6ChlBwpYcqVjuIgA3IXBMYYtNbd30IIpJQI0ZEa+gPQnk9ieA8GSrESaGNyiWIBrVQntUHqdrq01iiluo0WilBK4fs+WutOr4S9YAyJoRzamMGYAClEve046ETyTr13EKCU6kZ+N4GNCxfwKpVOryQSuOUVhBCbsRIIuN1cWRkaSCfRrdaOTncijgltNPDn5xHZLIn7x3GNh4CVmADgcv3a9YmBY0cxm06nAQH31KlOao3BL5fxbtzAOE73hAt7JXb6RU7PGO44WK5Do1ZHw6WYAN+YM+X5S8dLXziWizVNvY5aWcFfWuq8Idsctb1Yr8DwmRwrUr1yfVMbcyYmwIWZ2mbdai9+gvfBAsaAbrUwrrtllLuJPibIGGQ2hUlIHLdlA+diTXgSqkKIt5b/OevL+8bwqlWU63anW3jyhaa4c9T2Hs0hrsL5EOCJQ/sov7/gS8Mb07AZEwDgav2D5aVy3eSziEL+Dllk0PSRcmcMqx6BUeGykINsksrttboPP4w2aVfACVhGiFevvft+I/XwJCad3DF6tc2MiD4zmRSZhyZY/OusI4V4JTqKYwIA6lr/2Gm6s5/+7UMv/egDmEyqL7VbRR/LViR6sikGvniYpffm2m6r/VFd65/0vqZ9R/tbsMeG+WKpMDL+lWMJ58Jl/NVqvOG26PAoDmCXhhg4epDl9+a9zUp1uQkPbvWfcMvZchbuEXAuk0kf2X/84YxpuDQv3kA5zW1fw9CswSyZyXFEJsmnf/m46bntuTY8+SxUtuLadri9CokxeEUK8WJhtJgaeeSIxG3RurWGv+Gg3RbaU5CwkOkU1lCWxFgBmbS4ff6qX7297rXh9Gn4/llobMcjtsFywACQ+zZMTsOP8vBIOpNS+bFiJj2cxx7MYg+k8ZwmrWqD9lqNjVvrTc9tWRtw/k345dtwFagDTmTdUUA2EDAYXffB2JPw6FH4ch7GUpCzIemD50J9A1Y+hH/8Cc4vdTq9Tud9D9dNOt+MajclyNL53xZmIhusmcBSQJLOd4UJnHqACzTppDy0kHizl/yuPRB5nggIM0A6IE4GuA34EQFtoBUQuwGm7kbwb+eaEEXmuV5dAAAAJXRFWHRjcmVhdGUtZGF0ZQAyMDA5LTExLTEwVDE5OjM4OjI0LTA3OjAwdDKp4gAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxMC0wMi0yMFQyMzoyNjoyNC0wNzowMC7DUNYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTAtMDEtMTFUMDg6NTc6MzUtMDc6MDCruapPAAAAMnRFWHRMaWNlbnNlAGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUHVibGljX2RvbWFpbj/96s8AAAAldEVYdG1vZGlmeS1kYXRlADIwMDktMTEtMTBUMTk6Mzg6MjQtMDc6MDArg9/WAAAAGXRFWHRTb3VyY2UAVGFuZ28gSWNvbiBMaWJyYXJ5VM/tggAAADp0RVh0U291cmNlX1VSTABodHRwOi8vdGFuZ28uZnJlZWRlc2t0b3Aub3JnL1RhbmdvX0ljb25fTGlicmFyebzIrdYAAAAASUVORK5CYII=') left center no-repeat;
> }.error-text-div {
> display: inline-block; vertical-align: top; height: 32px;}.label { font-weight:bold; display: inline-block;}.value { display: inline-block;}</style></head><body><div class="header"><div class="error-div"></div><div class="error-text-div">Error processing request</div></div><div class="label">Context Path:</div><div class="value">/war-example</div><br/><div class="label">Servlet Path:</div><div class="value">/simple</div><br/><div class="label">Path Info:</div><div class="value">null</div><br/><div class="label">Query String:</div><div class="value">null</div><br/><b>Stack Trace</b><br/>javax.servlet.ServletException: java.lang.ClassNotFoundException: org.wildfly.extension.undertow.security.AccountImpl$AccountPrincipal<br/>org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceTestServlet.doGet(DefaultContextServiceTestServlet.java:74)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:687)<br/>javax.servlet.http.HttpServlet.service(HttpServlet.java:790)<br/>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)<br/>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)<br/>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)<br/>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)<br/>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)<br/>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)<br/>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)<br/>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)<br/>io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)<br/>io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)<br/>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)<br/>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)<br/>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)<br/>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)<br/>io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)<br/>io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:788)<br/>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)<br/>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)<br/>java.lang.Thread.run(Thread.java:785)<br/></body></html>
> at org.jboss.as.test.integration.common.HttpRequest.processResponse(HttpRequest.java:156)
> at org.jboss.as.test.integration.common.HttpRequest.access$000(HttpRequest.java:45)
> at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:78)
> at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1989:
--------------------------------
Actually, buffer pools can be used more widely:
* Sending of message batches and single messages
** Also for {{TCP_NIO2}} once JGRP-1991 is in place
* Reception of message batches
** The message batches are de-serialized from the buffer, so the buffer can be reused immediately after deserialization (in {{TP.handleMessageBatch}})
* Reception of single messages
** Can we assume that - after the {{receive()}} callback returned - we can reuse the buffer?
** Asynchronous Invocation API?
** User cannot store the buffer somewhere, but needs to copy if it wants to hang on to the buffer
** Possibly make this configurable
> Bundlers: reuse send buffer when transport == sync.
> ---------------------------------------------------
>
> Key: JGRP-1989
> URL: https://issues.jboss.org/browse/JGRP-1989
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
> Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer).
> The code in the bundler should check for this, and copy if async or not copy if sync.
> Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet (not thread safe) storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1000?page=com.atlassian.jira.plugi... ]
Thomas Leung updated DROOLS-1000:
---------------------------------
Description:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"CacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
was:
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"DSLFpmlUniversalContainerCacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
> Race condition occured when executing Drools
> --------------------------------------------
>
> Key: DROOLS-1000
> URL: https://issues.jboss.org/browse/DROOLS-1000
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Thomas Leung
> Assignee: Mario Fusco
>
> We encountered soft timeout on threads executing Drools in our production environment.
> Below is the trimmed thread dump:
> "CacheWorker:2" id=988 State:RUNNABLE
> at java.util.HashMap.getEntry(HashMap.java:446)
> at java.util.HashMap.containsKey(HashMap.java:434)
> at java.util.HashSet.contains(HashSet.java:201)
> at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
> at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
> at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
> at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
> at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
> at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
> Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
> public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
> From the thread dump, it hanged at addEventListener method:
> public void addEventListener(KieBaseEventListener listener) {
> if (!kieBaseListeners.contains(listener)) {
> eventSupport.addEventListener(listener);
> kieBaseListeners.add(listener);
> }
> }
> When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
> [http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
> Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1000) Race condition occured when executing Drools
by Thomas Leung (JIRA)
Thomas Leung created DROOLS-1000:
------------------------------------
Summary: Race condition occured when executing Drools
Key: DROOLS-1000
URL: https://issues.jboss.org/browse/DROOLS-1000
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.2.0.Final
Reporter: Thomas Leung
Assignee: Mario Fusco
We encountered soft timeout on threads executing Drools in our production environment.
Below is the trimmed thread dump:
"DSLFpmlUniversalContainerCacheWorker:2" id=988 State:RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:446)
at java.util.HashMap.containsKey(HashMap.java:434)
at java.util.HashSet.contains(HashSet.java:201)
at org.drools.core.impl.KnowledgeBaseImpl.addEventListener(KnowledgeBaseImpl.java:252)
at org.jbpm.process.instance.ProcessRuntimeImpl.initProcessEventListeners(ProcessRuntimeImpl.java:303)
at org.jbpm.process.instance.ProcessRuntimeImpl.<init>(ProcessRuntimeImpl.java:115)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:10)
at org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl.newProcessRuntime(ProcessRuntimeFactoryServiceImpl.java:7)
at org.drools.core.runtime.process.ProcessRuntimeFactory.newProcessRuntime(ProcessRuntimeFactory.java:16)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.createProcessRuntime(StatefulKnowledgeSessionImpl.java:757)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:393)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.<init>(StatefulKnowledgeSessionImpl.java:286)
at org.drools.core.common.PhreakWorkingMemoryFactory.createWorkingMemory(PhreakWorkingMemoryFactory.java:21)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.newWorkingMemory(StatelessKnowledgeSessionImpl.java:127)
at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:302)
Analysis on the Drools code reveals a possible thread safety issue. A single instance of KnowledgeBaseImpl is shared amongst multiple kSessions but inside KnowledgeBaseImpl, it contains a HashSet storing the listeners:
public final Set<KieBaseEventListener> kieBaseListeners = new HashSet<KieBaseEventListener>();
>From the thread dump, it hanged at addEventListener method:
public void addEventListener(KieBaseEventListener listener) {
if (!kieBaseListeners.contains(listener)) {
eventSupport.addEventListener(listener);
kieBaseListeners.add(listener);
}
}
When 2 threads try to put into a hashmap at the same time and both trigger the map to be resized there is a small chance of created a corrupt internal data structure which results in infinite loops. There are a bunch of references on the net for this, here is one example:
[http://stackoverflow.com/questions/13695832/explain-the-timing-causing-ha...].
Our system heavily rely on Drools and we have high volume everyday, we really need help from Drools dev team and much appreciate if you can provide a patch for us. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months