[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)
11 years, 9 months
[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)
11 years, 9 months
[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 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.
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 do 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[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 do 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.
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 do 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 methods 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 do 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.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[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 commented on WFLY-3936:
------------------------------------------
Wildfly 9.0.0-Alfa1 seems to be also affected. I will test it soon. As far as I've checked so far, the fix can be also applied for 9.0.0 as it is.
> 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 do 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 methods 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)
11 years, 9 months
[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:
-------------------------------------
Affects Version/s: 8.1.0.Final
> 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 do 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 methods 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)
11 years, 9 months