[JBoss JIRA] (JBTM-1598) version tags missed for all the sub-components
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1598?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1598:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> version tags missed for all the sub-components
> ----------------------------------------------
>
> Key: JBTM-1598
> URL: https://issues.jboss.org/browse/JBTM-1598
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Weinan Li
> Assignee: Gytis Trikleris
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
> Original Estimate: 1 hour
> Time Spent: 1 day, 2 hours, 50 minutes
> Remaining Estimate: 0 minutes
>
> Hi Tom, the problem I've found is that all the dependencies of its own components are lack of version section. For example:
> {code}
> <dependencies>
> <dependency>
> <groupId>org.jboss.jbossts</groupId>
> <artifactId>common</artifactId>
> </dependency>
> </dependencies>
> {code}
> Should be:
> {code}
> <dependencies>
> <dependency>
> <groupId>org.jboss.jbossts</groupId>
> <artifactId>common</artifactId>
> <version>${project.version}</version>
> </dependency>
> </dependencies>
> {code}
> Could you please help to add these tags? Thanks!
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1472) Initial work on JTA for Compensations
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1472?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1472:
--------------------------------
Remaining Estimate: 2 weeks, 1 day, 4 hours (was: 1 week, 1 day, 4 hours)
> Initial work on JTA for Compensations
> -------------------------------------
>
> Key: JBTM-1472
> URL: https://issues.jboss.org/browse/JBTM-1472
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M3
>
> Original Estimate: 2 weeks
> Time Spent: 3 days, 4 hours
> Remaining Estimate: 2 weeks, 1 day, 4 hours
>
> We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
> It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
> This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
> Tasks:
> # Investigate existing WS-BA APIs
> ## Try code examples if possible
> # Produce an initial list of features that should be covered by the API
> # Create a simple implementation backed by WS-BA.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1634) TX tests failed with "Unable to start a new txn on URI"
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1634?page=com.atlassian.jira.plugin.... ]
Amos Feng updated JBTM-1634:
----------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/blacktie/pull/39
> TX tests failed with "Unable to start a new txn on URI"
> -------------------------------------------------------
>
> Key: JBTM-1634
> URL: https://issues.jboss.org/browse/JBTM-1634
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
>
> http://172.17.131.2/job/blacktie-windows2008-taconic/246/
> http://172.17.131.2/job/blacktie-linux32/915/
> http://172.17.131.2/job/blacktie-linux64/1472/
> {code}
> 2013-04-16 06:12:25,324 [0x57fb3f0] DEBUG (HttpClient :114 ) - connected to TM on localhost:8080 URI=http://localhost:8080/rest-tx/tx/transaction-manager
> 2013-04-16 06:12:25,484 [0x57fb3f0] DEBUG (HttpClient :74 ) - connect to localhost:8080 ok
> 2013-04-16 06:12:25,491 [0x57fb3f0] DEBUG (HttpClient :99 ) - POST http://localhost:8080/rest-tx/tx/transaction-manager HTTP/1.1
> 2013-04-16 06:12:25,495 [0x57fb3f0] DEBUG (HttpClient :99 ) - Host: localhost
> 2013-04-16 06:12:25,498 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Length: 13
> 2013-04-16 06:12:25,500 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Type: application/x-www-form-urlencoded
> 2013-04-16 06:12:25,505 [0x57fb3f0] DEBUG (HttpClient :148 ) - timeout=-1000
> 2013-04-16 06:12:25,508 [0x57fb3f0] DEBUG (HttpClient :158 ) - buf size is 4096
> 2013-04-16 06:12:27,023 [0x57fb3f0] DEBUG (HttpClient :162 ) - receive 241 bytes
> 2013-04-16 06:12:27,028 [0x57fb3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 404 Not Found
> Content-Length: 145
> Connection: keep-alive
> Content-Type: text/html
> Could not find resource for relative : /rest-tx/tx/transaction-manager of full path: http://localhosthttp/rest-tx/rest-tx/tx/transaction-manager?
> 2013-04-16 06:12:27,049 [0x57fb3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 404 Not Found
> {code}
> It looks like restat-web.war has not regiter as /rest-tx
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1634) TX tests failed with "Unable to start a new txn on URI"
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1634?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-1634:
---------------------------------
It looks like the undertow does not accept
{noformat}
POST http://localhost:8080/rest-tx/tx/transaction-manager HTTP/1.1
Host: localhost
{noformat}
I change it to
{noformat}
POST /rest-tx/tx/transaction-manager HTTP/1.1
Host: localhost:8080
{noformat}
and this works fine now.
> TX tests failed with "Unable to start a new txn on URI"
> -------------------------------------------------------
>
> Key: JBTM-1634
> URL: https://issues.jboss.org/browse/JBTM-1634
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
>
> http://172.17.131.2/job/blacktie-windows2008-taconic/246/
> http://172.17.131.2/job/blacktie-linux32/915/
> http://172.17.131.2/job/blacktie-linux64/1472/
> {code}
> 2013-04-16 06:12:25,324 [0x57fb3f0] DEBUG (HttpClient :114 ) - connected to TM on localhost:8080 URI=http://localhost:8080/rest-tx/tx/transaction-manager
> 2013-04-16 06:12:25,484 [0x57fb3f0] DEBUG (HttpClient :74 ) - connect to localhost:8080 ok
> 2013-04-16 06:12:25,491 [0x57fb3f0] DEBUG (HttpClient :99 ) - POST http://localhost:8080/rest-tx/tx/transaction-manager HTTP/1.1
> 2013-04-16 06:12:25,495 [0x57fb3f0] DEBUG (HttpClient :99 ) - Host: localhost
> 2013-04-16 06:12:25,498 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Length: 13
> 2013-04-16 06:12:25,500 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Type: application/x-www-form-urlencoded
> 2013-04-16 06:12:25,505 [0x57fb3f0] DEBUG (HttpClient :148 ) - timeout=-1000
> 2013-04-16 06:12:25,508 [0x57fb3f0] DEBUG (HttpClient :158 ) - buf size is 4096
> 2013-04-16 06:12:27,023 [0x57fb3f0] DEBUG (HttpClient :162 ) - receive 241 bytes
> 2013-04-16 06:12:27,028 [0x57fb3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 404 Not Found
> Content-Length: 145
> Connection: keep-alive
> Content-Type: text/html
> Could not find resource for relative : /rest-tx/tx/transaction-manager of full path: http://localhosthttp/rest-tx/rest-tx/tx/transaction-manager?
> 2013-04-16 06:12:27,049 [0x57fb3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 404 Not Found
> {code}
> It looks like restat-web.war has not regiter as /rest-tx
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1522:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> "no XTS application recovery module found" during XTS Recovery Tests
> --------------------------------------------------------------------
>
> Key: JBTM-1522
> URL: https://issues.jboss.org/browse/JBTM-1522
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 4.17.4, 5.0.0.M3
>
> Attachments: 2013-04-01_jbtm-1522_outputs.zip, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit-output.txt, com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output-2.txt, com.arjuna.qa.junit.TestBACrashDuringCommit-output.txt, com.arjuna.qa.junit.TestBACrashDuringCommit.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit-output.txt, com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit.txt
>
>
> See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/...
> Notice the following log is displayed repeatedly until the test gives up waiting for recovery:
> {code}
> WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0
> {code}
> This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular:
> {code}
> if (!found) {
> // we failed to find a helper to convert a participant record so log a warning
> // but leave it in the table for next time
> RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId());
> }
> {code}
> It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry?
> This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan...
> h4.Cunning Plan
> We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take:
> # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it.
> # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above.
> # Configure the job to run @hourly until it fails with this problem.
> # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build.
> # Boot the AS and confirm that the issue is reproduced.
> # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue.
> # Attach a debugger to find out what the problem is.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1639:
-----------------------------------
Summary: Improve XTS Api for looking up Recovery Manager to prevent developer from poling
Key: JBTM-1639
URL: https://issues.jboss.org/browse/JBTM-1639
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.Final
Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup.
This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null.
Two possible solutions:
Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome.
Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted.
To Reproduce
Put breakpoints on:
Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads
XTSATRecoveryManager.setRecoveryManager() // stop on Thread only
Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM.
Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1634) TX tests failed with "Unable to start a new txn on URI"
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1634?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-1634:
---------------------------------
see http://172.17.131.2/job/blacktie-linux32/915/artifact/tx/target/cpp-test-...
and the content
{noformat}
Could not find resource for relative : /rest-tx/tx/transaction-manager of full path: http://localhosthttp/rest-tx/rest-tx/tx/transaction-manager?
{noformat}
looks like the response from the server.
> TX tests failed with "Unable to start a new txn on URI"
> -------------------------------------------------------
>
> Key: JBTM-1634
> URL: https://issues.jboss.org/browse/JBTM-1634
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 5.0.0.M3
>
>
> http://172.17.131.2/job/blacktie-windows2008-taconic/246/
> http://172.17.131.2/job/blacktie-linux32/915/
> http://172.17.131.2/job/blacktie-linux64/1472/
> {code}
> 2013-04-16 06:12:25,324 [0x57fb3f0] DEBUG (HttpClient :114 ) - connected to TM on localhost:8080 URI=http://localhost:8080/rest-tx/tx/transaction-manager
> 2013-04-16 06:12:25,484 [0x57fb3f0] DEBUG (HttpClient :74 ) - connect to localhost:8080 ok
> 2013-04-16 06:12:25,491 [0x57fb3f0] DEBUG (HttpClient :99 ) - POST http://localhost:8080/rest-tx/tx/transaction-manager HTTP/1.1
> 2013-04-16 06:12:25,495 [0x57fb3f0] DEBUG (HttpClient :99 ) - Host: localhost
> 2013-04-16 06:12:25,498 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Length: 13
> 2013-04-16 06:12:25,500 [0x57fb3f0] DEBUG (HttpClient :99 ) - Content-Type: application/x-www-form-urlencoded
> 2013-04-16 06:12:25,505 [0x57fb3f0] DEBUG (HttpClient :148 ) - timeout=-1000
> 2013-04-16 06:12:25,508 [0x57fb3f0] DEBUG (HttpClient :158 ) - buf size is 4096
> 2013-04-16 06:12:27,023 [0x57fb3f0] DEBUG (HttpClient :162 ) - receive 241 bytes
> 2013-04-16 06:12:27,028 [0x57fb3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 404 Not Found
> Content-Length: 145
> Connection: keep-alive
> Content-Type: text/html
> Could not find resource for relative : /rest-tx/tx/transaction-manager of full path: http://localhosthttp/rest-tx/rest-tx/tx/transaction-manager?
> 2013-04-16 06:12:27,049 [0x57fb3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 404 Not Found
> {code}
> It looks like restat-web.war has not regiter as /rest-tx
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1479) Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1479?focusedWorklogId=12429100&page=... ]
Gytis Trikleris logged work on JBTM-1479:
-----------------------------------------
Author: Gytis Trikleris
Created on: 17/Apr/13 2:47 PM
Start Date: 17/Apr/13 2:47 PM
Worklog Time Spent: 6 hours
Issue Time Tracking
-------------------
Remaining Estimate: 1 day, 2 hours (was: 2 days)
Time Spent: 1 week, 4 hours, 30 minutes (was: 4 days, 6 hours, 30 minutes)
Worklog Id: (was: 12429100)
> Create a quickstart to show how to use IronJacamar and JBTM inside tomcat
> -------------------------------------------------------------------------
>
> Key: JBTM-1479
> URL: https://issues.jboss.org/browse/JBTM-1479
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Demonstrator
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M3
>
> Attachments: test-ds.xml, transaction.xml
>
> Original Estimate: 3 days
> Time Spent: 1 week, 4 hours, 30 minutes
> Remaining Estimate: 1 day, 2 hours
>
> See JBTM-809 for the algorithm
> You might want to put the startup in the context listener:
> public class MyServletContextListener implements ServletContextListener {
> public void contextInitialized(ServletContextEvent sce) {
> // Initialize RecoveryManager
> // Initialize TransactionManager
> // Initialize IronJacamar
> }
>
> @Override
> public void contextDestroyed(ServletContextEvent sce) {
> // Clean IronJacamar
> // Clean TransactionManager
> // Clean RecoveryManager
> }
> }
> Quickstart application should connect to the database (say PostgreSQL), dummy XA resource and coordinate the transaction. The PostgreSQL data source needs to be accessed via IronJacamar.
--
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
11 years, 5 months