[JBoss JIRA] (WFLY-1518) HornetQBackupActivationTestCase runs into intermittent failures
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1518?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-1518:
-----------------------------
Fix Version/s: 9.0.0.Final
> HornetQBackupActivationTestCase runs into intermittent failures
> ---------------------------------------------------------------
>
> Key: WFLY-1518
> URL: https://issues.jboss.org/browse/WFLY-1518
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: jaikiran pai
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Final
>
> Attachments: log.txt
>
>
> The HornetQBackupActivationTestCase#testPassiveBackupReload() failed on TeamCity environment against latest upstream/master. I haven't yet had a detailed look at it. The exception stacktrace looks like:
> {code}
> Caused by: java.util.concurrent.ExecutionException: Operation failed
> at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 93 more
> Caused by: java.io.IOException: Channel closed
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:381)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:137)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:134)
> at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:399)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:108)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
> at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> {code}
> There's also some complaints about connection leaks in those logs:
> {code}
> 13:17:26,866 WARN [org.jboss.as.controller.client] (Finalizer) JBAS010600: Closing leaked controller client: JBAS010649: Allocation stack trace:
> at java.lang.Thread.getStackTrace(Thread.java:1567)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:337)
> at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:147)
> at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.createBackupClient(HornetQBackupActivationTestCase.java:107)
> at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.waitForBackupServerToReload(HornetQBackupActivationTestCase.java:297)
> at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.testActiveBackupReload(HornetQBackupActivationTestCase.java:224)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> The entire log has been attached to the JIRA.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-3162) audit syslog handler should be able to automatically reconnect
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3162?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3162:
-----------------------------
Fix Version/s: 9.0.0.Final
> audit syslog handler should be able to automatically reconnect
> --------------------------------------------------------------
>
> Key: WFLY-3162
> URL: https://issues.jboss.org/browse/WFLY-3162
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Tom Fonteyne
> Assignee: Kabir Khan
> Labels: EAP
> Fix For: 9.0.0.Final
>
>
> When the syslog server goes down, WF will retry (up to 10 times we believe) to reconnect but will then give up. You can manually force a reconnect by issuing:
> /host=master/core-service=management/access=audit/syslog-handler=mysyslog:recycle
> This request is to make it possible to automate this and make it configurable at which interval it should try and reconnect
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month