[JBoss JIRA] (JGRP-1659) deadlock in MFC with default configuration
by Ray Tsang (JIRA)
[ https://issues.jboss.org/browse/JGRP-1659?page=com.atlassian.jira.plugin.... ]
Ray Tsang commented on JGRP-1659:
---------------------------------
Bela - what is the configuration file you used?
Does FragMacOSX thing apply to tcp as well?
Thanks,
> deadlock in MFC with default configuration
> ------------------------------------------
>
> Key: JGRP-1659
> URL: https://issues.jboss.org/browse/JGRP-1659
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.7
> Reporter: Mircea Markus
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: expiration-test.zip
>
>
> MFC.down does the following:
> {code:java}
> credits.decrement(length, block_time); //A
> if(needToSendCreditRequest()) //B
> sendCreditRequest(tuple.getVal1(), Math.min(max_credits)
> {code}
> A blocks forever even if the MFC.max_block_time is configured:
> {code:xml}
> <MFC max_credits="200k" min_threshold="0.20" max_block_time="1"/>
> {code}
> This happens at the same time on the whole cluster. B never gets invoked, so both wake up conditions( credits received or timeout) for credits.decrement are never satisfied resulting in the whole cluster to freeze.
--
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
13 years
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Dimitris Andreadis <dandread(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]
Rado, have you fixed that upstream, too? JIRA/pull requests?
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {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
13 years
[JBoss JIRA] (WFLY-1708) Per-deployment web thread pools
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1708?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1708:
-----------------------------------
The problem is that RejectedExecutionException is expensive and difficult to handle properly. The alternative is to queue indefinitely which is also potentially problematic. By handling it at the handler, you essentially suspend the connection, and once enough connections accumulate, the server connection limiting kicks in, which works as a buffer against the server doing the Apache HTTPD thing and throwing 4xx and 5xx errors sporadically as load increases. Instead the backlog is handled more cleanly by the server OS and TCP/IP.
> Per-deployment web thread pools
> -------------------------------
>
> Key: WFLY-1708
> URL: https://issues.jboss.org/browse/WFLY-1708
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> It would be nice if you could limit the number of worker threads being used by an application, and one way of achieving that would be to add a per-deployment thread pool for handing web requests.
> This can be done currently by configuring one <connector> per application and giving each one it's own thread pool.
> Undertow supports (from cursory inspection) DeploymentInfo.setExecutor/setAsyncExecutor() which configured the Executor to use for requests. The subsystem could read a thread pool configuration from jboss-web.xml and pass the resulting executor into those two methods to make setting this up easier and not require a load balancer.
--
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
13 years
[JBoss JIRA] (WFLY-1708) Per-deployment web thread pools
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1708?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-1708:
-----------------------------------
The CAS is only contended if the given handler already would be invoked. In this case a CAS is generally going to be just about the smallest tick on the CPU consumption of what is, after all, otherwise going to be a blocking handler. And I think you can potentially win back that cost just by having substantially fewer threads in the system, in many cases.
> Per-deployment web thread pools
> -------------------------------
>
> Key: WFLY-1708
> URL: https://issues.jboss.org/browse/WFLY-1708
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: James Livingston
> Assignee: Stuart Douglas
>
> It would be nice if you could limit the number of worker threads being used by an application, and one way of achieving that would be to add a per-deployment thread pool for handing web requests.
> This can be done currently by configuring one <connector> per application and giving each one it's own thread pool.
> Undertow supports (from cursory inspection) DeploymentInfo.setExecutor/setAsyncExecutor() which configured the Executor to use for requests. The subsystem could read a thread pool configuration from jboss-web.xml and pass the resulting executor into those two methods to make setting this up easier and not require a load balancer.
--
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
13 years
[JBoss JIRA] (WFLY-87) Fired object messages violate classloaders
by John Ament (JIRA)
[ https://issues.jboss.org/browse/WFLY-87?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on WFLY-87:
--------------------------------
I'll actually give this a try in the wfly builds shortly (probably this weekend). I think the bypass for this is to use jboss-deployment-structure.xml in the deployment now (since this was originally noted in AS6 and kind of just brought along for the ride).
> Fired object messages violate classloaders
> ------------------------------------------
>
> Key: WFLY-87
> URL: https://issues.jboss.org/browse/WFLY-87
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: John Ament
> Assignee: Jeff Mesnil
> Fix For: 8.0.0.Beta1
>
> Attachments: test.zip
>
>
> JMS allows you to fire an object message. In this case, I have a object of type in my deployment. It fires fine. I bind a message consumer to a queue in AS7. the object message coming in results in a classloader violation:
> 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> at java.lang.Class.forName0(Native Method) [:1.6.0_22]
> at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
> at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
> at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
> at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
> at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
--
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
13 years
[JBoss JIRA] (AS7-4932) CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------
Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from ON_QA to POST
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4932
> URL: https://issues.jboss.org/browse/AS7-4932
> Project: Application Server 7
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Radoslav Husar
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: as713tracking
> Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/jo...
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {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
13 years
[JBoss JIRA] (WFLY-806) acceptor and poller threads not destroyed when reloading
by Markus Backes (JIRA)
[ https://issues.jboss.org/browse/WFLY-806?page=com.atlassian.jira.plugin.s... ]
Markus Backes commented on WFLY-806:
------------------------------------
We had an similar issue with an application which is using corba in AS7. AOMRemoval threads where not tidied up after desroying the POA. This was causing an java.lang.OutOfMemoryError. I created a patch and sent a pull request to JacORB-Team.
> acceptor and poller threads not destroyed when reloading
> --------------------------------------------------------
>
> Key: WFLY-806
> URL: https://issues.jboss.org/browse/WFLY-806
> Project: WildFly
> Issue Type: Bug
> 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
> 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
13 years