[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)
11 years, 9 months
[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)
11 years, 9 months
[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)
11 years, 9 months
[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)
11 years, 9 months
[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)
11 years, 9 months
[JBoss JIRA] (DROOLS-626) collectList on objects of type java.lang.Class get returned as null
by David Fell (JIRA)
David Fell created DROOLS-626:
---------------------------------
Summary: collectList on objects of type java.lang.Class get returned as null
Key: DROOLS-626
URL: https://issues.jboss.org/browse/DROOLS-626
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Beta1
Environment: Snapshot Drools 6.2.0.201410031437 runtime
Reporter: David Fell
Assignee: Mark Proctor
If collectList in an accumulate is supplied objects of type java.lang.Class, then subsequent examination of the supplied list yields null values rather than the expect Class values.
Test case below. Swapping the comments to make InitClass have a String field instead of a Class field changes the behaviour of the list from collectList to what one would expect.
package com.sample
declare MyClass end
declare InitClass
clazz: Class @key
// clazz: String @key
end
rule "init"
when
then
insert( new InitClass( MyClass.class ) );
// insert( new InitClass( "some string" ) );
end
rule "make init classes"
when
accumulate( InitClass( $clazz; ), $list: collectList( $clazz ) )
then
System.out.printf("%d items in list\n", $list.size());
for(Object obj : $list)
System.out.printf("item is %s\n", obj);
end
rule "show init classes"
when
InitClass( $v; )
then
System.out.printf("match %s\n", $v);
end
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (JGRP-1850) jGroups 3.4.3 timeouts after a node leaves and rejoins cluster
by Justin Cranford (JIRA)
[ https://issues.jboss.org/browse/JGRP-1850?page=com.atlassian.jira.plugin.... ]
Justin Cranford commented on JGRP-1850:
---------------------------------------
There was an update to WFLY-2632 for the same JGRP000031 error after my last comment here on June 12.
Radoslav Husar added a comment - 24/Jun/14 9:57 AM
We don't have a final fix yet, though you can ignore these warnings for now.
Unfortunately I cannot ignore the error. Immediately after cluster start, I am acquire locks no problem. But as soon as any application node is restarted, the errors appear and all attempts to acquire a lock fail.
Paul Ferraro works on both WildFly and HA-JDBC. He confirmed both are affected.
> jGroups 3.4.3 timeouts after a node leaves and rejoins cluster
> --------------------------------------------------------------
>
> Key: JGRP-1850
> URL: https://issues.jboss.org/browse/JGRP-1850
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.3
> Environment: Tomcat 7.0.54
> Java 7u45 x32
> HA-JDBC 3.0.0, 3.0.1, 3.0.2, 3.0.3-SNAPSHOT
> Debian 5 x64
> Reporter: Justin Cranford
> Assignee: Bela Ban
> Attachments: catalina.out.bz2, ha-jdbc-jgroups-tcp.xml
>
>
> I have this open thread on HA-JDBC forum. The issue seems to be jGroups. I attached my Tomcat log there with steps to reproduce the issue.
> http://sourceforge.net/p/ha-jdbc/discussion/383397/thread/843c60ad/?limit...
> Here is an example of what my jGroups error looks like, copied from the HA-JDBC thread. I can reproduce this quite often, possibly every time I try it, but not sure if it happens 100% of the time. I have reproduced it at least half a dozen times.
> May 09, 2014 12:01:45 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:46 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:49 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:50 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:51 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
> May 09, 2014 12:01:51 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:53 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:54 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:57 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:01:57 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
> May 09, 2014 12:01:57 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> FINE: Received MemberAcquireLockCommand(writeLock()) from 10.0.0.187
> May 09, 2014 12:01:58 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:01 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:02 AM org.jgroups.logging.JDKLogImpl debug
> FINE: 10.0.0.188: sending are-you-alive msg to 10.0.0.187
> May 09, 2014 12:02:03 AM net.sf.hajdbc.logging.slf4j.SLF4JLogger log
> WARNING: timeout sending message to 10.0.0.187
> org.jgroups.TimeoutException: timeout sending message to 10.0.0.187
> at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:419)
> at net.sf.hajdbc.distributed.jgroups.JGroupsCommandDispatcher.execute(JGroupsCommandDispatcher.java:177)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockCoordinator(DistributedLockManager.java:420)
> at net.sf.hajdbc.lock.distributed.DistributedLockManager$DistributedLock.lockInterruptibly(DistributedLockManager.java:320)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:864)
> at net.sf.hajdbc.sql.DatabaseClusterImpl.activate(DatabaseClusterImpl.java:156)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-2632) JGroups drops unicast messages after shutdown/restart
by Justin Cranford (JIRA)
[ https://issues.jboss.org/browse/WFLY-2632?page=com.atlassian.jira.plugin.... ]
Justin Cranford commented on WFLY-2632:
---------------------------------------
I am experiencing the same JGRP000031 error with JGroups 3.4.3 and 3.4.4. However, I was trying JGroups 3.4 with Tomcat 7 & HA-JDBC 3.0 instead of WildFly. The symptoms are identical - restart an application server in the JGroups cluster, and it logs these JGRP000031 errors. Restart the cluster and the errors disappear.
I added myself to the watchlist for this WFLY-2632 bug. I previously reported it on the HA-JDBC forum and in the JGroups bug tracker:
https://sourceforge.net/p/ha-jdbc/discussion/383397/thread/843c60ad/?limi...
https://issues.jboss.org/browse/JGRP-1850
Unfortunately I cannot ignore the warnings. If I try to acquire locks after cluster restart then all is ok, but if I try to acquire a lock after an application server restart then it fails. This is a blocker bug for me, and goes beyond Wildfly. My hope is if and when it is fixed for WildFly, I can apply the same fix to my situation.
> JGroups drops unicast messages after shutdown/restart
> -----------------------------------------------------
>
> Key: WFLY-2632
> URL: https://issues.jboss.org/browse/WFLY-2632
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 9.0.0.Beta1
>
>
> JGroups drops unicast messages (citing wrong destination) after a node in a cluster is shutdown and then restarted.
> The JGroups version in use is 3.4.1.Final.
> Steps to reproduce:
> - start two nodes A, B using the server configuration standalone-ha.xml to create a cluster
> - shutdown A
> - restart A
> - after restart, we see these messages:
> {noformat}
> 13:15:03,227 INFO [stdout] (ServerService Thread Pool -- 63)
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,228 INFO [stdout] (ServerService Thread Pool -- 63) GMS: address=lenovo/web, cluster=web, physical address=127.0.0.1:55200
> 13:15:03,229 INFO [stdout] (ServerService Thread Pool -- 63) -------------------------------------------------------------------
> 13:15:03,414 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000094: Received new cluster view: [fred/
> web|3] (2) [fred/web, lenovo/web]
> 13:15:03,422 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 63) ISPN000079: Cache local address is lenovo/web
> , physical addresses are [127.0.0.1:55200]
> 13:15:03,427 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 63) ISPN000128: Infinispan version: Infinispan 'Infinium' 6
> .0.0.CR1
> 13:15:03,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:03,609 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,610 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 62) ISPN000031: MBeans were successfully registered to the platform
> MBean server.
> 13:15:03,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) JBAS010281: Started default-host/distributable cache from web contain
> er
> 13:15:03,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started dist cache from web container
> 13:15:03,906 INFO [org.wildfly.extension.undertow] (MSC service thread 1-1) JBAS017534: Register web context: /distributable
> 13:15:03,978 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "distributable.war" (runtime-name : "distributable.war")
> 13:15:04,033 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5
> -f005-ddb2-b377-46b165e2aa77
> 13:15:04,059 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 13:15:04,060 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta2-SNAPSHOT "WildFly" started in 5193ms - Started 293 of 410 services (178 services are lazy, passive or on-demand)
> 13:15:04,533 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,034 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> 13:15:05,534 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: lenovo/web: dropping unicast message to wrong destination ac84f3e5-f005-ddb2-b377-46b165e2aa77
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-3623) Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3623?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3623:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1139188|https://bugzilla.redhat.com/show_bug.cgi?id=1139188] from ASSIGNED to POST
> Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3623
> URL: https://issues.jboss.org/browse/WFLY-3623
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Attachments: 01134324.jar, dumpServices.txt
>
>
> See attached jar for a reproducer. Just deploy it. The jar includes it's own source.
> An @Resource annotation with a spurious ":" in the name attribute value results in an incorrect binding but no deployment failure:
> {code}
> @Resources({
> @Resource(
> // name="java:jboss/ResourceTestEJB", // ==> this works fine
> name="java:jboss:/ResourceTestEJB", // ==> this will not bind the JNDI correctly, and there is no error on deploying EJB
>
> type=com.test.ResourceEJB.class,
> lookup="java:global/01134324/ResourceEJBImpl")
> })
> {code}
> There is no error reported in the log.
> Using jndi-view op in the CLI, I see:
> {code}
> [standalone@localhost:9990 subsystem=naming] :jndi-view
> {
> "outcome" => "success",
> "result" => {
> "java: contexts" => {
> .....
> "java:jboss" => {
> ....
> "java:jboss:" => {"class-name" => "javax.naming.Context"},
> }
> }
> ....
> }
> {code}
> Any time the jndi-view op is run, the following is logged in the server.log:
> {code}
> 10:52:02,985 ERROR [org.jboss.as.naming] (management-handler-thread - 5) WFLYNAM0013: Failed to obtain jndi view value for entry java:jboss:.: javax.naming.NameNotFoundException: jboss: -- service jboss.naming.context.java.jboss.jboss:
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:204) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:133) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:297)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:536)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> If a proper binding can't be done per the annotation value, there should be an exception thrown triggering deployment rollback.
> I'll attach an MSC service dump in case it's useful.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months