[JBoss JIRA] (WFLY-4017) EjbClientContextSetupProcessor uses ServiceRegistry.getService()
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-4017:
------------------------------------
Summary: EjbClientContextSetupProcessor uses ServiceRegistry.getService()
Key: WFLY-4017
URL: https://issues.jboss.org/browse/WFLY-4017
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Stuart Douglas
Assignee: Stuart Douglas
As no dependencies are in place there is no guarantee this service will exist. If a deployment is present at boot time it is possible that this will not be setup correctly.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-4001) Virtual host in jboss-web.xml doesn't work
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4001?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on WFLY-4001:
------------------------------
Thanks Tomaz. How can I define the http-listener for "vhost2" ? I intend to start another http port which is dedicated for "vhost2", like the following AS7 configuration . Do I have to define another server-instance with different http-listener and vitural host element ? Should we allow specify http-listener for host element ?
{code}
<subsystem xmlns="urn:jboss:domain:web:2.1" default-virtual-server="default-host" native="false">
<connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/>
<connector name="http-1" protocol="HTTP/1.1" scheme="http" socket-binding="http-1">
<virtual-server name="localhost4"/>
</connector>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
<virtual-server name="localhost4" enable-welcome-root="true">
<alias name="localhost4"/>
</virtual-server>
</subsystem>
{code}
> Virtual host in jboss-web.xml doesn't work
> ------------------------------------------
>
> Key: WFLY-4001
> URL: https://issues.jboss.org/browse/WFLY-4001
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jim Ma
> Assignee: Tomaz Cerar
> Attachments: host.war
>
>
> Define the following configuration for undertow subsystem and deploy the attached host.war with virtual host "vhost2" metada in jboss-web.xml.
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:undertow:2.0">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <server name="undertow-server2">
> <http-listener name="listener2" socket-binding="http2"/>
> <host name="vhost2" alias="localhost4">
> <location name="/" handler="welcome-content2"/>
> <filter-ref name="server-header"/>
> <filter-ref name="x-powered-by-header"/>
> </host>
> </server>
> <servlet-container name="default">
> <jsp-config/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
> <file name="welcome-content2" path="${jboss.home.dir}/welcome-content2"/>
> </handlers>
> <filters>
> <response-header name="server-header" header-name="Server" header-value="WildFly/9"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> </filters>
> </subsystem>
> {code}
> Deploy is failed with error message :
> 14:37:27,092 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "host.war")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.undertow.deployment.default-server.vhost2./host is missing [jboss.undertow.server.default-server.vhost2]",
> "jboss.undertow.deployment.default-server.vhost2./host.UndertowDeploymentInfoService is missing [jboss.undertow.server.default-server.vhost2]"
> ]}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-643) Spreadsheet cell value by XLS function results in decimal fraction
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-643:
----------------------------------------
Summary: Spreadsheet cell value by XLS function results in decimal fraction
Key: DROOLS-643
URL: https://issues.jboss.org/browse/DROOLS-643
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Beta1, 6.1.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mark Proctor
If you use XLS functions (e.g. =ROW(), =SUM()) in Spreadsheet cells, the values (e.g. '10') are parsed to decimal fraction values (e.g. '10.0'). This doesn't occur in version 5.3.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-642) Named Consequences do not respect timers in STREAM mode
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-642:
-------------------------------------
Summary: Named Consequences do not respect timers in STREAM mode
Key: DROOLS-642
URL: https://issues.jboss.org/browse/DROOLS-642
Project: Drools
Issue Type: Bug
Reporter: Davide Sottara
Assignee: Mark Proctor
In the rule:
{code}
when
$a : A()
not B( this after[0,10s] $a ) do[something]
C()
then
then[something]
{code}
No timer node is created for the named consequence, resulting in the named consequence firing immediately, even in STREAM mode
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (DROOLS-641) Named Consequences don't work with events
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-641:
-------------------------------------
Summary: Named Consequences don't work with events
Key: DROOLS-641
URL: https://issues.jboss.org/browse/DROOLS-641
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR1, 6.1.0.Final, 6.0.0.Final
Reporter: Davide Sottara
Assignee: Mark Proctor
Given e.g. a rule :
{code}
when
Event()
AnotherEvent() do[something]
then ... end
{code}
A stream queue is created only for the main path (main consequence).
The events never reach then named consequence, failing to match it.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-203) CLI instance hanging around after test suite run
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-203?page=com.atlassian.jira.plugin... ]
Stuart Douglas updated WFCORE-203:
----------------------------------
Description:
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}
was:
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)
{notformat}
{notformat}
"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)
{notformat}
> 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: Alexey Loubyansky
>
> 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
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFCORE-203) CLI instance hanging around after test suite run
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-203:
-------------------------------------
Summary: 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: Alexey Loubyansky
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)
{notformat}
{notformat}
"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)
{notformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months
[JBoss JIRA] (WFLY-4014) TransactionReaper wedged and not responding to interrupts (ARJUNA012378, ARJUNA012120)
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4014?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-4014 at 10/26/14 5:26 PM:
----------------------------------------------------------------
Reproduced stuck on shutdown condition with logs and stacktraces. Logs attached.
The host1/node1 could not be shutdown without SIGKILL JVM.
Post-SIGKILL host reaper reported
{noformat}
[Server:node1] 16:01:56,651 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017532: Host default-host stopping
[Server:node1] 16:21:47,935 INFO [org.jboss.as.process.Server:node1.status] (reaper for Server:node1) JBAS012010: Process 'Server:node1' finished with an exit status of 137
[Host Controller] 16:21:47,936 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering server node1
[Host Controller] 16:21:47,939 INFO [org.jboss.as.host.controller] (Remoting "aimobile-sm.servicemesh.com:MANAGEMENT" I/O-1) JBAS010926: Unregistering server node1
[Host Controller] 16:21:47,984 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 1206387ms
[Host Controller] 16:21:47,996 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 0
16:21:47,997 INFO [org.jboss.as.process] (Thread-12) JBAS012015: All processes finished; exiting
{noformat}
was (Author: arcivanov):
Reproduced stuck on shutdown condition with logs and stacktraces. Logs attached.
The host1/node1 could not be shutdown without SIGKILL JVM.
Post-SIGKILL host reaper reported
{noformat}
[Server:node1] 16:01:56,651 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017532: Host default-host stopping
[Server:node1]
16:21:47,935 INFO [org.jboss.as.process.Server:node1.status] (reaper for Server:node1) JBAS012010: Process 'Server:node1' finished with an exit status of 137
[Host Controller] 16:21:47,936 INFO [org.jboss.as.host.controller] (ProcessControllerConnection-thread - 2) JBAS010926: Unregistering server node1
[Host Controller] 16:21:47,939 INFO [org.jboss.as.host.controller] (Remoting "aimobile-sm.servicemesh.com:MANAGEMENT" I/O-1) JBAS010926: Unregistering server node1
[Host Controller] 16:21:47,984 INFO [org.jboss.as] (MSC service thread 1-1) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 1206387ms
[Host Controller]
16:21:47,996 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 0
16:21:47,997 INFO [org.jboss.as.process] (Thread-12) JBAS012015: All processes finished; exiting
{noformat}
> TransactionReaper wedged and not responding to interrupts (ARJUNA012378, ARJUNA012120)
> --------------------------------------------------------------------------------------
>
> Key: WFLY-4014
> URL: https://issues.jboss.org/browse/WFLY-4014
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.1.0.Final
> Environment: Darwin Keith-Yarbroughs-MBPro.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64
> Reporter: Arcadiy Ivanov
> Assignee: Tom Jenkinson
> Attachments: cluster_logs.2014-10-23T23-37-03.tar.gz, cluster_logs.2014-10-24T16-50-50.tar.gz, stuck-shutdown-wedged-reaper-logs.tar.gz
>
>
> This issue is definitely intermittent and appeared first time ever in several months. It is severe enough, however (server node becomes unresponsive and can only be killed with SIGKILL) that I'm reporting it.
> Issue occurred while running an Arquillian test. I don't know how to reproduce it.
> The system is as follows:
> * There is a multi-host multi-node WildFly domain cluster residing on a single machine (127.0.0.(1+N) IPs, N > 0).
> * There is a multi-node Postgres-XL cluster configured (127.0.1.(1+N) IPs, N > 0) configured.
> * There is a HAJDBC module configured. HAJDBC cluster is configured with datasources from WildFly datasources subsystem which has a datasource for each node of Postgres-XL cluster.
> There is [another mention on the Inet of the same problem|https://developer.jboss.org/thread/240172] without such an exotic setup, but rather with simply a MySQL 5.6, although information is scarce.
> {noformat}
> 2014-10-23 23:19:47,127 INFO [org.wildfly.extension.undertow] (MSC service thread 1-16) JBAS017534: Registered web context: /test
> 2014-10-23 23:19:47,154 INFO [org.jboss.as.server] (ServerService Thread Pool -- 64) JBAS018559: Deployed "1208cb8c-2b19-4d9a-a8b9-101f6e9e778f.ear" (runtime-name : "1208cb8c-2b19-4d9a-a8b9-101f6e9e778f.ear")
> 2014-10-23 23:24:47,417 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state RUN
> 2014-10-23 23:24:47,420 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a801f4:-475d22cc:5449ccbe:2f invoked while multiple threads active within it.
> 2014-10-23 23:24:47,420 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a801f4:-475d22cc:5449ccbe:2f aborting with 1 threads active!
> 2014-10-23 23:24:47,918 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state CANCEL
> 2014-10-23 23:24:47,920 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012378: ReaperElement appears to be wedged: sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> java.util.concurrent.locks.ReentrantLock$FairSync.lock(ReentrantLock.java:229)
> java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.lock(BaseWrapperManagedConnection.java:373)
> org.jboss.jca.adapters.jdbc.local.LocalManagedConnection.rollback(LocalManagedConnection.java:113)
> org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.rollback(LocalXAResourceImpl.java:242)
> com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.rollback(XAOnePhaseResource.java:196)
> com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelAbort(LastResourceRecord.java:126)
> com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2939)
> com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2918)
> com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1632)
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:116)
> com.arjuna.ats.arjuna.AtomicAction.cancel(AtomicAction.java:215)
> com.arjuna.ats.arjuna.coordinator.TransactionReaper.doCancellations(TransactionReaper.java:377)
> com.arjuna.ats.internal.arjuna.coordinator.ReaperWorkerThread.run(ReaperWorkerThread.java:78)
> 2014-10-23 23:24:48,421 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f in state CANCEL_INTERRUPTED
> 2014-10-23 23:24:48,422 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012120: TransactionReaper::check worker Thread[Transaction Reaper Worker 0,5,main] not responding to interrupt when cancelling TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f -- worker marked as zombie and TX scheduled for mark-as-rollback
> 2014-10-23 23:24:48,422 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012110: TransactionReaper::check successfuly marked TX 0:ffffc0a801f4:-475d22cc:5449ccbe:2f as rollback only
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 9 months