[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)
10 years
[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)
10 years
[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)
10 years
[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)
10 years
[JBoss JIRA] (WFLY-3936) Unnecessary transactions for non-existent lifecycle event callbacks.
by Sławomir Wojtasiak (JIRA)
Sławomir Wojtasiak created WFLY-3936:
----------------------------------------
Summary: 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.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)
10 years
[JBoss JIRA] (WFLY-918) Web deployment metrics missing
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-918?page=com.atlassian.jira.plugin.s... ]
Stuart Douglas reassigned WFLY-918:
-----------------------------------
Assignee: Stuart Douglas (was: Tomaz Cerar)
> Web deployment metrics missing
> ------------------------------
>
> Key: WFLY-918
> URL: https://issues.jboss.org/browse/WFLY-918
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Stefan Negrea
> Assignee: Stuart Douglas
> Labels: rhq
> Fix For: 9.0.0.Beta1
>
>
> The following web deployment metrics are missing from AS7 when compared to AS5 exposed metrics:
> Clustered - True if this web application context is clustered
> Virtual Host - the virtual host with which this context is associated
> Response Time - the minimum, maximum, and average response times for requests serviced by this webapp
> Currently Active Sessions - the number of sessions that are currently active for this WAR
> Maximum Active Sessions - the maximum number of sessions that have been active for this WAR
> Created Sessions - the number of sessions created for this WAR
> Created Sessions per Minute - the number of sessions created for this WAR
> Expired Sessions - the number of expired sessions for this WAR
> Expired Sessions per Minute - the number of expired sessions for this WAR
> Rejected Sessions - the number of sessions rejected for this WAR
> Rejected Sessions per Minute - the number of sessions rejected for this WAR
> Average Session Alive Time - the average alive time of sessions for this WAR
> Max Session Alive Time - the maximum alive time of sessions for this WAR
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3935) cluster-ha-singleton fails to deploy when the server is started with the debug flag
by Euan Mapham (JIRA)
[ https://issues.jboss.org/browse/WFLY-3935?page=com.atlassian.jira.plugin.... ]
Euan Mapham updated WFLY-3935:
------------------------------
Description:
When a clustered-ha-singleton is deployed to a wildfly server that was started using the --debug option, a org.jboss.msc.service.ServiceNotFoundException occurrs.
I am using the quickstart/cluster-ha-singleton found on github:
https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton
Wildfly version 8.1.0.Final
I start the server with this command:
./bin/standalone.sh --debug -server-config=standalone-ha.xml -Djboss.node.name=jb.node1
I then deploy the wildfly-cluster-ha-singleton-service.jar.
The exception that occurrs is:
15:03:31,803 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "wildfly-cluster-ha-singleton-service.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:72) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 5 more
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.DelegatingServiceRegistry.getRequiredService(DelegatingServiceRegistry.java:46) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.install(HATimerServiceActivator.java:51)
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.activate(HATimerServiceActivator.java:44)
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 6 more
When I remove the "--debug" option from the command to start the server, everything works fine.
This means we cannot debug our applications if we use this feature.
Regards,
Euan
was:
When a clustered-ha-singleton is deployed using the --debug option, a org.jboss.msc.service.ServiceNotFoundException occurrs.
I am using the quickstart/cluster-ha-singleton found on github:
https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton
Wildfly version 8.1.0.Final
I start the server with this command:
./bin/standalone.sh --debug -server-config=standalone-ha.xml -Djboss.node.name=jb.node1
I then deploy the wildfly-cluster-ha-singleton-service.jar.
The exception that occurrs is:
15:03:31,803 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "wildfly-cluster-ha-singleton-service.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:72) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 5 more
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.DelegatingServiceRegistry.getRequiredService(DelegatingServiceRegistry.java:46) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.install(HATimerServiceActivator.java:51)
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.activate(HATimerServiceActivator.java:44)
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 6 more
When I remove the "--debug" option from the command to start the server, everything works fine.
This means we cannot debug our applications if we use this feature.
Regards,
Euan
> cluster-ha-singleton fails to deploy when the server is started with the debug flag
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3935
> URL: https://issues.jboss.org/browse/WFLY-3935
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Euan Mapham
> Assignee: Jason Greene
>
> When a clustered-ha-singleton is deployed to a wildfly server that was started using the --debug option, a org.jboss.msc.service.ServiceNotFoundException occurrs.
> I am using the quickstart/cluster-ha-singleton found on github:
> https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton
> Wildfly version 8.1.0.Final
> I start the server with this command:
> ./bin/standalone.sh --debug -server-config=standalone-ha.xml -Djboss.node.name=jb.node1
> I then deploy the wildfly-cluster-ha-singleton-service.jar.
> The exception that occurrs is:
> 15:03:31,803 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "wildfly-cluster-ha-singleton-service.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
> at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:72) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 5 more
> Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
> at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.DelegatingServiceRegistry.getRequiredService(DelegatingServiceRegistry.java:46) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.install(HATimerServiceActivator.java:51)
> at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.activate(HATimerServiceActivator.java:44)
> at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
> ... 6 more
> When I remove the "--debug" option from the command to start the server, everything works fine.
> This means we cannot debug our applications if we use this feature.
> Regards,
> Euan
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3935) cluster-ha-singleton fails to deploy when the server is started with the debug flag
by Euan Mapham (JIRA)
Euan Mapham created WFLY-3935:
---------------------------------
Summary: cluster-ha-singleton fails to deploy when the server is started with the debug flag
Key: WFLY-3935
URL: https://issues.jboss.org/browse/WFLY-3935
Project: WildFly
Issue Type: Bug
Affects Versions: 8.1.0.Final
Reporter: Euan Mapham
Assignee: Jason Greene
When a clustered-ha-singleton is deployed using the --debug option, a org.jboss.msc.service.ServiceNotFoundException occurrs.
I am using the quickstart/cluster-ha-singleton found on github:
https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton
Wildfly version 8.1.0.Final
I start the server with this command:
./bin/standalone.sh --debug -server-config=standalone-ha.xml -Djboss.node.name=jb.node1
I then deploy the wildfly-cluster-ha-singleton-service.jar.
The exception that occurrs is:
15:03:31,803 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "wildfly-cluster-ha-singleton-service.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:72) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 5 more
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.msc.service.DelegatingServiceRegistry.getRequiredService(DelegatingServiceRegistry.java:46) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.install(HATimerServiceActivator.java:51)
at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.activate(HATimerServiceActivator.java:44)
at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8.1.0.Final.jar:8.1.0.Final]
... 6 more
When I remove the "--debug" option from the command to start the server, everything works fine.
This means we cannot debug our applications if we use this feature.
Regards,
Euan
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3934) TimerServiceImpl should use message patterns for debug logging
by Philippe Marschall (JIRA)
Philippe Marschall created WFLY-3934:
----------------------------------------
Summary: 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
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