[JBoss JIRA] (JBTM-2358) Benchmark the different Object Store Implementations
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2358?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2358:
-------------------------------------
We should try to get the best JDBC results we can so should try to use a database that is either on the same machine ideally. Does haverstraw host a postgres?
> Benchmark the different Object Store Implementations
> ----------------------------------------------------
>
> Key: JBTM-2358
> URL: https://issues.jboss.org/browse/JBTM-2358
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Performance Testing
> Affects Versions: 5.0.4
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.5
>
>
> Include object store performance testing in the benchmark suite:
> - Volatile
> - File
> - HornetQ store
> - JDBC
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (JBTM-2358) Benchmark the different Object Store Implementations
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2358:
--------------------------------------
Summary: Benchmark the different Object Store Implementations
Key: JBTM-2358
URL: https://issues.jboss.org/browse/JBTM-2358
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: Performance Testing
Affects Versions: 5.0.4
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.0.5
Include object store performance testing in the benchmark suite:
- Volatile
- File
- HornetQ store
- JDBC
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (JBTM-2356) REST-AT recovery failure
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-2356?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-2356:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> REST-AT recovery failure
> ------------------------
>
> Key: JBTM-2356
> URL: https://issues.jboss.org/browse/JBTM-2356
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: REST
> Affects Versions: 5.0.4
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 5.0.5
>
>
> See linked forum post:
> Start two serves A and B with the coordinator running on A and a participant on server B. Crash server B just before commit. When server B comes back up the coordinator fails to recover the transaction and returns 404 when asked about the transaction.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2357:
-------------------------------------
Excellent - thanks for confirming :)
> jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
> -------------------------------------------------------------------------------
>
> Key: JBTM-2357
> URL: https://issues.jboss.org/browse/JBTM-2357
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Affects Versions: 5.0.3
> Reporter: Toby Crawley
> Assignee: Tom Jenkinson
>
> If the property isn't set, ConfigurationInfo falls back to looking for "arjuna-properties.xml" because of https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna.... Is that default intentional, or should it have been set to "jbossts-properties.xml" as part of JBTM-482?
> We're running in to this with [Immutant|http://immutant.org], where the user can run their application as a set of jars or as an uberjar. When ran as a set of jars, the manifest from narayana-jta.jar has arjuna-properties-file set, and the jar provides a jbossts-properties.xml at the top level that gets loaded. But when the user creates an uberjar (a process we don't control), the uberjar includes the jbossts-properties.xml file from the jta jar, but does not include the arjuna-properties-file property in the manifest, which causes narayana to fail because the node id isn't set. We'd prefer the same behavior in either run mode, so currently provide an arjuna-properties.xml that is identical to the default from the jta jar to work around the issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Toby Crawley (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Toby Crawley commented on JBTM-2357:
------------------------------------
Thanks for looking in to this Tom. It looks like the system property will work for us.
> jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
> -------------------------------------------------------------------------------
>
> Key: JBTM-2357
> URL: https://issues.jboss.org/browse/JBTM-2357
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Affects Versions: 5.0.3
> Reporter: Toby Crawley
> Assignee: Tom Jenkinson
>
> If the property isn't set, ConfigurationInfo falls back to looking for "arjuna-properties.xml" because of https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna.... Is that default intentional, or should it have been set to "jbossts-properties.xml" as part of JBTM-482?
> We're running in to this with [Immutant|http://immutant.org], where the user can run their application as a set of jars or as an uberjar. When ran as a set of jars, the manifest from narayana-jta.jar has arjuna-properties-file set, and the jar provides a jbossts-properties.xml at the top level that gets loaded. But when the user creates an uberjar (a process we don't control), the uberjar includes the jbossts-properties.xml file from the jta jar, but does not include the arjuna-properties-file property in the manifest, which causes narayana to fail because the node id isn't set. We'd prefer the same behavior in either run mode, so currently provide an arjuna-properties.xml that is identical to the default from the jta jar to work around the issue.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 10 months