[
https://issues.jboss.org/browse/WFLY-806?page=com.atlassian.jira.plugin.s...
]
Tomaz Cerar resolved WFLY-806.
------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
This should be fixed or at least it should behave differently given that now XNIO workers
are configured in one place (IO subsystem) and other subsystems just use it.
acceptor and poller threads not destroyed when reloading
--------------------------------------------------------
Key: WFLY-806
URL:
https://issues.jboss.org/browse/WFLY-806
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Remoting
Environment: Fedora 18
java version "1.7.0_13"
Java(TM) SE Runtime Environment (build 1.7.0_13-b20)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Alexey Loubyansky
Assignee: Remy Maucherat
Fix For: 8.0.0.Final
Attachments: server_thread_dump.txt
I'm testing the reload operation. At some point the server becomes unresponsive. One
of the reasons is
14:39:17,452 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS
8.0.0.Alpha1-SNAPSHOT "TBD" started in 240ms - Started 144 of 181 services (55
services are lazy, passive or on-demand)
14:39:17,452 ERROR [stderr] (Controller Boot Thread) Controller Boot Thread releasing
lock on 565478949
14:39:17,713 ERROR [org.xnio.listener] (Remoting "fedorka:MANAGEMENT" read-1) A
channel event listener threw an exception: java.lang.OutOfMemoryError: unable to create
new native thread
at java.lang.Thread.start0(Native Method) [rt.jar:1.7.0_13]
at java.lang.Thread.start(Thread.java:691) [rt.jar:1.7.0_13]
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:949)
[rt.jar:1.7.0_13]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1360)
[rt.jar:1.7.0_13]
at org.xnio.XnioWorker.execute(XnioWorker.java:724)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at
org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:218)
[jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
[jboss-remoting-3.2.15.GA.jar:3.2.15.GA]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at
org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at
org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61)
[xnio-api-3.1.0.Beta9.jar:3.1.0.Beta9]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:518)
And if look at the thread dump of the server process, I see lots of acceptor and poller
threads. See the attached thread dump.
--
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