[JBoss JIRA] (WFLY-5567) Update to HAL 2.8.13.Final
by Heiko Braun (JIRA)
Heiko Braun created WFLY-5567:
---------------------------------
Summary: Update to HAL 2.8.13.Final
Key: WFLY-5567
URL: https://issues.jboss.org/browse/WFLY-5567
Project: WildFly
Issue Type: Component Upgrade
Components: Web Console
Reporter: Heiko Braun
Assignee: Heiko Braun
Priority: Blocker
Fix For: 10.0.0.CR4
Remaining updates for WF 10
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-5566:
------------------------------
Affects Version/s: 10.0.0.CR2
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Paul Ferraro
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
Ivan Straka created WFLY-5566:
---------------------------------
Summary: org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
Key: WFLY-5566
URL: https://issues.jboss.org/browse/WFLY-5566
Project: WildFly
Issue Type: Bug
Components: Clustering, Test Suite
Reporter: Ivan Straka
Assignee: Paul Ferraro
There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
{code:java}
Error Message
expected:<500> but was:<200>
Stacktrace
java.lang.AssertionError: expected:<500> but was:<200>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil closed WFLY-4866.
-----------------------------
Fix Version/s: 10.0.0.CR3
Resolution: Done
Underlying ARTEMIS-155 issue has been fixed in Artemis 1.1.0.wildfly.007
> messaging-activemq: NPE when http-acceptor and https-acceptor configured
> ------------------------------------------------------------------------
>
> Key: WFLY-4866
> URL: https://issues.jboss.org/browse/WFLY-4866
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.1.0.Final, 10.0.0.CR2
> Environment: Windows 7 Pro, Java 7u55
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Labels: JMS, Messaging
> Fix For: 10.0.0.CR3
>
> Attachments: server-logs.zip
>
>
> With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log.
> I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped.
> Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException.
> I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method.
> The workaround in the ticket works because the redundant <param> causes the equals() method to see the two acceptors as unequal.
> The exception was:
> [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
> [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
> [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
> [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
> [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
> [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
> [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
> [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
> [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
> [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
> [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
> [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
> [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
> [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
> [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
> [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Paul Ferraro reassigned WFCORE-1029:
------------------------------------
Assignee: Brian Stansberry
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
> Assignee: Brian Stansberry
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1029) ManagedSocketFactory doesn't work for client sockets
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1029?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFCORE-1029:
--------------------------------------
I'm pretty sure this is a duplicate of WFCORE-1033, which was already fixed. There was no component set for this jira, so nobody owns it currently. I'm assigning to Brian.
> ManagedSocketFactory doesn't work for client sockets
> ----------------------------------------------------
>
> Key: WFCORE-1029
> URL: https://issues.jboss.org/browse/WFCORE-1029
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 2.0.0.CR5
> Reporter: Dennis Reed
>
> SocketBindingManagerImpl does not work with client sockets.
> It adds sockets to a map based on local address. Client sockets that have not been bound yet do not have a local address.
> This breaks the JGroups subsystem's ManagedSocketFactory, which uses SocketBindingManagerImpl for both server and client sockets.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5543) Can't recover transaction started by MDB on WSMQ when RAR is deployed as an archive
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5543?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5543:
----------------------------------------
[~jesper.pedersen] mentioned that the documentation https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Applicatio... says that resource adapter needs to be repacked to contain file {{mqetclient.jar}}. I have to admit that rar archive that we use does not contain that. But I have tried the run with the repacked rar archive and there is no change in behavior. I rather think that there is an issue in our documentation.
In case that the file {{com.ibm.mqetclient.jar}} would be needed it could be find in repository http://git.app.eng.bos.redhat.com/git/jbossqe-eap-tests-transactions.git under branch master.
What I can say XA transactions works fine for outbound connection, even recovery, even withouth {{mqetclient.jar}}. The troubles came when MDB is in play. Non-MDB scenario is the same just there is only ejb bean sending messages to a queue and jvm is crashed at some point of time
{code}
rm -rf jbossts/target && mkdir -p jbossts/target && cp -r ~/jms/eap-tests-wsmq jbossts/target/
mvn verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JMSCrashRecoveryRemoteTestCase#commitHaltAtPhaseBeginning -Djbossts.noJTS -Dmessaging.remote -Dibmmq.remote -Dno.cleanup
{code}
The same trouble happens for the MDB scenario when WSMQ 8 is used. There is the same class loading issue
{code}
rm -rf jbossts/target && mkdir -p jbossts/target && cp -r ~/jms/eap-tests-wsmq jbossts/target/
mvn verify -am -pl jbossts -DfailIfNoTests=false -Dtest=JMSMdbCrashRecoveryRemoteTestCase#commitHaltAtPhaseBeginning -Djbossts.noJTS -Dmessaging.remote -Dibmmq.remote -Dibmmq8 -Dno.cleanup
{code}
It's probably only coincidence but we have another issue with MDB where rar(?) does not provide enough information to recovery to finish txn: issue https://issues.jboss.org/browse/JBEAP-1497
> Can't recover transaction started by MDB on WSMQ when RAR is deployed as an archive
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5543
> URL: https://issues.jboss.org/browse/WFLY-5543
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR2
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Priority: Blocker
> Fix For: 10.0.0.CR4
>
> Attachments: standalone-full.wmq.xml, tx-object-store.zip
>
>
> There is a problem with recovering transaction started by MDB pointing to a WSMQ JMS resource.
> If I do so then the recovery process fails with [1]
> {code}WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016043: Exception on attempting to restore XAResource: java.lang.ClassNotFoundException: com.ibm.mq.connector.xa.XARWrapper from [Module "org.jboss.jts:main" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:626)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:969)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1118)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:488)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:451)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:50)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:149)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:793)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
> WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012154: RecoverAtomicAction: transaction 0:ffff0a28048f:-470895ed:5624c495:34 not activated, unable to replay phase 2 commit. Check state has not already been completed.
> InputObjectState Type : /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> InputObjectState Size : 7204
> InputObjectState Buffer: )
> WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012379: ExpiredTransactionScanner - 0:ffff0a28048f:-470895ed:5624c495:34 is assumed complete and will be moved.
> {code}
> This means that instead of commiting the unfinished transaction the txn log is put to expired part of txn object store and the transaction on wsmq broker side is left in-doubt.
> I'm attaching my configuration file.
> [1] trace level on transaction manager log category
> {code}
> WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016043: Exception on attempting to restore XAResource: java.lang.ClassNotFoundException: com.ibm.mq.connector.xa.XARWrapper from [Module "org.jboss.jts:main" from local module loader @707f7052 (finder: local module finder @11028347 (roots: /home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/modules,/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:626)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:969)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1118)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:488)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:451)
> at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:50)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:149)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:253)
> at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:109)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:793)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) RecoverAtomicAction.replayPhase2 recovering 0:ffff0a28048f:-470895ed:5624c495:34 ActionStatus is ActionStatus.COMMITTED
> WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012154: RecoverAtomicAction: transaction 0:ffff0a28048f:-470895ed:5624c495:34 not activated, unable to replay phase 2 commit. Check state has not already been completed.
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 2, 0 )
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction()
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff0a28048f_-470895ed_5624c495_34, FileLock.F_RDLCK, false)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff0a28048f_-470895ed_5624c495_34, java.io.FileInputStream@13c3edbd, null)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState(InputObjectState Uid : 0:ffff0a28048f:-470895ed:5624c495:34
> InputObjectState Type : /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> InputObjectState Size : 7204
> InputObjectState Buffer: )
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.write_committed(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.write_state(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired, 11)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired/0_ffff0a28048f_-470895ed_5624c495_34, FileLock.F_WRLCK, true)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.createHierarchy(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired/0_ffff0a28048f_-470895ed_5624c495_34)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/Expired/0_ffff0a28048f_-470895ed_5624c495_34, null, java.io.FileOutputStream@322aab6a)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.remove_committed(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.remove_state(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff0a28048f:-470895ed:5624c495:34, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff0a28048f_-470895ed_5624c495_34, FileLock.F_WRLCK, false)
> TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/jboss/jboss-eap-7.0.0.DR11-wsmq2/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff0a28048f_-470895ed_5624c495_34, null, null)
> WARN [com.arjuna.ats.arjuna] (Periodic Recovery) ARJUNA012379: ExpiredTransactionScanner - 0:ffff0a28048f:-470895ed:5624c495:34 is assumed complete and will be moved.
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery)
> DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - second pass
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery)
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS
> DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule - second pass
> DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change SECOND_PASS->IDLE
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery)
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5562) Simplify GC logging configuration in domain mode
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5562?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5562:
----------------------------------------
This is a duplicate of something in WFCORE, isn't it?
> Simplify GC logging configuration in domain mode
> ------------------------------------------------
>
> Key: WFLY-5562
> URL: https://issues.jboss.org/browse/WFLY-5562
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Priority: Minor
>
> In standalone mode, you can turn on GC logging relatively easily by adding the set of options to standalone.conf or uncommenting the section in standalone.sh/bat.
> Turning it on for managed servers in domain mode is much more complex. The main options to control GC logging can be added to the <jvm-options> in <jvm>s, but the log location in "-Xloggc:" is server specific so they do not overwrite each other. As noted on https://developer.jboss.org/thread/237355 you cannot use a substitution like "${jboss.server.log.dir}" since they are done by the host controller once and not per-server, and that is not set at resolution time. This means that every individual server in host.xml needs a <jvm><jvm-options> configuration to set that, which is tedious and error prone.
> It would be good to provide a way of configuring GC logging for managed servers in domain mode which is simpler and less likely to cause mistakes. Two mechanisms that may be options would be the following, but there may be others:
> * Supporting per-server substitutions in domain.xml <jvm> definitions, so ${jboss.server.log.dir} could be used
> * a <gc-logging> option similar to <heap>, with a few options and WF knows how to add the correction options. This may require that WF knows more about which java implementation is being used
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months