[JBoss JIRA] (WFCORE-203) CLI instance hanging around after test suite run
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-203?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise closed WFCORE-203.
---------------------------------------
Resolution: Cannot Reproduce Bug
The AbstractHandleableCloseable.close hanging has been recently fixed. Closing this bug, doesn't seem to be reproducible.
> CLI instance hanging around after test suite run
> ------------------------------------------------
>
> Key: WFCORE-203
> URL: https://issues.jboss.org/browse/WFCORE-203
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Stuart Douglas
> Assignee: Jean-Francois Denise
>
> After a test suite run I see a CLI instance that has locked up. The issue is that remoting is not shutting down cleanly for some reason, which causes the shutdown hook thread to block.
> Even though the remoting threads are deamon threads, the shutdown thread is not, so it is actually the shutdown thread the is preventing the JVM from terminating.
> Relevant stack traces are:
> {noformat}
> "Remoting "cli-client" I/O-1" daemon prio=5 tid=0x00007feefb966000 nid=0x5903 waiting on condition [0x0000000120d7d000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000007acd20818> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:389)
> at org.jboss.aesh.console.reader.ConsoleInputSession$1.read(ConsoleInputSession.java:39)
> at org.jboss.aesh.terminal.POSIXTerminal.read(POSIXTerminal.java:95)
> at org.jboss.aesh.console.Console.read(Console.java:397)
> at org.jboss.aesh.console.Console.read(Console.java:346)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:178)
> at org.jboss.as.cli.impl.CommandContextImpl.readLine(CommandContextImpl.java:750)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSSLFailure(CommandContextImpl.java:966)
> at org.jboss.as.cli.impl.CommandContextImpl.access$500(CommandContextImpl.java:170)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager$1.run(CommandContextImpl.java:1636)
> at org.jboss.as.protocol.GeneralTimeoutHandler.suspendAndExecute(GeneralTimeoutHandler.java:45)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager.checkServerTrusted(CommandContextImpl.java:1631)
> at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:827)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1328)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1227)
> - locked <0x00000007ac085000> (a sun.security.ssl.SSLEngineImpl)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:542)
> - locked <0x00000007ac085000> (a sun.security.ssl.SSLEngineImpl)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:313)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:203)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:297)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:284)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:93)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {noformat}
> {noformat}
> "Thread-2" prio=5 tid=0x00007feefa0ca800 nid=0x440b in Object.wait() [0x0000000121177000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007ac03d518> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> - locked <0x00000007ac03d518> (a java.lang.Object)
> at org.jboss.as.cli.impl.CLIModelControllerClient$1.shutdown(CLIModelControllerClient.java:98)
> at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> - locked <0x00000007abd8b4a8> (a java.util.ArrayList)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-203) CLI instance hanging around after test suite run
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-203?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise reassigned WFCORE-203:
-------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> CLI instance hanging around after test suite run
> ------------------------------------------------
>
> Key: WFCORE-203
> URL: https://issues.jboss.org/browse/WFCORE-203
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Stuart Douglas
> Assignee: Jean-Francois Denise
>
> After a test suite run I see a CLI instance that has locked up. The issue is that remoting is not shutting down cleanly for some reason, which causes the shutdown hook thread to block.
> Even though the remoting threads are deamon threads, the shutdown thread is not, so it is actually the shutdown thread the is preventing the JVM from terminating.
> Relevant stack traces are:
> {noformat}
> "Remoting "cli-client" I/O-1" daemon prio=5 tid=0x00007feefb966000 nid=0x5903 waiting on condition [0x0000000120d7d000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000007acd20818> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
> at java.util.concurrent.ArrayBlockingQueue.poll(ArrayBlockingQueue.java:389)
> at org.jboss.aesh.console.reader.ConsoleInputSession$1.read(ConsoleInputSession.java:39)
> at org.jboss.aesh.terminal.POSIXTerminal.read(POSIXTerminal.java:95)
> at org.jboss.aesh.console.Console.read(Console.java:397)
> at org.jboss.aesh.console.Console.read(Console.java:346)
> at org.jboss.as.cli.impl.Console$Factory$1.readLine(Console.java:178)
> at org.jboss.as.cli.impl.CommandContextImpl.readLine(CommandContextImpl.java:750)
> at org.jboss.as.cli.impl.CommandContextImpl.handleSSLFailure(CommandContextImpl.java:966)
> at org.jboss.as.cli.impl.CommandContextImpl.access$500(CommandContextImpl.java:170)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager$1.run(CommandContextImpl.java:1636)
> at org.jboss.as.protocol.GeneralTimeoutHandler.suspendAndExecute(GeneralTimeoutHandler.java:45)
> at org.jboss.as.cli.impl.CommandContextImpl$LazyDelagatingTrustManager.checkServerTrusted(CommandContextImpl.java:1631)
> at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:827)
> at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1328)
> at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
> at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1227)
> - locked <0x00000007ac085000> (a sun.security.ssl.SSLEngineImpl)
> at org.xnio.ssl.JsseSslConduitEngine.handleHandshake(JsseSslConduitEngine.java:542)
> - locked <0x00000007ac085000> (a sun.security.ssl.SSLEngineImpl)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:313)
> at org.xnio.ssl.JsseSslConduitEngine.wrap(JsseSslConduitEngine.java:203)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:98)
> at org.xnio.ssl.JsseSslStreamSinkConduit.write(JsseSslStreamSinkConduit.java:72)
> at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:297)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$StringWriteListener.handleEvent(HttpUpgrade.java:284)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:93)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
> {noformat}
> {noformat}
> "Thread-2" prio=5 tid=0x00007feefa0ca800 nid=0x440b in Object.wait() [0x0000000121177000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000007ac03d518> (a java.lang.Object)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
> - locked <0x00000007ac03d518> (a java.lang.Object)
> at org.jboss.as.cli.impl.CLIModelControllerClient$1.shutdown(CLIModelControllerClient.java:98)
> at org.jboss.as.cli.impl.CliShutdownHook$1.run(CliShutdownHook.java:50)
> - locked <0x00000007abd8b4a8> (a java.util.ArrayList)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment with audit logging enabled
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise reassigned WFCORE-695:
-------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1545) File path to file content replacement is bound to validation
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1545?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-1545:
--------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> File path to file content replacement is bound to validation
> ------------------------------------------------------------
>
> Key: WFCORE-1545
> URL: https://issues.jboss.org/browse/WFCORE-1545
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> DefaultBatch and OperationRequestHandler are making the replacement only if validation is enabled.
> It seems that users are expecting the replacement to be done in all cases.
> Doing so we would make operation description retrieval mandatory for all requests. This could have an impact on the CLI performance.
> We should have a configuration option to disable the replacement. By default the replacement should be enabled. With validation OFF and replacement OFF, we would have no extra requests sent by the CLI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1496) rollback-across-groups completion
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1496?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise reassigned WFCORE-1496:
--------------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> rollback-across-groups completion
> ---------------------------------
>
> Key: WFCORE-1496
> URL: https://issues.jboss.org/browse/WFCORE-1496
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 3.0.0.Alpha1
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> rollout completion ignores the fact that the rollback-across-groups can be set to true or false. It does not propose true/false. That is fine.
> If one write rollback-across-groups=, there is no completion.
> If one write rollback-across-groups=t the completion is lost and the following completion is done: rollback-across-groups=tollback-across-groups
> So completion should better handle the rollback-across-groups= case.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months