[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-4853:
-------------------------------------------
This test has been implemented on my private branch: https://github.com/rachmatowicz/wildfly/tree/EJB2CLUSTERS
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour is that:
> - all client invocations will complete
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The transaction set up is currently:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-4853:
--------------------------------------
Description:
The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters
{noformat}
ejb-forwarder = {node0, node1}
ejb={node3, node4}
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
The expected behaviour is that:
- all client invocations will complete
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
was:
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters
{noformat}
-- (ejb-forwarder = {node0, node1}
-- ejb={node3, node4})
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
The expected behavior is that:
- all client invocations will complete
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly test suite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> ejb-forwarder = {node0, node1}
> ejb={node3, node4}
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> Once the servers and deployments have been deployed, each server is shut down and then restarted in turn, at which time the test ends.
> The expected behaviour is that:
> - all client invocations will complete
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will fail-over from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The transaction set up is currently:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-4853:
--------------------------------------
Description:
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters
{noformat}
-- (ejb-forwarder = {node0, node1}
-- ejb={node3, node4})
{noformat}
where each node of cluster ejb-forwarder has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
The expected behavior is that:
- all client invocations will complete
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
was:
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters (ejb-forwarder = {node0, node1}, ejb={node3, node4}) where each node of clusterA has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
The expected behavior is that:
- all client invocations will complete
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters
> {noformat}
> -- (ejb-forwarder = {node0, node1}
> -- ejb={node3, node4})
> {noformat}
> where each node of cluster ejb-forwarder has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
> The expected behavior is that:
> - all client invocations will complete
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The transaction set up is currently:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-4853?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-4853:
--------------------------------------
Description:
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
The test setup:
- two clusters (ejb-forwarder = {node0, node1}, ejb={node3, node4}) where each node of clusterA has a remote outbound connection to node3
- a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
- a non-forwarding deployment on cluster ejb
- a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
The test execution:
Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
The expected behavior is that:
- all client invocations will complete
- test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
- server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
The transaction set up is currently:
- invocations from the client to ejb-forwarder are not in transaction scope
- invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
This allows exercising invocations from a managed transaction context.
was:
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters.
> Provide two cluster test case for EJBClient
> -------------------------------------------
>
> Key: WFLY-4853
> URL: https://issues.jboss.org/browse/WFLY-4853
> Project: WildFly
> Issue Type: Feature Request
> Components: Test Suite
> Affects Versions: 10.0.0.Alpha4
> Reporter: Richard Achmatowicz
>
> The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters, which does exist in the EAP test cycle.
> The test setup:
> - two clusters (ejb-forwarder = {node0, node1}, ejb={node3, node4}) where each node of clusterA has a remote outbound connection to node3
> - a forwarding SFSB deployment on cluster ejb-forwarder, which forwards invocations to cluster ejb
> - a non-forwarding deployment on cluster ejb
> - a client which makes invocations on the clustered deployment on ejb-forwarder every 10 ms
> The test execution:
> Once the servers and deployments have been deployed, each server is shutdown and then restarted in turn, at which time the test ends.
> The expected behavior is that:
> - all client invocations will complete
> - test client invocations on ejb-forwarder will fail over from node0 to node1 (or vice versa, depending on which node of cluster ejb-forwarder is down)
> - server-client invocations on ejb will failover from node3 to node 4 (or vice versa depending on which node of cluster ejb is down)
> The transaction set up is currently:
> - invocations from the client to ejb-forwarder are not in transaction scope
> - invocations from ejb-forwarder to ejb are in transaction scope with attribute REQUIRED
> This allows exercising invocations from a managed transaction context.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4853) Provide two cluster test case for EJBClient
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-4853:
-----------------------------------------
Summary: Provide two cluster test case for EJBClient
Key: WFLY-4853
URL: https://issues.jboss.org/browse/WFLY-4853
Project: WildFly
Issue Type: Feature Request
Components: Test Suite
Affects Versions: 10.0.0.Alpha4
Reporter: Richard Achmatowicz
The Wildfly testsuite is missing a test case for testing EJBClient interactions over two clusters.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (DROOLS-834) Guided scorecard source dumped to system output during KieModule build
by Jiri Locker (JIRA)
Jiri Locker created DROOLS-834:
----------------------------------
Summary: Guided scorecard source dumped to system output during KieModule build
Key: DROOLS-834
URL: https://issues.jboss.org/browse/DROOLS-834
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.3.0.Beta1
Reporter: Jiri Locker
Assignee: Mario Fusco
Priority: Minor
I find this annoying in Workbench where KieModule is built frequently without user explicitly requesting the build. The scorecard file seems to be converted into quite verbose DRL which pollutes server log when dumped.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4827) Network Connection leak on client abort connection
by Andrea Bertolini (JIRA)
[ https://issues.jboss.org/browse/WFLY-4827?page=com.atlassian.jira.plugin.... ]
Andrea Bertolini edited comment on WFLY-4827 at 7/1/15 7:05 AM:
----------------------------------------------------------------
Skipping tests I succeed in building jars. I've tested this new version and problem still persist.
I've used jconsole to check default-task and i've noticed that many tasks are stuck in a wait operation during the read phase from the stream.
Stack trace:
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:296)
sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:278)
sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:159)
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked sun.nio.ch.Util$2@77874f09
- locked java.util.Collections$UnmodifiableSet@24c4e3e0
- locked sun.nio.ch.WindowsSelectorImpl@2d48e7c7
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
org.xnio.nio.SelectorUtils.await(SelectorUtils.java:46)
org.xnio.nio.NioSocketConduit.awaitReadable(NioSocketConduit.java:345)
org.xnio.conduits.AbstractSourceConduit.awaitReadable(AbstractSourceConduit.java:66)
io.undertow.conduits.ReadDataStreamSourceConduit.awaitReadable(ReadDataStreamSourceConduit.java:101)
org.xnio.conduits.AbstractSourceConduit.awaitReadable(AbstractSourceConduit.java:66)
org.xnio.conduits.ConduitStreamSourceChannel.awaitReadable(ConduitStreamSourceChannel.java:151)
io.undertow.channels.DetachableStreamSourceChannel.awaitReadable(DetachableStreamSourceChannel.java:77)
io.undertow.server.HttpServerExchange$ReadDispatchChannel.awaitReadable(HttpServerExchange.java:1951)
org.xnio.channels.Channels.readBlocking(Channels.java:295)
io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:170)
io.undertow.servlet.spec.ServletInputStreamImpl.read(ServletInputStreamImpl.java:146)
[... READ REQUESTS FROM APPLICATION ...]
I even tried to update xnio library to new version 3.3.1, no results.
was (Author: aberto88):
Skipping tests I succeed in building jars. Now I'm going to test this new version.
> Network Connection leak on client abort connection
> --------------------------------------------------
>
> Key: WFLY-4827
> URL: https://issues.jboss.org/browse/WFLY-4827
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Sockets
> Affects Versions: 8.2.0.Final
> Environment: On Windows Server 2012, JDK 1.8.0_45, Wildfly 8.2.0.Final in standalone mode.
> Reporter: Andrea Bertolini
> Assignee: Stuart Douglas
>
> We have a classic client-server application, all written in Java. Each client is installed on a forklift which can move all around a large area. This area is under wi-fi coverage.
> Sometimes the clients can have a bad connection quality and the client-server communication is interrupted; in such a case it takes too many seconds to be restored.
> To fix this situation, we add a timeout client-side. After 5 seconds it aborts the call and tries again a second time.
> To achieve this call we use apache httpcomponents library (version 4.4). We use the abort method of httppost to interrupt this call.
> Server-side, we have a group of web-servlets which listen to the incoming calls, manage requests and send a response.
> It appears that sometimes a communication remains stuck in reading or writing from/to the stream. When the client aborts the communication, an exception is thrown on the server caused by the channel being closed.
> It happens that a large number of connections remains stuck in connection status 'established' (only server-side) even if the real connection is actually closed (client doesn't have that connection active anymore).
> When the number of established connections grows up to 200, server stops responding on port 8080, so it cannot accept more connections and it seems to freeze.
> We tried to add tcp-keep-alive=true and no-request-timeout=120000 on http-listener in undertow subsystem, but sometimes it removes idle connections after any incoming requests are received for 2 minutes, some other times it keep connections as established and doesn't close them.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (WFLY-4852) (XNIO-2 I/O-1) XNIO001007 java.util.concurrent.RejectedExecutionException error shown intermittently during server shutdown
by Ondřej Chaloupka (JIRA)
Ondřej Chaloupka created WFLY-4852:
--------------------------------------
Summary: (XNIO-2 I/O-1) XNIO001007 java.util.concurrent.RejectedExecutionException error shown intermittently during server shutdown
Key: WFLY-4852
URL: https://issues.jboss.org/browse/WFLY-4852
Project: WildFly
Issue Type: Bug
Components: Server
Reporter: Ondřej Chaloupka
Assignee: Jason Greene
Attachments: JPAProxyCrashRecoveryTestCase_haltConnectionAfterDbCommits_jta_server.log
Exception
{code}
ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1@2d696007 rejected from org.xnio.XnioWorker$TaskPool@74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
{code}, details at [1]
could be hit when stopping server. This happens intermediately.
I run transaction integration tests on WildFly/EAP7 DR builds. My tests works in way of doing some settings via CLI, deploy application, do the test, undeploy application, stop the server.
During the stopping the server this exception is shown in log.
Adding server log from my test for possible more details.
[1]
{code}
INFO [org.jboss.as.server] (Thread-3) WFLYSRV0220: Server shutdown has been requested.
INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0019: Stopped Driver service with driver-name = module_ojdbc7.jar
INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/DefaultJMSConnectionFactory
INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/JmsXA]
INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 77) WFLYMSGAMQ0006: Unbound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-7) WFLYJCA0019: Stopped Driver service with driver-name = h2
INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0019: Host default-host stopping
ERROR [org.xnio.listener] (XNIO-2 I/O-1) XNIO001007: A channel event listener threw an exception: java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteReadListener$1$1@2d696007 rejected from org.xnio.XnioWorker$TaskPool@74a153ee[Shutting down, pool size = 9, active threads = 0, queued tasks = 0, completed tasks = 50]
at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1364)
at org.xnio.XnioWorker.execute(XnioWorker.java:741)
at org.jboss.remoting3.remote.RemoteReadListener$1.handleEvent(RemoteReadListener.java:54)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.channels.TranslatingSuspendableChannel.close(TranslatingSuspendableChannel.java:906)
at org.xnio.IoUtils.safeClose(IoUtils.java:134)
at org.xnio.channels.TranslatingSuspendableChannel$3.handleEvent(TranslatingSuspendableChannel.java:133)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.StreamConnection.invokeCloseListener(StreamConnection.java:80)
at org.xnio.Connection.writeClosed(Connection.java:117)
at org.xnio.nio.AbstractNioStreamConnection.writeClosed(AbstractNioStreamConnection.java:47)
at org.xnio.nio.NioSocketConduit.terminateWrites(NioSocketConduit.java:181)
at org.xnio.nio.NioSocketConduit.truncateWrites(NioSocketConduit.java:191)
at org.xnio.conduits.ConduitStreamSinkChannel.close(ConduitStreamSinkChannel.java:186)
at org.xnio.IoUtils.safeClose(IoUtils.java:134)
at org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.forceTermination(WriteReadyHandler.java:57)
at org.xnio.nio.NioSocketConduit.forceTermination(NioSocketConduit.java:107)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:490)
INFO [org.apache.activemq.artemis.ra] (ServerService Thread Pool -- 71) AMQ151003: resource adaptor stopped
INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 71) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.0.0 [8e39e2e6-1fc3-11e5-b5ab-adb038d9447d] stopped
INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
INFO [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032018: Destroying TransactionManagerService
INFO [com.arjuna.ats.jbossatx] (MSC service thread 1-3) ARJUNA032014: Stopping transaction recovery manager
DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Recovery listener existing com.arjuna.ats.internal.arjuna.recovery.WorkerService
DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: Mode <== TERMINATED
DEBUG [com.arjuna.ats.arjuna] (MSC service thread 1-3) PeriodicRecovery: shutdown scan wait complete
DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread exiting
INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to localhost/127.0.0.1:8080
INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0004: Undertow 1.3.0.Beta2 stopping
INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: EAP 7.0.0.Alpha1 (WildFly Core 2.0.0.Alpha5) stopped in 237ms
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months