[JBoss Tools Development] - How To Build JBoss Tools 4.1 FAQ
by Nick Boldt
Nick Boldt [https://community.jboss.org/people/nickboldt] modified the document:
"How To Build JBoss Tools 4.1 FAQ"
To view the document, visit: https://community.jboss.org/docs/DOC-48358
--------------------------------------------------------------
>
https://community.jboss.org/4.5.6/images/tiny_mce3/plugins/jiveemoticons/... https://community.jboss.org/4.5.6/images/tiny_mce3/plugins/jiveemoticons/...
*Frequently Asked Questions: How Do I Build JBoss Tools 4.1?*
*
*
*+How do I configure my settings.xml?+*
* Follow https://community.jboss.org/docs/DOC-15170 these instructions to add reference to JBoss Repositories into your settings.xml. You'll also probably need access to the SNAPSHOT repository. So here is what you should see in your ~/.m2/settings.xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
....
<profiles>
....
<profile>
<id>jboss-default</id>
<repositories>
<!-- To resolve parent artifact -->
<repository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
<repository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</repository>
</repositories>
<pluginRepositories>
<!-- To resolve parent artifact -->
<pluginRepository>
<id>jboss-public-repository-group</id>
<name>JBoss Public Repository Group</name>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</pluginRepository>
<pluginRepository>
<id>jboss-snapshots-repository</id>
<name>JBoss Snapshots Repository</name>
<url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>jboss-default</activeProfile>
...
</activeProfiles>
</settings>
+*My build is failing due to OutOfMemory or PermGen issues! How do I give Maven more memory?*+
+*
*+
* To configure the amount of memory used by Maven, you can define MVN_OPTS as follows, either in the mvn / mvn.bat script you use to run Maven, or set as global environment variables. Here's how to do so for http://forums.fedoraforum.org/showthread.php?t=262465 Fedora, https://help.ubuntu.com/community/EnvironmentVariables Ubuntu, http://forums.techarena.in/windows-xp-support/1152405.htm Windows, http://www.digitaledgesw.com/node/31 OSX.
set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m
+*How do I build via commandline?*+
1. Fetch code from github
2. Run maven
3. Repeat for other projects
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
cd ~/jbosstools/jbosstools-base
mvn verify
+*How do I build in Eclipse (with m2e)?*+
* With m2e installed, you can either do *CTRL-SHIFT-X,M (Run Maven Build),* or right-click the project and select *Run As > Maven Build*. See https://community.jboss.org/docs/DOC-47936#Building_Locally_In_Eclipse How To Build JBoss Tools 4 - Building Locally In Eclipse
+*How do I build a single project?*+
* Generally, you need only fetch the sources, and run `mvn verify`. See 'How do I build via commandline?' or 'How do I build in Eclipse (with m2e)?' above.
+*
*+
+*How do I build a series of projects (eg., Base, Server, Webservices) ?*+
* Assuming your goal is to change sources in *multiple* projects, then build them all to verify everything still compiles, you will need to fetch sources, then build the projects in dependency order.
* This workflow is useful when you're looking to change framework code in an upstream project like Base on which Webservices or Server depends, and verify that API changes don't break the downstream project's code.
* Rather than using `mvn verify`, you must use `*mvn install*` so that the downstream build will use YOUR locally-built content in your ~/.m2, rather than looking to the internet for the last published upstream dependencies.
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-base
git clone https://github.com/jbosstools/jbosstools-server
git clone https://github.com/jbosstools/jbosstools-webservices
cd ~/jbosstools/jbosstools-base; mvn install
cd ~/jbosstools/jbosstools-server; mvn install
cd ~/jbosstools/jbosstools-webservices; mvn verify
+*Which is better - `mvn clean install` or `mvn verify` ?*+
* Use `*install*` to create artifacts in your ~/.m2 folder which will be checked when building anything which depends on those artifacts (in addition to checking the internet). Also useful for doing subsequent offline builds with the `*-o*` or `*--offline*` flag.
* Use `*verify*` to build, but NOT install anything into your ~/.m2 folder.
+*How do I clean out artifacts I might have installed to my ~/.m2/repo ?*+
+*What if I've already built something locally, but I want to build against the server version instead of my local repo?*+
* There are http://wiki.eclipse.org/Tycho/Target_Platform#Locally_built_artifacts two approaches that work here:
0.1. override temporarily when building, using *-Dtycho.localArtifacts=ignore*, or
0.2. delete *~/.m2/repository/.meta/p2-local-metadata.properties*
+*How do I build a target platform?*+
* Currently, you should not need to build a target platform locally if you're building w/ maven via commandline. But if you'd like to materialize a target platform for use in Eclipse, you can do so like this:
1. Fetch target platforms project from github
2. Switch to the correct branch
3. Run maven
4. Results will be in jbosstools/multiple/target/jbosstools-multiple.target.repo/ or jbdevstudio/multiple/target/jbdevstudio-multiple.target.repo/
cd ~/jbosstools
git clone https://github.com/jbosstools/jbosstools-target-platforms
cd ~/jbosstools/jbosstools-target-platforms
git checkout 4.30.x
mvn install
cd ~/jbosstools/jbosstools-target-platforms/jbosstools/multiple/target/jbosstools-multiple.target.repo/
+*How do I ignore MD5sum checks when resolving dependencies or building?*+
* If for some reason the site against which you're buidling has invalid metadata (perhaps because the site's IUs were pack200'd AFTER the artifacts.xml / content.xml metadata was created) you may get errors like "MD5 hash is not as expected". To ignore these errors, simply build like this:
mvn install -Declipse.p2.MD5ArtifactCheck=false -Declipse.p2.MD5Check=false
+*
*+
+*Why is there more than one target platform?*+
* Every time we make changes to the target platform, either to add/remove something, or to change the included version, we release a new version.
* In order to verify we can build against the oldest version of a target platform (eg., one based on Eclipse 4.2.0, or "minimum" target platform) but also run tests against the latest for that stream (eg., based on Eclipse 4.2.2, or "maximum" target platform), we need to maintain multiple versions.
* By default, your build will use the default "minimum" target platform specified in the JBoss Tools parent pom. To easily build against the default "maximum", use *-Pmaximum*. See also 'What profiles do I need to build? What Maven properties are useful when building?'
+*How do I specify which target platform to use when building?*+
+*
*+
* See 'What profiles do I need to build? What Maven properties are useful when building?'
+*How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?
*+
+*
*+
* To skip running tests, you can use these Maven flags:* *-Dmaven.test.skip=true*
* *-DskipTests*
* If your reason for skipping tests is to see if everything can run without being stuck on the first test failure, you might also like these flags:* *-fae*, *--fail-at-end* : Fail at end of build only
* *-fn*, *--fail-never* : Never fail the build regardless of result
* You can also cause test failures to result in JUnit output without failing the build using these flags:* *-Dmaven.test.error.ignore=true*
* *-Dmaven.test.failure.ignore=true*
+*How can I debug tests in Eclipse when run from Tycho (with Surefire)?*+
+*
*+
* See http://www.jboss.org/tools/docs/testing.html http://www.jboss.org/tools/docs/testing.html
+*How do I build docs?*+
+*
*+
* See https://community.jboss.org/docs/DOC-13341 Building JBoss Tools Documentation.
+*What profiles do I need to build? What Maven properties are useful when building?
*+
* Most of the time, you don't need any profiles or -D properties. Here are some profiles and properties you might want to use in special cases.
** *-Pmaximum* : selects the default maximum target platform version instead of the default minimum one. Useful when running tests to verify that your code works against a newer target platform (eg., Eclipse 4.2.2 instead of 4.2.0)
** *-DTARGET_PLATFORM_VERSION* : allows you to pick a specific target platform version from those available in Nexus.
* See also 'How to I skip running tests? How do I make tests not fail? Or only fail after ALL tests run?' above for test-related properties.
+*How do I see what's happening on a remote slave running Xvfb?
*+
* Look in the build log for 2 lines like these - you need to determine the slave name, screen number (probably 0), and framebuffer directory (a path ending in +xvfb+):* Building remotely on ${SLAVE_NAME} in workspace /mnt/hudson/workspace/${JOB_NAME}
* Xvfb starting$ Xvfb :1 -screen ${SCREEN_NUM} 1024x768x24 -fbdir ${FBDIR}
* Get the +Xvfb_screen0+ file from the remote server. If necessary, you might have to use the server's http://en.wikipedia.org/wiki/Fully_qualified_domain_name FQDN instead of the slave name that appears in the log:* rsync -Pzrlt --rsh=ssh --protocol=28 ${USER}@${SLAVE_NAME}:${FBDIR}/Xvfb_screen${SCREEN_NUM} /tmp/
* View the screen w/ xwud:* xwud /tmp/Xvfb_screen${SCREEN_NUM}
+*
*++*Anything else?*+
* See also this FAQ: https://community.jboss.org/docs/DOC-10796 https://community.jboss.org/wiki/JBossToolsFAQ
+*
*+
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48358]
Create a new document in JBoss Tools Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years
Re: [jboss-dev-forums] [JBoss Transactions Development] - TransactionMonitoringAndVisualization
by Mark Little
Mark Little [https://community.jboss.org/people/marklittle] commented on the document
"TransactionMonitoringAndVisualization"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48255#comment-12047
--------------------------------------------------
"Update Narayana to dump a lot of data when the transaction fails. Same as the Byteman approach, but will be useful for more users."
Yes, but what about the performance impact on the rest of the system and users when this happens? Furthermore, define "fails" because if the application has told the transaction to rollback then the information needed is different to if the reaper forces it to rollback, for instance. Plus, maintaining data for all transactions throughout their life just so that it can be dumped out in the small case that the transaction rolls back seems of dubious benefit to the 99.99% of users who don't have failing transactions.
--------------------------------------------------
11 years
Re: [jboss-dev-forums] [JBoss Transactions Development] - TransactionMonitoringAndVisualization
by Tom Jenkinson
Tom Jenkinson [https://community.jboss.org/people/tomjenkinson] commented on the document
"TransactionMonitoringAndVisualization"
To view all comments on this document, visit: https://community.jboss.org/docs/DOC-48255#comment-12041
--------------------------------------------------
RE: Data Model
To capture some extra information we discussed, it will be useful to maintain a separate table of participants that each participant record links to. We discussed the naming of the "ParticipantRecord" entity, initially we discounted "Branch" as this was determined as possibly too XA specific (tbd). To extend on this, there would be expected to be few "ResourceManager" rows, but many "ParticipantRecord" rows.
We also discussed that we should maintain timestamps for everything, for example when the Transaction is created, prepared, suspended. This also implies we would probably want to keep a list of the state changes that the transaction has gone through rather than a single status field. I am not so sure about this, do we want to be able to replay the transaction state changes or give a view of the current transaction state (tbd). Also, the ParticipantRecord is only maintaining the "vote" field. It is possible that the record can be suspended/resumed, so I think maybe that needs a status field instead of vote field (perhaps a list if we are supporting replay).
You are going to need to consider what a subordinate coordinator (JTS) is in the data model. In JTS it sits behind a participant style interface functionally but in this model I don't think you would want to record it as such. You can either use the Transaction table (add a nullable list of subordinate transactions and a nullable parent) or create a new table for it. Most properties would remain the same so tbd what the best course of action is. Related to this, we discussed how it would be possible when different nodes are processing their logs in parallel and submitting to the database, it would be possible that the subordinate coordinator was added before the parent so we need to consider how that would work. When a parent is added it will know the subordinates so you will know when you have the full picture.
--------------------------------------------------
11 years
[JBoss Transactions Development] - TransactionMonitoringAndVisualization
by Alex Creasy
Alex Creasy [https://community.jboss.org/people/arcreasy] modified the document:
"TransactionMonitoringAndVisualization"
To view the document, visit: https://community.jboss.org/docs/DOC-48255
--------------------------------------------------------------
h1. Transaction Monitoring and Visualization
h3. Overview of the Tool
The purpose of this project is to create a tool for monitoring the status of in-flight and complete transactions. The main aims of the tool are to help debug transaction related issues and also to provide insight into the running of the system. Essentially, the tool monitors a running system (or a log from a running system) and produces a detailed list of all transactions. A user may then select a particular transaction to see in more detail, including the participants involved in the transaction, the outcome of the transaction and the participants that influenced the outcome. The tool could be visual, showing a diagrammatic view of a transaction or may be command line based, producing a textual output (or maybe both).
h3. What Problems does this solve?
* Transaction Timeout detection. We frequently get support requests (via the forums or elsewhere) from users who are experiencing intermittent rollbacks of transactions due to timeout. It is not a simple matter for the user to figure out that this is what's happening.
* Transaction Profiling. It may be relatively easy to detect transactions that are taking longer than desired to complete. However, diagnosing which party in the transaction is to blame is non-trivial.
* Loops and Diamonds detection. In a distributed transaction it is possible to introduce a loop or a diamond without realizing. JTS may tolerate this, but distributed JTA and bridged WS-AT to JTA does not. Identifying this scenario is non-trivial and requires detailed internal knowledge of the TM.
* Reasoning about the System Architecture. Producing an architectural diagram of a distributed transaction with many participants and servers is not an easy task. Furthermore it can be error prone and could change based on the application inputs. The difficulty of this task is further compounded if multiple transaction types are involved (WS-AT, WS-BA, REST-AT, etc). This diagram is essential for reasoning about the current architecture and for considering improvements or changes. Also this diagram alone may not be enough without detailed profiling overlayed.
* Analyzing Disk Syncs. One approach to improving the performance of a transaction is to reduce the number of disk syncs. The problem is that it is often difficult to calculate exactly how many you are performing and what delay each adds.
h3. Who is the target audience?
* End users, to diagnose their own issues
* GSS, to diagnose customer issues
* Architects, to analyze their system architecture
* Those new to the field of transactions, learning what's going on.
h3. How does it solve these problems?
The tool analyses the server log and gathers data on every transaction ran. The tool could also support live updates for a server that is still running. The tool assumes that it can gather all its information from log statements. If it can't, we take the view that some logging is missing and then add it. We may also want the tool to support different log levels. For example, it may need a log level of TRACE to acquire full knowledge of the system. This may introduce too much of a performance overhead, so we may want to allow the tool to tollerate the reduced information provided by the less verbose log levels. In this case only basic information would be provided.
h6. Querying feature
The data can be queried to find out specific information. For example, show me all the transactions that rolled back. Given a rolledback transaction, the data should be available to diagnose exactly why it rolledback. Other things you may want to query by:
* *Outcome*. Committed, Rolledback, heuristic, etc
* *Type*. JTA, JTS, WS-AT, REST-AT, etc
* *Duration*. Find all fast or slow transactions
* *Inflight*. Show transactions currently inflight
* *Stuck*. Inflight transactions that have been running for longer than Xms.
* *Recovery*. All transactions that needed to be recovered.
h6. Diagnostics
The tool could also allow 'profiles' to be plugged in. A 'profile' is responsible for identifying common problems that we see users having. Hopefully these would allow issues to be identified earlier before they are passed further up the support chain. For example, we may create a 'profile' that searches over the data looking for loops or diamonds. Another could be responsible for identifying timeouts and maybe hinting at their cause. These 'profiles' would be created based on community demand.
h6. Visualization
In order to help architects reason about the system architecture, the tool could produce a visualization of a transaction of interest. A few diagrams should give you an idea of what the tooling could produce:
https://community.jboss.org/servlet/JiveServlet/showImage/102-48255-8-202... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-8...
Here we can see that a transaction was begun on Server1. It enlisted a DB and JMS queue locally and invoked a remote service on Server2. A second resource (DB2) was enlisted on Server2.
https://community.jboss.org/servlet/JiveServlet/showImage/102-48255-8-202... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-8...
In this example we can see that the transaction rolled back because DB2 voted rollback.
Other possible features:
* *Participant types*. Display if the participant is one or two phase aware for JTA/JTS. Display the completion type (Participant/Coordinator) for WS-BA.
* * Resource types*. Whether it's a database or message queue and maybe include the name and version.
* *Multiple Transaction Types*. Somehow depict the type of transaction (JTS, WS-AT, REST-AT, etc).
* *Display Bridges*. Display when a transaction is bridged from one type to another
* *In flight Transactions*. More useful for long running transactions; display the current status of each participant and update the display in real-time as the status changes.
* *Recovery Status*. Show which resources crashed and the status of those resources already committed or recovered.
h3. Reducing the amount of data
It's likely that enabling all the required TRACE logging will generate too large a log, and slow the system down. Therefore to optimize this we could do a number of things:
1. Use Byteman to do the TRACE logging anyway (despite being turned off), for just the items we require
2. Use Byteman to somehow buffer up detailed logging in memory, for all transactions. This is discarded for committed transactions and dumped to the log for failed transactions.
3. Update Narayana to dump a lot of data when the transaction fails. Same as the Byteman approach, but will be useful for more users.
We should also reduce the amount of data held for 'identical' transactions. For example, we may have 1,000's of transactions that follow the same paths, interacting with the same resources. We should simply store this data once along with aggregate data for all the associated transactions.
h3. Research
Things to look into:
* http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm... http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm... IBM seem to have an API for being notified of all completed transactions.
* https://blog.heroku.com/archives/2013/3/19/log2viz https://blog.heroku.com/archives/2013/3/19/log2viz
* http://logstash.net/ http://logstash.net/
h3. Example - log grepping
Edit the log levels in standalone.xml setting the "com.arjuna" level to TRACE and the CONSOLE logger to TRACE. You'll then see a lot of logging produced by the transaction manager. Here's some interesting messages for different scenarios:
h5. Commit
09:20:38,554 TRACE [com.arjuna.ats.arjuna] (pool-1-thread-1) BasicAction::Begin() for action-id 0:ffffac118223:61d0e901:515016c7:13
[0m09:20:38,558 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@47b24153 )
[0m09:20:38,563 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@1bb557c8 )
09:20:38,565 TRACE [com.arjuna.ats.arjuna] (pool-1-thread-1) BasicAction::prepare () for action-id 0:ffffac118223:61d0e901:515016c7:13
09:20:38,566 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@47b24153, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6e09388c >
09:20:38,567 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@1bb557c8, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1f5fa7c4 >
09:20:38,573 TRACE [com.arjuna.ats.arjuna] (pool-1-thread-1) BasicAction::doCommit (XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@47b24153, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6e09388c >)
09:20:38,574 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@47b24153, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6e09388c >
09:20:38,574 TRACE [com.arjuna.ats.arjuna] (pool-1-thread-1) BasicAction::doCommit (XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@1bb557c8, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1f5fa7c4 >)
09:20:38,574 TRACE [com.arjuna.ats.jta] (pool-1-thread-1) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@1bb557c8, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:61d0e901:515016c7:13, node_name=1, branch_uid=0:ffffac118223:61d0e901:515016c7:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@1f5fa7c4 >
09:20:38,575 TRACE [com.arjuna.ats.arjuna] (pool-1-thread-1) FileSystemStore.remove_committed(0:ffffac118223:61d0e901:515016c7:13, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)
h5. Client Driven Rollback
[0m10:03:41,737 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::Begin() for action-id 0:ffffac118223:-507ee916:515020eb:13
[0m10:03:41,741 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@5cbf424a )
[0m10:03:41,747 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@53adb4e5 )
[0m10:03:41,749 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::Abort() for action-id 0:ffffac118223:-507ee916:515020eb:13
[0m10:03:41,750 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@5cbf424a, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-507ee916:515020eb:13, node_name=1, branch_uid=0:ffffac118223:-507ee916:515020eb:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6c28e401 >
[0m10:03:41,751 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@53adb4e5, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-507ee916:515020eb:13, node_name=1, branch_uid=0:ffffac118223:-507ee916:515020eb:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@70913520 >
h5. Participant Driven Rollback
[0m10:15:52,446 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::Begin() for action-id 0:ffffac118223:-6fc6eada:515023cb:13
[0m10:15:52,450 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@72e0b50 )
[0m10:15:52,455 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) TransactionImple.enlistResource ( org.jboss.narayana.txvis.simple.DummyXAResource@7aa354c9 )
[0m10:15:52,458 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@72e0b50, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@50150c84 >
[0m10:15:52,459 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@7aa354c9, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@15e8d72f >
[0m [33m10:15:52,460 WARN [com.arjuna.ats.jta] (pool-2-thread-1) ARJUNA016041: prepare on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:18, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.narayana.txvis.simple.DummyXAResource@7aa354c9) failed with exception XAException.XAER_RMERR: javax.transaction.xa.XAException
[0m [33m10:15:52,467 WARN [com.arjuna.ats.arjuna] (pool-2-thread-1) ARJUNA012073: BasicAction.End() - prepare phase of action-id 0:ffffac118223:-6fc6eada:515023cb:13 failed.
[0m [33m10:15:52,467 WARN [com.arjuna.ats.arjuna] (pool-2-thread-1) ARJUNA012075: Action Aborting
[0m10:15:52,467 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::phase2Abort() for action-id 0:ffffac118223:-6fc6eada:515023cb:13
[0m10:15:52,468 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::doAbort (XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@72e0b50, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@50150c84 >)
[0m10:15:52,468 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@72e0b50, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:14, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@50150c84 >
[0m10:15:52,468 TRACE [com.arjuna.ats.arjuna] (pool-2-thread-1) BasicAction::doAbort (XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@7aa354c9, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@15e8d72f >)
[0m10:15:52,469 TRACE [com.arjuna.ats.jta] (pool-2-thread-1) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:org.jboss.narayana.txvis.simple.DummyXAResource@7aa354c9, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffac118223:-6fc6eada:515023cb:13, node_name=1, branch_uid=0:ffffac118223:-6fc6eada:515023cb:18, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@15e8d72f >
h3.
h3. Data Model
The basic data model currently used in early iterations of the tool is described in the following ER diagram
https://community.jboss.org/servlet/JiveServlet/showImage/102-48255-8-207... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-8...
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-48255]
Create a new document in JBoss Transactions Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
11 years
.png){kind=link}
.png){kind=link}
