[JBoss JIRA] (JBTM-1644) Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1644?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1644:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Documentation has been added to the failure recovery guide.
The previous comment indicated how to test the behavior by modifying an existing quickstart. However, it may still be useful to have a dedicated quickstart which explains what is happening "under the covers" as the various stages of recovery progress. If there is call for such a quickstart then the JIRA should be re-opened.
> Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1644
> URL: https://issues.jboss.org/browse/JBTM-1644
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Demonstrator, Documentation
> Reporter: Tom Jenkinson
> Assignee: Michael Musgrove
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: use-postgresql.patch
>
>
> Please can you document any restrictions (stating none if there are none). How to configure the recovery manager (e.g. specific node id, not *). Considerations a user should have (not to connect more than one recovery manager to the same store at once, suggestions for how to restrict that - maybe object store specific?)
> Object store specific information, e.g. if you are using filesystem/hornetq/jdbc do any of them ensure that only one process is accessing at the same time?
> A simple quickstart demonstrating how to use (maybe JDBC object store inside AS7 would be most appropriate) would be useful.
> Does IP address play a role, are there any other restrictions?
--
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, 11 months
[JBoss JIRA] (JBTM-1644) Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1644?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1644:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/documentation/pull/12
> Thoroughly document how to recover a local JTA object store from a different node (perhaps with quickstart?)
> ------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-1644
> URL: https://issues.jboss.org/browse/JBTM-1644
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Demonstrator, Documentation
> Reporter: Tom Jenkinson
> Assignee: Michael Musgrove
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Attachments: use-postgresql.patch
>
>
> Please can you document any restrictions (stating none if there are none). How to configure the recovery manager (e.g. specific node id, not *). Considerations a user should have (not to connect more than one recovery manager to the same store at once, suggestions for how to restrict that - maybe object store specific?)
> Object store specific information, e.g. if you are using filesystem/hornetq/jdbc do any of them ensure that only one process is accessing at the same time?
> A simple quickstart demonstrating how to use (maybe JDBC object store inside AS7 would be most appropriate) would be useful.
> Does IP address play a role, are there any other restrictions?
--
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, 11 months
[JBoss JIRA] (JBTM-1563) Transaction recovery failed
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1563?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1563:
-------------------------------------
Sure, the way this situation has arisen is that a build fails on CI, rather than the assignee having to understand the cause of the failure we allow them to link to the log of a failed build and make an attempt at a subject and component and if possible assignee. The reporter also marks the build as "keep forever". It is then the assignees responsibility to review the log (while still marked as "keep forever") then to update the subject and description to describe the actual problem. The assignee then resolves the issue, and finally removes the old build from CI.
What has happened here is the job was renamed, so the link didn't work. I have revised the link to point to the correct job name.
I will revise the link, and then we have the failed build that Amos is assigned to look into (that has been marked as "keep forever") but he hasn't looked into the cause of it yet.
> Transaction recovery failed
> ---------------------------
>
> Key: JBTM-1563
> URL: https://issues.jboss.org/browse/JBTM-1563
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie, Testing
> Affects Versions: 5.0.0.M1
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/blacktie-linux64/1423/console
--
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, 11 months
[JBoss JIRA] (JBTM-1689) "jta" vs. "jts" profile seems duplicate
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1689?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1689:
-----------------------------------
I'm fine with it.
> "jta" vs. "jts" profile seems duplicate
> ---------------------------------------
>
> Key: JBTM-1689
> URL: https://issues.jboss.org/browse/JBTM-1689
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 4.17.4
> Reporter: Weinan Li
> Assignee: Tom Jenkinson
> Priority: Minor
>
> "jta" vs. "jts" profile, they seem to build the same modules except for ArjunaJTS.
> As maven has some built in options for selecting which modules/directories to build, would it be better to just use those options? Instead of defining profiles, it might look something like "mvn install -pl common,ArjunaCore" instead of the build profile "mvn install -Pcore"
--
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, 11 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-1712:
-----------------------------------
Assignee: Mark Little (was: Tom Jenkinson)
Always happy to assign to willing volunteers :)
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4
> Reporter: Jonathan Halliday
> Assignee: Mark Little
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
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, 11 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1712:
-----------------------------------
Agreed.
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4
> Reporter: Jonathan Halliday
> Assignee: Tom Jenkinson
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
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, 11 months