[JBoss JIRA] (WFLY-5645) Use script name for file related to Wildfly to allow multiple instances easily
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-5645:
------------------------------------
Summary: Use script name for file related to Wildfly to allow multiple instances easily
Key: WFLY-5645
URL: https://issues.jboss.org/browse/WFLY-5645
Project: WildFly
Issue Type: Enhancement
Components: Scripts
Affects Versions: 10.0.0.CR4
Reporter: Romain Pelisse
Assignee: Tomaz Cerar
Priority: Optional
With the current provided init.d script, one cannot start several instances of Wildfly. Indeed, the script will associate the same files (pid file, log) to both instance. If we rename those files using, for instance, the name of the script we can easily use the *exact same script* for all local instances:
{code:bash}
# ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-1
# ln -s ..../init.d/wildfly-initd-redhat.sh /etc/init.d/wildfly-2
{code}
And to take the example of the PIDFILE:
{code:bash}
JBOSS_PIDFILE=/var/run/$(basename $0)/jboss-as-domain.pid
{code}
Each links will then look up and creates its own separate file:
/var/run/wildfly-1/jboss-as-domain.pid
/var/run/wildfly-2/jboss-as-domain.pid
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5644) EJB timers should use a different logging category to separate it from other EJB invocations
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-5644?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink commented on WFLY-5644:
----------------------------------------
-- Text for the release note --
Logging enhancement for EJB timer.
Timer services can now use a separate category "org.jboss.as.ejb3.timer" to track timer events in DEBUG or TRACE level without affecting the complete EJB logging.
The message identifiers (i.e. WFLYEJB0022) remain the same as before.
> EJB timers should use a different logging category to separate it from other EJB invocations
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5644
> URL: https://issues.jboss.org/browse/WFLY-5644
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: ejb, timer, timers, timerservice
>
> To analyze timer behaviour or track issues related to timers sometimes a log level higher than INFO is needed.
> Unfortunately the category "org.jboss.as.ejb3" does not make a differenciation and setting this category to DEBUG or TRACE cause a high amount of log messages, this can have performance impacts and make it dfficult to handle and read the logfiles.
> It should be possible to have a separate category for timers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5638) "Buffer was already freed" error from http request processing
by Arto Huusko (JIRA)
[ https://issues.jboss.org/browse/WFLY-5638?page=com.atlassian.jira.plugin.... ]
Arto Huusko commented on WFLY-5638:
-----------------------------------
That commit fixes buffer leak, but this is about a socket leak, and my wildfly instance is already patched with that commit.
But please see XNIO-254, which I just updated with a new patch to JsseSslConduitEngine which should avoid the "buffer was already freed" and therefore any problems the unexpeced IllegalStateException can cause.
> "Buffer was already freed" error from http request processing
> -------------------------------------------------------------
>
> Key: WFLY-5638
> URL: https://issues.jboss.org/browse/WFLY-5638
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.1.Final
> Reporter: Arto Huusko
> Assignee: Stuart Douglas
> Attachments: stacktrace.txt
>
>
> Undertow causes XNIO exception "Buffer was already freed" during response write, possibly due to premature client close.
> I suspect this may also cause the socket to leak, because the number of "Buffer was already freed" messages in widlfly server.log corresponds to the number of leaked sockets in the lsof command output for the wildfly process (seen as sockets with "can't identify protocol" description).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1049:
------------------------------------------
[~swd847] Thanks for the link. That's another example of the same failure pattern.
"Also I'm not sure why you can't just use a sync block to make sure that the underlying object is fully initialized before it is published?"
All the getter methods on the MRR would need to be synchronized for that to help. That's doable and probably simpler but now we've made methods that get called a lot synchronized. I don't expect much contention around those calls, but there's some overhead.
Doing that would remove the need for the last 2 commits in my PR, but only if I went back to doing the registerAttributes/Operations/Descriptions calls after I published the MRR.
> ConcreteResourceRegistration#registerSubModel is not thread safe
> ----------------------------------------------------------------
>
> Key: WFCORE-1049
> URL: https://issues.jboss.org/browse/WFCORE-1049
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> registerSubModel checks for existing, then registers, however it is invoked by two threads at the same time it is possible they will both see the resource as not existing and both register.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5543) Can't recover transaction started by MDB on WSMQ when RAR is deployed as an archive
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-5543?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-5543:
---------------------------------
The fix of JBTM-2550 should be in the narayana 5.2.8.Final
> 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: JCA, Transactions
> Affects Versions: 10.0.0.CR2
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.Final
>
> 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, 8 months
[JBoss JIRA] (WFLY-5644) EJB timers should use a different logging category to separate it from other EJB invocations
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-5644:
--------------------------------------
Summary: EJB timers should use a different logging category to separate it from other EJB invocations
Key: WFLY-5644
URL: https://issues.jboss.org/browse/WFLY-5644
Project: WildFly
Issue Type: Feature Request
Reporter: Wolf-Dieter Fink
Assignee: Wolf-Dieter Fink
To analyze timer behaviour or track issues related to timers sometimes a log level higher than INFO is needed.
Unfortunately the category "org.jboss.as.ejb3" does not make a differenciation and setting this category to DEBUG or TRACE cause a high amount of log messages, this can have performance impacts and make it dfficult to handle and read the logfiles.
It should be possible to have a separate category for timers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1049) ConcreteResourceRegistration#registerSubModel is not thread safe
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1049?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1049:
------------------------------------------
Here's one:
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=75813&tab=buil...
{code}
05:18:46,317 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: org.jboss.msc.service.StartException in service jboss.ra.deployer."ear_packaged.ear#ear_packaged2.rar".jboss.ironjacamar.resource: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.jboss.as.connector.services.resourceadapters.IronJacamarActivationResourceService.start(IronJacamarActivationResourceService.java:196)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
{code}
The failing code is:
{code}
ManagementResourceRegistration cdRegistration = raRegistration.getSubModel(PathAddress.pathAddress(peCD));
ManagementResourceRegistration overrideCdRegistration = cdRegistration.registerOverrideModel(cm.getJndiName(), new OverrideDescriptionProvider() {
{code}
Dereferencing cdRegistration throws the NPE. It's null because raRegistration is a ref to an incompletely populated MRR.
I found another failure of that test, and it was in a different spot in IronJacamarActivationResourceService but the same basic pattern -- getSubModel is called on an MRR and it unexpectedly returns null.
These failures are hard to find in CI because its not a test method that fails, it's the preliminary ARQ setup (i.e. deployment) work. So you can't look up the test method in any test run and then check the history to find failures.
> ConcreteResourceRegistration#registerSubModel is not thread safe
> ----------------------------------------------------------------
>
> Key: WFCORE-1049
> URL: https://issues.jboss.org/browse/WFCORE-1049
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Stuart Douglas
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> registerSubModel checks for existing, then registers, however it is invoked by two threads at the same time it is possible they will both see the resource as not existing and both register.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5643) h:graphicImage cannot show
by Seigo HOSHI (JIRA)
Seigo HOSHI created WFLY-5643:
---------------------------------
Summary: h:graphicImage cannot show
Key: WFLY-5643
URL: https://issues.jboss.org/browse/WFLY-5643
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 9.0.2.Final
Reporter: Seigo HOSHI
Assignee: Farah Juma
The following tag cannot show image in WildFly 9.0.2.Final.
<h:graphicImage library="image/aaa" name="bbb.png"/>
It has shown in 9.0.1.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months