[JBoss JIRA] (WFLY-4696) OutOfMemory DirectByteBuffer XNIO
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4696?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4696:
--------------------------------------
If you still have an issue in Wildfly 10.1 please file a new JIRA with the details.
> OutOfMemory DirectByteBuffer XNIO
> ---------------------------------
>
> Key: WFLY-4696
> URL: https://issues.jboss.org/browse/WFLY-4696
> Project: WildFly
> Issue Type: Bug
> Components: IO, Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.Final
> Reporter: Carlos Rodríguez Aguado
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR1
>
> Attachments: wfly9_0_0_final.mp4, wlfy.mp4
>
>
> I get this errors constantly in my server when a web connection is interrupted from the browser for instance:
> 11:50:45,301 ERROR [stderr] (default task-339) Exception in thread "default task-339" java.nio.BufferOverflowException
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363)
> 11:50:45,301 ERROR [stderr] (default task-339) at java.nio.ByteBuffer.put(ByteBuffer.java:859)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:150)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:629)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:205)
> 11:50:45,301 ERROR [stderr] (default task-339) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 11:50:45,301 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:201)
> 11:50:45,317 ERROR [stderr] (default task-339) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 11:50:45,317 ERROR [stderr] (default task-339) at java.lang.Thread.run(Thread.java:745)
> And then, I think this errors lead to a OutOfMemory crash:
> 14:23:09,592 ERROR [org.xnio.listener] (default I/O-3) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:149) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:143) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> This is the trace for version 8.2 of WildFly:
> 17:17:16,957 ERROR [io.undertow.request] (default task-49) Undertow request failed HttpServerExchange{ GET /modulab/servlet/ShowPDFReportServlet}: java.nio.BufferOverflowException
> at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:363) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.put(ByteBuffer.java:859) [rt.jar:1.8.0_20]
> at io.undertow.util.HttpString.appendTo(HttpString.java:204)
> at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:166)
> at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:564)
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
> at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:175)
> at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:194)
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.writeFinal(HttpServerExchange.java:1829)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:565)
> at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:600)
> at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:581)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:308)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> 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]
> 10:57:12,389 ERROR [org.xnio.listener] (default I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError
> at sun.misc.Unsafe.allocateMemory(Native Method) [rt.jar:1.8.0_20]
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:127) [rt.jar:1.8.0_20]
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311) [rt.jar:1.8.0_20]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslConduitEngine.<init>(JsseSslConduitEngine.java:146) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseSslStreamConnection.<init>(JsseSslStreamConnection.java:71) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:45) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.JsseAcceptingSslStreamConnection.accept(JsseAcceptingSslStreamConnection.java:37) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ssl.AbstractAcceptingSslChannel.accept(AbstractAcceptingSslChannel.java:187) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:289) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.NioTcpServerHandle.handleReady(NioTcpServerHandle.java:53) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.3.0.Final.jar:3.3.0.Final]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2656:
------------------------------------------
I think that WFLYDS0012 is relevant and highlights a flaw in the CapabilityRegistry. I think what we have is two threads, writer thread WT and reader thread RT. WT is doing the deployment-scanner=dummy:remove. RT is the scan thread trying to read deployment status.
1) WT modifies the CapabiltyRegistry, so now it's state differs from that of its publishedFullRegistry member.
2) RT is cancelled due to the remove happening, so its OperationContext enters enterResultHandlerPhase and calls OperationContextImpl.operationRollingBack / ModelControllerImp.disardModel / ManagemtModelImpl.discard / CapabilityRegistry.rollback.
3) CapabilityRegistry.rollback restores the state from the publishedFullRegistry, effectively undoing what WT did in step 1)
4) WT gets to OperationContext executeDoneStage and publishes the capability registry, which means its incorrect state from 3) is pushed to publishedFullRegistry.
This is going to take some thought. RT hasn't modified anything so it shouldn't do anything in rollback.
> DeploymentTestCase.testFilesystemScannerRegistration fails intermittently
> -------------------------------------------------------------------------
>
> Key: WFCORE-2656
> URL: https://issues.jboss.org/browse/WFCORE-2656
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner, Domain Management
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
>
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes...
> I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references.
> The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8587) Unable to establish loopback connection
by Daniel Kittrich (JIRA)
Daniel Kittrich created WFLY-8587:
-------------------------------------
Summary: Unable to establish loopback connection
Key: WFLY-8587
URL: https://issues.jboss.org/browse/WFLY-8587
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 10.1.0.Final
Environment: Windows 8.1
Reporter: Daniel Kittrich
Assignee: Jason Greene
When starting a fresh new installation using standalone.bat,
the system reports:
ERROR MSC000001: Failed to start service org.wildfly.io.worker.default...
caused by: "unable to establish loopback connection".
Consequently many services won't start.
Server then reports: ... started (with errors).
We believe the reported exception (WorkerService.java:55) comes from:
https://github.com/wildfly/wildfly-core/blob/2.0.10.Final/io/subsystem/sr...
*Screen dump*:
21:19:16,682 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service org.wildfly.io.worker.default: org.jboss.msc.service.StartException in service org.wildfly.io.worker.default: java.io.IOException:
Unable to establish loopback connection
at org.wildfly.extension.io.WorkerService.start(WorkerService.java:55)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Unable to establish loopback connection
at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101)
at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:170)
at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:50)
at java.nio.channels.Pipe.open(Pipe.java:155)
at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:127)
at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:44)
at org.xnio.nio.NioXnio$DefaultSelectorCreator.open(NioXnio.java:257)
at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:97)
at org.xnio.nio.NioXnio.createWorker(NioXnio.java:212)
at org.wildfly.extension.io.WorkerService.start(WorkerService.java:53)
... 5 more
Caused by: java.net.ConnectException: Connection timed out: connect
at sun.nio.ch.Net.connect0(Native Method)
at sun.nio.ch.Net.connect(Net.java:454)
at sun.nio.ch.Net.connect(Net.java:446)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648)
at java.nio.channels.SocketChannel.open(SocketChannel.java:189)
at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:130)
at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83)
... 16 more
21:19:16,691 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "io"),
("worker" => "default")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"org.wildfly.io.worker.default" => "org.jboss.msc.service.StartException in service org.wildfly.io.worker.default: java.io.IOException: Unable to establish loopback connection
Caused by: java.io.IOException: Unable to establish loopback connection
Caused by: java.net.ConnectException: Connection timed out: connect"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.worker.default"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
...
21:19:17,032 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started (with errors) in 25262ms - Started 308 of 574 services (16 services failed or missing dependencies, 393 ser
vices are lazy, passive or on-demand)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8579) Topic messages are sent to all shared non-durable subscription participants
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-8579?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-8579:
--------------------------------------
I did some further testing:
* Setting "shareSubscriptions" to "true" has no effect on NonDurable subscriptions.
* Setting the "clientId" property shows this warning at deployment time:
{panel}
15:02:10,541 WARN [org.jboss.as.ejb3] (MSC service thread 1-3) WFLYEJB0006: ActivationConfigProperty clientId will be ignored since it is not allowed by resource adapter: activemq-ra
{panel}
* Changing "clientId" to "clientID" makes this warning go away and introduces a new error about there already being subscribers on a durable topic, so...
* Setting "shareSubscriptions" to "true" at that point seems to make everything behave as I'd expect. The messages are delivered round-robin as if I had multiple subscribers on a queue.
So it looks like there's a separate issue with having to specify "clientID" instead of "clientId", although it's not completely silent about it, which is good. Ultimately I don't see a method of creating a non-durable shared subscription to a topic using MDBs, and thus there's probably no way to create a non-durable shared subscription across multiple nodes in a cluster. Thoughts?
> Topic messages are sent to all shared non-durable subscription participants
> ---------------------------------------------------------------------------
>
> Key: WFLY-8579
> URL: https://issues.jboss.org/browse/WFLY-8579
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Scott Van Wart
> Assignee: Jeff Mesnil
> Attachments: duplicate-shared.zip
>
>
> I have two MDBs with a subscription to a topic. The same clientId and a subscriptionName are specified in the activation config properties for each MDB. subscriptionDurability is omitted (defaulted to NonDurable).
> When I send a single message to this topic, both MDBs receive the message. According to JSR 343, 8.3.2 Shared non-durable subscriptions:
> bq. A non-durable shared subscription is used by a client that needs to be able to
> share the work of receiving messages from a non-durable topic subscription
> amongst multiple consumers. A non-durable shared subscription may
> therefore have more than one consumer. *Each message from the subscription will be delivered to only one of the consumers on that
> subscription.*
> Setting the subscriptionDurability property to Durable works as expected (each message is delivered to only one consumer in that subscription).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years