[JBoss JIRA] (WFLY-2458) Re-deployment of a clustered application fail due to race-condition with infinispan
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2458:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 1027738|https://bugzilla.redhat.com/show_bug.cgi?id=1027738]
https://github.com/jbossas/jboss-eap/pull/693
> Re-deployment of a clustered application fail due to race-condition with infinispan
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2458
> URL: https://issues.jboss.org/browse/WFLY-2458
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Server
> Affects Versions: 8.0.0.Beta1
> Environment: Clustered Standalone server with one clustered EAR
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployer
> Attachments: appone.ear
>
>
> If a clustered application should be redeployed it looks like that infinispan is not able to stop complete until the deployer finish undeployment and start to deploy the new application. See the Exception below.
> The behaviour is the same for managed or unmanged deployments.
> If it is unmanaged the .failed marker file exists.
> After the failure the application is shown in the mgmt console without deployed Beans.
> A second deploy attempt will be successfull
> 11:22:36,397 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [home/ejb|1] (2) [home/ejb, node2/ejb]
> 11:22:52,746 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:52,751 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000029: Passivating all entries to disk
> 11:22:52,752 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000030: Passivated 0 entries in 0 milliseconds
> 11:22:52,759 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 58) JBAS010282: Stopped repl cache from ejb container
> 11:22:52,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 60) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 11:22:52,768 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting and closing JGroups Channel
> 11:22:52,771 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 36ms
> 11:22:52,772 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 39ms
> 11:22:52,773 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "appone.ear" (runtime-name: "appone.ear")
> 11:22:52,778 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar")
> 11:22:52,792 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) JBAS016002: Processing weld deployment appone.ear
> 11:22:52,803 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment ejb.jar
> 11:22:52,805 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named AppOneBean in deployment unit subdeployment "ejb.jar" of deployment "appone.ear" are as follows:
> java:global/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:app/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:module/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:jboss/exported/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:global/appone/ejb/AppOneBean
> java:app/ejb/AppOneBean
> java:module/AppOneBean
> 11:22:52,807 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016005: Starting Services for CDI deployment: appone.ear
> 11:22:52,811 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment appone.ear
> 11:22:53,087 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher
> 11:22:53,118 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 60) ISPN000078: Starting JGroups Channel
> 11:22:53,119 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 60) MSC000001: Failed to start service jboss.infinispan.ejb.global-component-registry: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.global-component-registry: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.jboss.as.clustering.infinispan.subsystem.GlobalComponentRegistryService.start(GlobalComponentRegistryService.java:33)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:219)
> ... 6 more
> Caused by: org.infinispan.commons.CacheException: Unable to start JGroups Channel
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:196)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 11 more
> Caused by: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:902)
> at org.jgroups.JChannel._preConnect(JChannel.java:522)
> at org.jgroups.JChannel.connect(JChannel.java:284)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:194)
> ... 17 more
> 11:22:53,128 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:53,137 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 11ms
> 11:22:53,138 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 12ms
> 11:22:53,143 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.CREATE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne", service jboss.naming.context.java.global.appone.ejb.AppOneBean, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, JBAS014799: ... and 5 more ]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.WeldInstantiator (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."appone.ear".deploymentCompleteService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.naming.context.java.app.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.app.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultContextService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultDataSource (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedScheduledExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedThreadFactory (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.EJBContext (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TimerService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TransactionSynchronizationRegistry (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.UserTransaction (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env."org.jboss.as.quickstarts.ejb.multi.server.app.AppOneBean".context (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.global.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.global.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.module.appone.ejb.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> JBAS014777: Services which failed to start: service jboss.infinispan.ejb.global-component-registry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse edited comment on WFLY-2490 at 11/11/13 1:23 PM:
------------------------------------------------------------------
I believe it is the "Remoting "cli-client" I/O-1" thread that is in the loop, here are a couple of stacks captured whilst at 100% CPU for this thread: -
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:782)
- locked <0x00000000d88a88c8> (a java.io.EOFException)
at java.lang.Throwable.<init>(Throwable.java:265)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.EOFException.<init>(EOFException.java:63)
at org.xnio._private.Messages_$logger.connectionClosedEarly(Messages_$logger.java:859)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:282)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
at sun.nio.ch.IOUtil.read(IOUtil.java:198)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
- locked <0x00000000869920a0> (a java.lang.Object)
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:270)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:74)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:276)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x0000000086b42658> (a sun.nio.ch.Util$2)
- locked <0x0000000086b42648> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000086991a80> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:494)
{noformat}
Note - Despite the looping additional connections are not be created to the server: -
{noformat}
[darranl@localhost bin]$ netstat -anop | grep 9993
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:9993 0.0.0.0:* LISTEN 32698/java off (0.00/0/0)
tcp6 0 0 127.0.0.1:48415 127.0.0.1:9993 CLOSE_WAIT 337/java off (0.00/0/0)
{noformat}
was (Author: dlofthouse):
I believe it is the "Remoting "cli-client" I/O-1" thread that is in the loop, here are a couple of stacks captured whilst at 100% CPU for this thread: -
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:782)
- locked <0x00000000d88a88c8> (a java.io.EOFException)
at java.lang.Throwable.<init>(Throwable.java:265)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.EOFException.<init>(EOFException.java:63)
at org.xnio._private.Messages_$logger.connectionClosedEarly(Messages_$logger.java:859)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:282)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
at sun.nio.ch.IOUtil.read(IOUtil.java:198)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
- locked <0x00000000869920a0> (a java.lang.Object)
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:270)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:74)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:276)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x0000000086b42658> (a sun.nio.ch.Util$2)
- locked <0x0000000086b42648> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000086991a80> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:494)
{noformat}
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse edited comment on WFLY-2490 at 11/11/13 1:19 PM:
------------------------------------------------------------------
I believe it is the "Remoting "cli-client" I/O-1" thread that is in the loop, here are a couple of stacks captured whilst at 100% CPU for this thread: -
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:782)
- locked <0x00000000d88a88c8> (a java.io.EOFException)
at java.lang.Throwable.<init>(Throwable.java:265)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.EOFException.<init>(EOFException.java:63)
at org.xnio._private.Messages_$logger.connectionClosedEarly(Messages_$logger.java:859)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:282)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
at sun.nio.ch.IOUtil.read(IOUtil.java:198)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
- locked <0x00000000869920a0> (a java.lang.Object)
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:270)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:74)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:276)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x0000000086b42658> (a sun.nio.ch.Util$2)
- locked <0x0000000086b42648> (a java.util.Collections$UnmodifiableSet)
- locked <0x0000000086991a80> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:102)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:494)
{noformat}
was (Author: dlofthouse):
I believe it is the "Remoting "cli-client" I/O-1" thread that is in the loop, here are a couple of stacks captured whilst at 100% CPU for this thread: -
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:782)
- locked <0x00000000d88a88c8> (a java.io.EOFException)
at java.lang.Throwable.<init>(Throwable.java:265)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.EOFException.<init>(EOFException.java:63)
at org.xnio._private.Messages_$logger.connectionClosedEarly(Messages_$logger.java:859)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:282)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
at sun.nio.ch.IOUtil.read(IOUtil.java:198)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
- locked <0x00000000869920a0> (a java.lang.Object)
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:270)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:74)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:276)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2490:
----------------------------------------
I believe it is the "Remoting "cli-client" I/O-1" thread that is in the loop, here are a couple of stacks captured whilst at 100% CPU for this thread: -
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:782)
- locked <0x00000000d88a88c8> (a java.io.EOFException)
at java.lang.Throwable.<init>(Throwable.java:265)
at java.lang.Exception.<init>(Exception.java:66)
at java.io.IOException.<init>(IOException.java:58)
at java.io.EOFException.<init>(EOFException.java:63)
at org.xnio._private.Messages_$logger.connectionClosedEarly(Messages_$logger.java:859)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:282)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
{noformat}
"Remoting "cli-client" I/O-1" daemon prio=10 tid=0x00007fe48857f000 nid=0x173 runnable [0x00007fe46e172000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225)
at sun.nio.ch.IOUtil.read(IOUtil.java:198)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359)
- locked <0x00000000869920a0> (a java.lang.Object)
at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:270)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:74)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:276)
at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
{noformat}
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2458) Re-deployment of a clustered application fail due to race-condition with infinispan
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2458:
-----------------------------------------------
Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 1027738|https://bugzilla.redhat.com/show_bug.cgi?id=1027738]
OK - so the previous fix ensured that the channel exists before Infinispan's global component registry starts - however, this appears to be insufficient.
If undeploy doesn't trigger a full restart of the JGroups channel service, Infinispan's restarted cache manager attempts to reuse the channel that was previously closed, hence the exception.
The underlying problem is that Infinispan now controls the lifecycle of the channel, while the channel is provided by EAP. However, Infinispan should only be connecting and disconnecting the channel. The channel should not close until EAP says so.
I've opened an upstream issue for this:
https://issues.jboss.org/browse/ISPN-3697
Until then, we can trick Infinispan into not closing the channel - and instead make that the responsibility of the channel service.
I'll have a PR ready momentarily.
I should note that this issue has a workaround.
Instead of redeploying, the user can undeploy and deploy again. The introduction of a brief period of time allows the channel service to stop - thus causing the redeploy to use a fresh channel, instead of reusing the old, closed one.
> Re-deployment of a clustered application fail due to race-condition with infinispan
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2458
> URL: https://issues.jboss.org/browse/WFLY-2458
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering, Server
> Affects Versions: 8.0.0.Beta1
> Environment: Clustered Standalone server with one clustered EAR
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Labels: deployer
> Attachments: appone.ear
>
>
> If a clustered application should be redeployed it looks like that infinispan is not able to stop complete until the deployer finish undeployment and start to deploy the new application. See the Exception below.
> The behaviour is the same for managed or unmanged deployments.
> If it is unmanaged the .failed marker file exists.
> After the failure the application is shown in the mgmt console without deployed Beans.
> A second deploy attempt will be successfull
> 11:22:36,397 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [home/ejb|1] (2) [home/ejb, node2/ejb]
> 11:22:52,746 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:52,751 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000029: Passivating all entries to disk
> 11:22:52,752 INFO [org.infinispan.eviction.PassivationManagerImpl] (ServerService Thread Pool -- 58) ISPN000030: Passivated 0 entries in 0 milliseconds
> 11:22:52,759 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 58) JBAS010282: Stopped repl cache from ejb container
> 11:22:52,765 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 60) JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
> 11:22:52,768 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000080: Disconnecting and closing JGroups Channel
> 11:22:52,771 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 36ms
> 11:22:52,772 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 39ms
> 11:22:52,773 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "appone.ear" (runtime-name: "appone.ear")
> 11:22:52,778 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "ejb.jar")
> 11:22:52,792 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) JBAS016002: Processing weld deployment appone.ear
> 11:22:52,803 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment ejb.jar
> 11:22:52,805 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-5) JNDI bindings for session bean named AppOneBean in deployment unit subdeployment "ejb.jar" of deployment "appone.ear" are as follows:
> java:global/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:app/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:module/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:jboss/exported/appone/ejb/AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne
> java:global/appone/ejb/AppOneBean
> java:app/ejb/AppOneBean
> java:module/AppOneBean
> 11:22:52,807 INFO [org.jboss.weld.deployer] (MSC service thread 1-11) JBAS016005: Starting Services for CDI deployment: appone.ear
> 11:22:52,811 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment appone.ear
> 11:22:53,087 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000082: Stopping the RpcDispatcher
> 11:22:53,118 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 60) ISPN000078: Starting JGroups Channel
> 11:22:53,119 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 60) MSC000001: Failed to start service jboss.infinispan.ejb.global-component-registry: org.jboss.msc.service.StartException in service jboss.infinispan.ejb.global-component-registry: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:91) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241)
> at org.jboss.as.clustering.infinispan.subsystem.GlobalComponentRegistryService.start(GlobalComponentRegistryService.java:33)
> at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:86) [wildfly-clustering-common-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 4 more
> Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.remoting.transport.jgroups.JGroupsTransport.start() on object of type JGroupsTransport
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:219)
> ... 6 more
> Caused by: org.infinispan.commons.CacheException: Unable to start JGroups Channel
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:196)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:185)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 11 more
> Caused by: java.lang.IllegalStateException: channel is closed
> at org.jgroups.JChannel.checkClosed(JChannel.java:902)
> at org.jgroups.JChannel._preConnect(JChannel.java:522)
> at org.jgroups.JChannel.connect(JChannel.java:284)
> at org.jgroups.JChannel.connect(JChannel.java:275)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:194)
> ... 17 more
> 11:22:53,128 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment appone.ear
> 11:22:53,137 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015877: Stopped deployment null (runtime-name: ejb.jar) in 11ms
> 11:22:53,138 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015877: Stopped deployment appone.ear (runtime-name: appone.ear) in 12ms
> 11:22:53,143 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.CREATE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.VIEW."org.jboss.as.quickstarts.ejb.multi.server.app.AppOne".REMOTE (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation, service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne", service jboss.naming.context.java.global.appone.ejb.AppOneBean, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, JBAS014799: ... and 5 more ]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.WeldInstantiator (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".deploymentCompleteService (missing) dependents: [service jboss.deployment.unit."appone.ear".deploymentCompleteService]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START, service jboss.deployment.subunit."appone.ear"."ejb.jar".moduleDeploymentRuntimeInformationStart]
> service jboss.naming.context.java.app.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.app.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultContextService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultDataSource (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedScheduledExecutorService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.DefaultManagedThreadFactory (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.EJBContext (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TimerService (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.TransactionSynchronizationRegistry (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.UserTransaction (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.comp.appone.ejb.AppOneBean.env."org.jboss.as.quickstarts.ejb.multi.server.app.AppOneBean".context (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService, service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.START]
> service jboss.naming.context.java.global.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.global.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.AppOneBean (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb."AppOneBean!org.jboss.as.quickstarts.ejb.multi.server.app.AppOne" (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".component.AppOneBean.JndiBindingsService]
> service jboss.naming.context.java.module.appone.ejb.BeanManager (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> service jboss.naming.context.java.module.appone.ejb.env (missing) dependents: [service jboss.deployment.subunit."appone.ear"."ejb.jar".jndiDependencyService]
> JBAS014777: Services which failed to start: service jboss.infinispan.ejb.global-component-registry
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2490:
----------------------------------------
One additional piece of information, for the example where the thread is left spinning at 100% the CLI also does not contain any configuration to allow the servers certificate to be tested, we would expect this to result this in the user being prompted to decide if they want to trust the users certificate but in general this shows that the timeout and spinning is at a point where no connection to the server was established rather than a connection being established and the HTTP upgrade step failing.
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2490?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2490:
-----------------------------------
Parent: WFLY-1597
Issue Type: Sub-task (was: Bug)
> Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-2490
> URL: https://issues.jboss.org/browse/WFLY-2490
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI, Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
> {noformat}
> [disconnected /] connect https-remoting://localhost:9993
> The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> {noformat}
> Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
> {noformat}
> [disconnected /] connect http-remoting://localhost:9990
> The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2490) Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2490:
--------------------------------------
Summary: Connecting using https-remoting times out and leaves thread within CLI spinning at 100%
Key: WFLY-2490
URL: https://issues.jboss.org/browse/WFLY-2490
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI, Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
HTTP Upgrade is not fully working when SSL is enabled, other tasks will address that but this issue is about the CLI connecting to a server where HTTP Upgrade is not possible - a thread within the CLI is left running at 100% even after connecting has timed out.
{noformat}
[disconnected /] connect https-remoting://localhost:9993
The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
{noformat}
Connecting to the HTTP port where HTTP Upgrade is not available also results in a time out connecting rather than an early failure but does not result in the thread spinning at 100%
{noformat}
[disconnected /] connect http-remoting://localhost:9990
The controller is not available at localhost:9990: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out: JBAS012144: Could not connect to http-remoting://localhost:9990. The connection timed out
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2489) Replace add-user example image with something not running as root.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2489:
--------------------------------------
Summary: Replace add-user example image with something not running as root.
Key: WFLY-2489
URL: https://issues.jboss.org/browse/WFLY-2489
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Web Console
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
Where no users are defined we show a web page with an example using the add user utility - would be a good idea to not be encouraging running as root.
In addition to this some of the prompts have evolved anyway e.g. no longer a need to specify the realm name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-475) Re-review CLI server certificate acceptance.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-475?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-475:
---------------------------------------
The connect / reconnect loop is causing the following error to be logged server side after the first disconnect: -
{noformat}
17:35:10,570 ERROR [org.jboss.remoting.remote.connection] (Remoting "localhost:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
{noformat}
> Re-review CLI server certificate acceptance.
> --------------------------------------------
>
> Key: WFLY-475
> URL: https://issues.jboss.org/browse/WFLY-475
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Minor
> Fix For: 8.0.0.CR1
>
>
> Can we remove the call loop and manage the user prompt and trust store replacement all within the trust manager?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months