October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1887 at 10/6/14 6:04 AM: --------------------------------------------------------- Cause: https://issues.jboss.org/browse/JGRP-964, related to shared transport. When multiple channels are started in parallel, the first channel creates the shared transport. However, subsequent channels might fail accessing the shared transport's fields (such as the timer), as the shared transport hasn't yet been fully created (e.g. the timer hasn't yet been instantiated). was (Author: belaban): Cause: https://issues.jboss.org/browse/JGRP-964. Need to investigate whether this is still needed. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1887: -------------------------------- Cause: https://issues.jboss.org/browse/JGRP-964. Need to investigate whether this is still needed. > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1149623|https://bugzilla.redhat.com/show_bug.cgi?id=1149623] from NEW to CLOSED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from NEW to ASSIGNED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1139197, https://bugzilla.redhat.com/show_bug.cgi?id=1139202) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3934) TimerServiceImpl should use message patterns for debug logging

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-3934?page=com.atlassian.jira.plugin.... ] Philippe Marschall closed WFLY-3934. ------------------------------------ > TimerServiceImpl should use message patterns for debug logging > -------------------------------------------------------------- > > Key: WFLY-3934 > URL: https://issues.jboss.org/browse/WFLY-3934 > Project: WildFly > Issue Type: Patch > Components: EJB > Reporter: Philippe Marschall > Assignee: David Lloyd > Fix For: 9.0.0.Beta1 > > > When running an allocation profile on our WildFly AS instance debug logging in {{TimerServiceImpl}} showed up. The problem is that {{TimerServiceImpl}} unconditionally generates debug strings using string concatenation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3934) TimerServiceImpl should use message patterns for debug logging

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-3934?page=com.atlassian.jira.plugin.... ] Philippe Marschall updated WFLY-3934: ------------------------------------- Fix Version/s: 9.0.0.Beta1 > TimerServiceImpl should use message patterns for debug logging > -------------------------------------------------------------- > > Key: WFLY-3934 > URL: https://issues.jboss.org/browse/WFLY-3934 > Project: WildFly > Issue Type: Patch > Components: EJB > Reporter: Philippe Marschall > Assignee: David Lloyd > Fix For: 9.0.0.Beta1 > > > When running an allocation profile on our WildFly AS instance debug logging in {{TimerServiceImpl}} showed up. The problem is that {{TimerServiceImpl}} unconditionally generates debug strings using string concatenation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3934) TimerServiceImpl should use message patterns for debug logging

by Philippe Marschall (JIRA)

[ https://issues.jboss.org/browse/WFLY-3934?page=com.atlassian.jira.plugin.... ] Philippe Marschall commented on WFLY-3934: ------------------------------------------ Merged into 9 Alpha 2 but it couldn't be selected. > TimerServiceImpl should use message patterns for debug logging > -------------------------------------------------------------- > > Key: WFLY-3934 > URL: https://issues.jboss.org/browse/WFLY-3934 > Project: WildFly > Issue Type: Patch > Components: EJB > Reporter: Philippe Marschall > Assignee: David Lloyd > Fix For: 9.0.0.Beta1 > > > When running an allocation profile on our WildFly AS instance debug logging in {{TimerServiceImpl}} showed up. The problem is that {{TimerServiceImpl}} unconditionally generates debug strings using string concatenation. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3936) Unnecessary transactions for non-existent lifecycle event callbacks.

by Sławomir Wojtasiak (JIRA)

[ https://issues.jboss.org/browse/WFLY-3936?page=com.atlassian.jira.plugin.... ] Sławomir Wojtasiak updated WFLY-3936: ------------------------------------- Description: I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly does not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them. The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks. Provided pull request fixes the same problem for stateful session beans too. In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that. I have prepared a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop: Before the fix: Three calls in a row: 33 sec, 31 sec, 31 sec. After the fix: Three calls in a row: 24 sec, 22 sec, 22 sec. It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix. was: I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly does not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them. The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks. Provided pull request fixes the same problem for stateful session beans too. In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that. I have prepare a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop: Before the fix: Three calls in a row: 33 sec, 31 sec, 31 sec. After the fix: Three calls in a row: 24 sec, 22 sec, 22 sec. It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix. > Unnecessary transactions for non-existent lifecycle event callbacks. > -------------------------------------------------------------------- > > Key: WFLY-3936 > URL: https://issues.jboss.org/browse/WFLY-3936 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final, 8.2.0.CR1 > Environment: WildFly 8.2.0.CR1 + OracleJDK7 + Gentoo Linux > Reporter: Sławomir Wojtasiak > Assignee: David Lloyd > > I have found an issue in the semantic of the stateless and stateful session beans initialization policy. Every time a component is configured regardless of the existence of the lifecycle event callbacks, lifecycle interceptors responsible for transactions management are registered and they create new transactions suspending the current ones every time components are created and destroyed. Wildfly does not use the component pool for stateless session beans by default, so whenever we call a method on a stateless component which does not have any lifecycle callback handlers two unneccessary transactions (REQUIRES_NEW semantic) are created. The first one is created when the component is initialized and the second one when the component is destroyed. In other words, even if there is no @PostConstruct/@PreDestroy callback new transactions are created just to support them. > The PostConstruct/PreDestroy lifecycle callback interceptor methods for a stateless session bean execute in an unspecified transaction context, so purely theoretical these interceptors could even be completely ignored what would yield in significant performance improvements over the stateless session beans invocations. Anyway using the transaction interceptors in conjunction with the lifecycle event handlers for stateless session beans is probably intended, so I have prepared a fix which just ignores these interceptors as long as there are no lifecycle event handlers for a given component. I have tested the fix with @PostConstruct, @PreDestroy and SessionBean interface related lifecycle event callbacks. > Provided pull request fixes the same problem for stateful session beans too. > In addition I also found a minor inconsistency in the way components are configured. There is a flag "description.isIgnoreLifecycleInterceptors()" used in order to ignore lifecycle interceptors when needed. It is consequently used in the default components initialization procedure, but specialized configurators for stateful and stateless session beans silently ignore it. I have also added a fix for that. > I have prepared a simple performance report by executing one stateless method with TransactionAttribute.NEVER, about 1000000 times in a loop: > Before the fix: > Three calls in a row: 33 sec, 31 sec, 31 sec. > After the fix: > Three calls in a row: 24 sec, 22 sec, 22 sec. > It is not a common use case for stateless beans, but it shows that the call is about 41% slower before the fix. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

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 October 2014