[JBoss JIRA] (WFLY-4589) java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4589?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4589.
----------------------------------
Fix Version/s: 10.0.0.Beta1
Resolution: Done
Latest version of Undertow contains graceful shutdown code for web sockets that should stop this happening.
> java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-4589
> URL: https://issues.jboss.org/browse/WFLY-4589
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.0.CR1
> Environment: java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> cheffamille:wildfly-9.0.0.CR1 jfarcand$
> Reporter: Jeanfrancois Arcand
> Assignee: Stuart Douglas
> Priority: Minor
> Fix For: 10.0.0.Beta1
>
>
> Deploy atmosphere-chat.war (download it from Maven). Deploy, use WebSockets, then shutdown Wildfly 9.0.0.CR1
> 08:47:41,792 ERROR [io.undertow.websockets.jsr.request] (default task-17) UT026006: Exception running web socket method: java.lang.IllegalStateException: PBOX000048: Failed to obtain ApplicationPolicy for domain other
> at org.jboss.security.plugins.mapping.JBossMappingManager.getMappingContext(JBossMappingManager.java:67)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.setup(SecurityContextThreadSetupAction.java:110)
> at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42)
> at io.undertow.websockets.jsr.ServerWebSocketContainer.invokeEndpointMethod(ServerWebSocketContainer.java:416)
> at io.undertow.websockets.jsr.ServerWebSocketContainer$3.run(ServerWebSocketContainer.java:403)
> at io.undertow.websockets.jsr.OrderedExecutor$ExecutorTask.run(OrderedExecutor.java:67)
> 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)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[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:
--------------------------------------
Cal you try out this XNIO fix? https://github.com/xnio/xnio/commit/b30ac9dbeeab484f1b8a366944bba4c17357b816
You should be able to test it out by using Xnio 3.4.0.Beta1.
> 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: 9.0.0.CR2, 10.0.0.Alpha3
>
> 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
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-5043) Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5043?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved UNDERTOW-493 to WFLY-5043:
-----------------------------------------------
Project: WildFly (was: Undertow)
Key: WFLY-5043 (was: UNDERTOW-493)
Issue Type: Feature Request (was: Bug)
Affects Version/s: (was: 1.3.0.Beta3)
Component/s: Web (Undertow)
(was: Proxy)
> Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5043
> URL: https://issues.jboss.org/browse/WFLY-5043
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Michal Karm Babacek
> Assignee: Stuart Douglas
> Labels: mod_cluster
>
> As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities.
> h3. Implement & Display node's Elected, Read, Transferred and Connected stats
> At the moment, this is all there is to see:
> {noformat}
> "balancer" => {
> "qa_balancer" => {"node" => {"worker-2" => {
> "load" => 89,
> "status" => "NODE_UP",
> "context" => {"/clusterbench" => {
> "requests" => 0,
> "status" => "enabled"
> }}
> }}},
> ...
> {noformat}
> Furthermore, at a glance, it appears that a part of the needed stats is a mere placeholder at the moment: [NodeStats.java|https://github.com/undertow-io/undertow/blob/master/core/s...]
> h3. Call to action
> Display the aforementioned stats for each node. Let me set priorities according to what is really used in the battlefield:
> * {color:red}Critical{color}: *Elected* (it is often correlated with *Load* during load metric *history* and *capacity* tuning)
> * {color:green}Minor{color}: *Read*
> * {color:green}Minor{color}: *Transferred*
> * {color:green}Minor{color}: *Connected*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFCORE-855) Intermittent Disconnection from CLI After Reload in domain mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-855?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-855:
------------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1249031|https://bugzilla.redhat.com/show_bug.cgi?id=1249031] from NEW to POST
> Intermittent Disconnection from CLI After Reload in domain mode
> ---------------------------------------------------------------
>
> Key: WFCORE-855
> URL: https://issues.jboss.org/browse/WFCORE-855
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.Alpha12
> Reporter: Joe Wertz
> Assignee: Joe Wertz
> Fix For: 2.0.0.Alpha12
>
> Original Estimate: 3 minutes
> Remaining Estimate: 3 minutes
>
> Description of problem:
> CLI scripts for management of managed domain
> Version-Release number of selected component (if applicable):
> 6.4.3.CP.CR1
> How reproducible:
> Always
> Steps to Reproduce:
> Use CLI script:
> :read-attribute(name=process-type)
> reload --host=master
> :read-attribute(name=process-type)
> or commands option for script
> Actual results:
> 6.4.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Failed to establish connection in 6025ms
> Expected results:
> 6.3.3
> ./jboss-cli.sh -c commands=':read-attribute(name=process-type), reload --host=master, :read-attribute(name=process-type)'
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> {
> "outcome" => "success",
> "result" => "Domain Controller"
> }
> Additional info:
> - Follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1232933
> - using --timeout doesn't workaround the problem
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months
[JBoss JIRA] (WFLY-1548) Add fallback querry to jconsole plugin
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1548?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1548:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1215278|https://bugzilla.redhat.com/show_bug.cgi?id=1215278] from ASSIGNED to POST
> Add fallback querry to jconsole plugin
> --------------------------------------
>
> Key: WFLY-1548
> URL: https://issues.jboss.org/browse/WFLY-1548
> Project: WildFly
> Issue Type: Enhancement
> Affects Versions: 8.0.0.Alpha1
> Reporter: Bartosz Baranowski
> Assignee: Darran Lofthouse
> Labels: JConsole, JMX, Plugin
> Fix For: 8.0.0.Beta1
>
>
> JConsolePlugin connecects to default port, despite chance to use proper info.
> Problem:
> Unless I miss somethingm JConsole has a bit tight isolation between components. There is no way for AS7 JConsolePlugin to access "connect dialog" info. Hence it has no idea what is the content of URL being passed as remote.
> AS7 JConsolePlugin checks if MBeanServerConnection is instance of RemotinConnection. If its not, it fallbacks to default: localhost:9990.
> However we can check for socket bindings and try to connect to proper socket.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 11 months