[JBoss JIRA] (JBTM-2081) Why do we mandate the property file?
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2081?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2081:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/609
Hi Mark,
I was getting a different exception to you when I didn't provide a config file (I got a FileNotFoundException).
If you can share your code that gets the null ExceptionINInitializerError I can check my pull will handle your scenario.
Thanks,
Tom
> Why do we mandate the property file?
> ------------------------------------
>
> Key: JBTM-2081
> URL: https://issues.jboss.org/browse/JBTM-2081
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 5.0.2
>
>
> I noticed this originally when doing the Android port, but now again when doing vert.x: at some point over the years we appear to have moved to a model where the properties file must be present (e.g., in class path or CWD) or we exit. I'm not sure why we do this given that every property has a default value anyway.
> For example:
> java.lang.ExceptionInInitializerError: null
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getPropertiesFromFile(PropertiesFactory.java:93)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.initDefaultProperties(PropertiesFactory.java:236)
> at com.arjuna.common.util.propertyservice.PropertiesFactory.getDefaultProperties(PropertiesFactory.java:66)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:77)
> at com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:49)
> at com.arjuna.ats.txoj.common.txojPropertyManager.getTxojEnvironmentBean(txojPropertyManager.java:48)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (JBTM-2114) back-port JBTM-2105 to 4.17
by Will Reichert (JIRA)
Will Reichert created JBTM-2114:
-----------------------------------
Summary: back-port JBTM-2105 to 4.17
Key: JBTM-2114
URL: https://issues.jboss.org/browse/JBTM-2114
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Core
Affects Versions: 4.17.17
Reporter: Will Reichert
Assignee: Will Reichert
Fix For: 4.17.18
JBTM-2105 reduced GC overhead of TxStats.enabled by saving the CoordinatorEnvironmentBean reference to a local variable
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (JBTM-2098) Deadlock in ThreadActionTest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2098?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2098:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/608
> Deadlock in ThreadActionTest
> ----------------------------
>
> Key: JBTM-2098
> URL: https://issues.jboss.org/browse/JBTM-2098
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Testing, Transaction Core
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 5.0.2
>
>
> {code}
> Found one Java-level deadlock:
> =============================
> "Thread-3":
> waiting to lock monitor 0x0000000019599b88 (object 0x000000009e484cb0, a com.arjuna.ats.arjuna.AtomicAction),
> which is held by "Thread-2"
> "Thread-2":
> waiting for ownable synchronizer 0x000000009debea20, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "Thread-3"
> Java stack information for the threads listed above:
> ===================================================
> "Thread-3":
> at com.arjuna.ats.arjuna.coordinator.BasicAction.add(BasicAction.java:297)
> - waiting to lock <0x000000009e484cb0> (a com.arjuna.ats.arjuna.AtomicAction)
> at com.arjuna.ats.arjuna.StateManager.modified(StateManager.java:896)
> - locked <0x000000009debe740> (a com.hp.mwtests.ts.txoj.common.resources.AtomicObject)
> at com.arjuna.ats.txoj.LockManager.setlock(LockManager.java:487)
> - locked <0x000000009e05fba8> (a java.lang.Object)
> at com.arjuna.ats.txoj.LockManager.setlock(LockManager.java:329)
> at com.hp.mwtests.ts.txoj.common.resources.AtomicObject.incr(AtomicObject.java:139)
> at com.hp.mwtests.ts.txoj.common.resources.BasicThreadedObject.run(BasicThreadedObject.java:79)
> "Thread-2":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000009debea20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at com.arjuna.ats.arjuna.StateManager.lockMutex(StateManager.java:1317)
> at com.arjuna.ats.txoj.LockManager.doRelease(LockManager.java:756)
> at com.arjuna.ats.txoj.LockManager.releaseAll(LockManager.java:288)
> at com.arjuna.ats.internal.txoj.abstractrecords.LockRecord.nestedAbort(LockRecord.java:106)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2941)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2918)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1632)
> - locked <0x000000009e484cb0> (a com.arjuna.ats.arjuna.AtomicAction)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.checkChildren(BasicAction.java:3354)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1460)
> - locked <0x000000009e4039c8> (a com.arjuna.ats.arjuna.AtomicAction)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:147)
> at com.hp.mwtests.ts.txoj.common.resources.BasicThreadedObject.run(BasicThreadedObject.java:90)
> Found 1 deadlock.
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (JBTM-2113) [JDK ORB] Incorrect datasources configuration in standalone-cmr.xml
by Gytis Trikleris (JIRA)
Gytis Trikleris created JBTM-2113:
-------------------------------------
Summary: [JDK ORB] Incorrect datasources configuration in standalone-cmr.xml
Key: JBTM-2113
URL: https://issues.jboss.org/browse/JBTM-2113
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JTS, Testing
Reporter: Gytis Trikleris
Assignee: Michael Musgrove
Priority: Minor
Fix For: 5.0.2
http://172.17.131.2/view/Narayana+BlackTie/job/narayana-SUN_ORB/34/
{code}
[0m[31m08:57:12,067 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[140,9]
Message: Unexpected element '{urn:jboss:domain:datasources:3.0}subsystem'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:458) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT]
... 3 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month