[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads
by John O'Hara (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1305?page=com.atlassian.jira.plugin... ]
John O'Hara commented on JBJCA-1305:
------------------------------------
I think that a configurable option would be a good idea, allowing users to determine how the semaphore should behave for different use cases.
> Performance degradation using fair semaphores in heavily contended workloads
> ----------------------------------------------------------------------------
>
> Key: JBJCA-1305
> URL: https://issues.jboss.org/browse/JBJCA-1305
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.1.Final
> Reporter: John O'Hara
> Assignee: Jesper Pedersen
>
> Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1305?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on JBJCA-1305:
--------------------------------------
One scenario to consider would be where the same datasource is used for multiple applications. In that case a server under heavy load may see certain applications not making progress in an orderly manner.
> Performance degradation using fair semaphores in heavily contended workloads
> ----------------------------------------------------------------------------
>
> Key: JBJCA-1305
> URL: https://issues.jboss.org/browse/JBJCA-1305
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.1.Final
> Reporter: John O'Hara
> Assignee: Jesper Pedersen
>
> Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1305?page=com.atlassian.jira.plugin... ]
Tom Jenkinson edited comment on JBJCA-1305 at 12/8/15 5:25 AM:
---------------------------------------------------------------
>From https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore....: "Generally, semaphores used to control resource access should be initialized as fair, to ensure that no thread is starved out from accessing a resource. When using semaphores for other kinds of synchronization control, the throughput advantages of non-fair ordering often outweigh fairness considerations."
As I understand it this semaphore is for accessing a resource so the guidance from the SDK is that fair would be desirable for that type of work load. However, if there are still use-cases that guard access to resources where none-fair is advantageous, a configurable option may therefore be appropriate.
was (Author: tomjenkinson):
>From https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore....: "Generally, semaphores used to control resource access should be initialized as fair, to ensure that no thread is starved out from accessing a resource. When using semaphores for other kinds of synchronization control, the throughput advantages of non-fair ordering often outweigh fairness considerations."
As I understand it this semaphore is for accessing a resource so the guidance from the SDK is that fair would be desirable for that type of work load. However, if there are still use-cases that guard access to resources where none-fair is advantageous, a configurable option may therefore be appropriate. Please can you create a forum thread to discuss this further?
> Performance degradation using fair semaphores in heavily contended workloads
> ----------------------------------------------------------------------------
>
> Key: JBJCA-1305
> URL: https://issues.jboss.org/browse/JBJCA-1305
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.1.Final
> Reporter: John O'Hara
> Assignee: Jesper Pedersen
>
> Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1305?page=com.atlassian.jira.plugin... ]
Tom Jenkinson commented on JBJCA-1305:
--------------------------------------
>From https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Semaphore....: "Generally, semaphores used to control resource access should be initialized as fair, to ensure that no thread is starved out from accessing a resource. When using semaphores for other kinds of synchronization control, the throughput advantages of non-fair ordering often outweigh fairness considerations."
As I understand it this semaphore is for accessing a resource so the guidance from the SDK is that fair would be desirable for that type of work load. However, if there are still use-cases that guard access to resources where none-fair is advantageous, a configurable option may therefore be appropriate. Please can you create a forum thread to discuss this further?
> Performance degradation using fair semaphores in heavily contended workloads
> ----------------------------------------------------------------------------
>
> Key: JBJCA-1305
> URL: https://issues.jboss.org/browse/JBJCA-1305
> Project: IronJacamar
> Issue Type: Enhancement
> Components: Core
> Affects Versions: WildFly/IronJacamar 1.3.1.Final
> Reporter: John O'Hara
> Assignee: Jesper Pedersen
>
> Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JBJCA-1305) Performance degradation using fair semaphores in heavily contended workloads
by John O'Hara (JIRA)
John O'Hara created JBJCA-1305:
----------------------------------
Summary: Performance degradation using fair semaphores in heavily contended workloads
Key: JBJCA-1305
URL: https://issues.jboss.org/browse/JBJCA-1305
Project: IronJacamar
Issue Type: Enhancement
Components: Core
Affects Versions: WildFly/IronJacamar 1.3.1.Final
Reporter: John O'Hara
Assignee: Jesper Pedersen
Under heavy contention, a fair semaphore causes performance degradation for threads trying to acquire a permit from the semaphore. Changing the semaphore to not fair alleviates the performance degradation under heavy contention.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 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)
10 years, 7 months