[JBoss AS 7 Development] - Logging Id's
by Cheng Fang
Cheng Fang [https://community.jboss.org/people/cfang] modified the document:
"Logging Id's"
To view the document, visit: https://community.jboss.org/docs/DOC-16810
--------------------------------------------------------------
Logging id ranges for JBoss AS7 i18n message interfaces.
|| %1,3% *Status* ||
| C | = | Complete |
| I | = | In Progress |
| P | = | Merged, but not complete |
| W | = | Waiting Merge |
|| *Range* || *Subsystem
* || *Status
* ||
| *10100 - 10199* | *Transaction* | C |
| *10200 - 10399
* | *Clustering (https://community.jboss.org/docs/DOC-48622)**
* | C |
| *10400 - 10499* | *Connector**
* | C |
| *10500 - 10599* | *CLI (not applicable)
* | N/A |
| *10600 - 10699* | *Controller Client* | C |
| *10700 - 10799*, *18500 - 18699, 18800-18999* | *CMP* | C |
| *10800 - 10899* | *Host Controller (domain packages)* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *11100 - 11199* | *Embedded* | C |
| *11200 - 11299* | *JAXRS* | C |
| *11300 - 11399* | *JMX* | C |
| *11400 - 11499* | *JPA* | C |
| *11500 - 11599* | *Logging* | C |
| *11600 - 11699* | *Messaging* | C |
| *11700 - 11799* | *mod_cluster* | C |
| *11800 - 11899* | *Naming* | C |
| *11900 - 11999* | *OSGi* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *12100 - 12199* | *Protocol* | C |
| *12200 - 12299* | *Management Client Content* | C |
| *12300 - 12399* | *Platform MBeans* | C |
| *12400 - 12499* | *Threads* | C |
| *12500 - 12599* | *PicketLink* | I |
| *12600 - 12699* | *JSF (proposed)* |
|
| *12700 - 13100* | *IIOP Common (proposed)* |
|
| *13100 - 13199* | *JDR* | C |
| *13200 - 13299* | *AppClient* | C |
| *13300 - 13399* | **Security*
* | C |
| *13400 - 13499, 14600 - 14899* | *Controller* | C |
| available block(s) |
|
|
| *14000 - 14099* | *JAXR* | W |
| *14100 - 14599* | *Ejb3* | P |
| **13400 - 13499, 14600 - 14899** | *Controller* | C |
| *14900 - 14999* | *Deployment Repository* | C |
| *15000 - 15099* | *Deployment Scanner* | C |
| *15100 - 15199* | *Domain Management HTTP Interface* | C |
| *15200 - 15299* | *Deployment Management* | C |
| *15300 - 15399* | *Network* | C |
| *15400 - 15499* | *Mail* | C |
| *15500 - 15699* | *Web Services (AS subsystem)* | C |
| *15700 - 15999*, *18700 - 18799* | *Server* | C |
| *1**6000 - 16099* | *Weld* | C |
| *16100 - 16199* | *EE Deployment* | C |
| *16200 - 16299* | *Configadmin* | C |
| *16300 - 16499* | *Jacorb* | C |
| *10900 - 10999, 16500 - 16599* | *Host Controller (host packages)* | C |
| *12000 - 12099, 16600 - 16699* | *Process Controller* | C |
| *11000 - 11099, 16700 - 16799* | *EE* | C |
| *16800 - 16899* | *Patching (Library)* | C |
| *16900 - 16999* | *Patching (Server)* |
|
| *17000 - 17099* | *POJO* | C |
| *17100 - 17199* | *Remoting* | W |
| *17200 - 17299* | *SAR* | W |
| *17300 - 17699* | *Web/Undertow (reserved)* | I |
| *17700 - 17799* | *Security Manager* | I |
| available block(s) |
|
|
| *18000 - 18399* | *Web* | C |
| *18400 - 18499* | *Xts* | C |
| *15700 - 15999, 18700 - 18799* | *Server* | C |
| available block(s) |
|
|
| *19000-19999* | *JSR-77* | I |
| *20000-20199* | *Camel* | I |
| *20200-20299* | *JipiJapa* | I |
| *20300-20499* | *Provision* | I |
| *20500-20699* | *javax.batch integration* | I |
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-16810]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
10 years, 9 months
[JBoss AS 7 Development] - Extending AS 7
by Brian Stansberry
Brian Stansberry [https://community.jboss.org/people/brian.stansberry] modified the document:
"Extending AS 7"
To view the document, visit: https://community.jboss.org/docs/DOC-25627
--------------------------------------------------------------
Like all releases of JBoss Application Server, AS 7 provides a relatively small core set of functionality, along with APIs that can be used to extend this core functionality in order to provide the services external clients need. As in previous releases, the AS ships with extensions to its core functionality that provide capabilities like Java EE support. And, as in previous releases, it is possible for custom extensions to the AS to be integrated, either by organizations (e.g. other open source projects or ISVs) who want to distribute a modified version of the AS to others, or by organizations who directly run the AS.
The means by which AS & can be extended is significantly different than it was in previous releases. This article is intended to discuss those differences, and to elicit thoughts on best practices.
The article is focused on educating organizations who want to distribute a modified version of the AS, but hopefully the information herein will be useful to organizations who directly run the AS.
h2. How Extending AS 7 is Different from Previous Versions
The fundamental difference between AS 7 and previous versions is that in AS 7 +everything isn't a deployment+. In AS 6 and early, the core AS provided some basic functionality including a couple of basic services called +deployers+. Deployers could recognize the existence of content on the filesystem, a.k.a. "deployments", process that content and install new services into AS's core service container. Most of the services provided by the AS itself were themselves +deployments+. The web container, the EJB container, the transaction manager, the naming service, etc, all were installed as +deployments.+ Even additional deployers, beyond the basic ones that were part of the core AS, were themselves deployments. Those additional deployers could do things like parsing a web.xml, making it possible to deploy additional kinds of deployments (e.g. a war file), but they themselves were deployments.
And, of course, end user applications like Java EE ears and war, were also deployments. So, in this architecture, end user applications were logically equivalent to the web container, the EJB container -- all extended the core capabilities of the AS and all were +deployments.+
In AS 7, the basic design philosophy is that deployments are end user applications. Adding new fundamental capabilities to the application server is done by installing +extensions+. However, since deployments and extensions in the end add new capabilities to the core server, what are the differences between the two? Why would someone wishing to extend the AS choose one or the other?
h2. Extensions and Subsystems
An +extension+ is an implementation of the org.jboss.as.controller.Extension interface, packaged in a directory structure accessible to the JBoss Modules modular classloading layer used by the AS. An extension can register one or more +subsystems+ with the core AS. A subsystem is a set of functionality; e.g. the web container is a subsystem. See the https://docs.jboss.org/author/display/AS71/Extending+JBoss+AS+7 Extending JBoss AS 7 documentation for more details on how to write an extension.
Extensions are packaged as JBoss Modules modules. Typically you would place your extension's module(s) in the $JBOSS_HOME/modules directory. (You can place your modules in another location if before running standalone.sh or domain.sh you set the $JBOSS_MODULE_PATH environment variable to a value that includes both your location and the location of the $JBOSS_HOME/modules directory.)
Why would you use an extension to add functionality to the AS?
* You want to make aspects of your new functionality manageable by your end users, e.g. via the AS's CLI tool and via the standalone.xml and domain.xml configuration files. The Extension interface is the means by which the core AS is told about the management API exposed by your new functionality, and about the xml parsing and marshalling logic used to read and write its configuration. One of the main new features in AS 7 is a consistent management solution; if you want your functionality to properly integrate with these management features you need to use an extension.
* You want to be able to process deployments. AS 7 has "deployment unit processors" which are conceptually similar to "deployers" in early releases. They are invoked during deployment and undeployment of deployments and can perform processing work on the deployment. Only extensions can register deployment unit processors with the core AS.
* Patching. We will introduce a patching tool in later releases of AS 7. Extensions will have significant advantages over deployments when it comes to patching. See the section on this below.
* You wish to differentiate your extension from end user applications. End users will typically use deployments to extend the AS's functionality (e.g. deploying a WAR deployment adds new functionality). Using deployments instead of extensions for things other than end-user applications mixes end user stuff with non-end-user stuff, somewhat muddying the waters. In particular:* The actual physical binaries may be mixed. If instead of using an extension you put a deployment in standalone/deployments, now your binaries will be mixed with end user binaries. To avoid this, you either need to configure a separate deployment scanner to deploy your content from a different location, or require some sort of installation process (e.g. execution of a CLI script) to get your deployment installed. The "configure a separate deployment scanner" approach is only available for standalone servers, since deployment scanners are not supported in a managed domain.
* Your deployments will be mixed with the end user deployments in the management resource tree. For example if an admin starts the CLI and executes ls deployment they will see your deployments in the same list as their own. Same thing with the admin console.
h2. Deployments
A deployment in AS7 is binary content that is installed into the server via a mangement client (or a deployment scanner, which is really just an automated management client.) The management client either uploads the content to the server or informs it of its filesystem location, and then asks the server to install that content. The server does so by taking the deployment's bits and making them available to the various deployment unit processors (DUPs) that have been added by the server's extensions. The DUPs examine the contents of the deployments and take the necessary actions to start the necessary services for the deployment and integrate them with the needed container services.
Why would you use a deployment to add functionality to the AS?
* You're an end user installing an EE application.
* You're an end user adding new mbean services or JBoss MSC services and you are not concerned with making your new functionality manageable via the AS's CLI tool or via the standalone.xml and domain.xml configuration files. You could use an extension for your new functionality instead of a deployment, but many users will find using a deployment easier, particularly if they are porting something from a previous AS release.
* You're not an end user, but your new functionality requires complex integration with the AS's EE containers. The deployment unit processors that handle deployments take care of that integration for you.
h2. A Mixed Approach
It is possible to mix extensions and deployments. For example, if you wanted to expose aspects of your new functionality's configuration to admins via the AS's management APIs, but also need to accept end user requests via the servlet container, you could package a war inside your extension's module and then have the "add" operation handler for your subsystem deploy the war.
See https://github.com/bstansberry/wildfly/commit/197f7b64b48f4a28a7d44be4820... https://github.com/bstansberry/wildfly/commit/197f7b64b48f4a28a7d44be4820... for a prototype extension with a subsystem that deploys an ear when it is added to the server.
This approach still suffers from the drawback that your extension's war will appear alongside end-user applications in the management resource tree.
Note that most of the content of that prototype extension commit is boilerplate. The key technical bits that do the deployment/undeployment are in two classes:
* https://github.com/bstansberry/wildfly/commit/197f7b64b48f4a28a7d44be4820... The subsystem add operation handler
* https://github.com/bstansberry/wildfly/commit/197f7b64b48f4a28a7d44be4820... The subsystem remove operation handler
The rest of the commit relates to creating an extension module as well as making that module part of the standard JBoss AS build. The latter part is not relevant to extensions whose source code isn't part of the AS source tree.
h2. Implications for Patching
In a future AS 7 release we will be introducing a patching feature, with a tool that stage a patch in an AS 7 installation and then (optionally) restart the standalone server of Host Controller + servers running on that installation. The feature will include the ability to roll back patches.
This feature has implications for the decision about whether to add functionality to the AS via extensions or deployments.
Extensions are packaged as JBoss Modules modules, typically located in the $JBOSS_HOME/modules directory. It will be quite simple for the patching tool support staging/installation/rollback of modules. When the AS launches, it is provided with a "modules path", a list of filesystem locations under which modules can be found. This "modules path" is conceptually very similar to an OS $PATH environment variable. It's an ordered list of locations; when the AS needs to locate a module for the first time it iterates through that list of locations checking each for the desired module; once found the search stops.
This behavior makes it simple to apply staging/install/rollback behavior to modules by storing the patch's modules in a new directory location specific to the patch and then manipulating the "modules path" used by the AS.
The upshot of all this is functionality added to the AS via an extension will be easily patchable.
The patching tool will also be able to patch arbitrary non-module files located in the AS installation (e.g. the bin/standalone.sh script). It will do this by storing a copy of the original file in a private working area, and then replacing the file with the patched one. Rollback of the patch means restoring the original file by copying it back from the private working area.
This works fine, +unless the server is actively using the original file+. If the server is actively using the original file, the patch cannot be +staged+. As soon as the patch tool lays down the new file, it will be visible to the running server.
An example of the kind of problem this can cause is if your added functionality was packaged as a deployment located in standalone/deployments. If you create a patch file with a new version of your deployment and ask your users to use the patching tool to install it, the tool will put a new version of the file in standalone/deployments -- and the deployment scanner will see that new version and tell the patching tool to deploy it.
--------------------------------------------------------------
Comment by going to Community
[https://community.jboss.org/docs/DOC-25627]
Create a new document in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=102&c...]
10 years, 9 months
[JBoss Transactions Development] - TransactionMonitoringAndVisualization
by Paul Robinson
Paul Robinson [https://community.jboss.org/people/paul.robinson] modified the document:
"TransactionMonitoringAndVisualization"
To view the document, visit: https://community.jboss.org/docs/DOC-48255
--------------------------------------------------------------
h1. Transaction Profiling and Visualization
h3. Overview of the Tool
The purpose of this project is to create a tool for profiling 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 profiles 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 kind of problems could 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.
* Performance Profiling. Diagnosing which transactions are taking a long time to run and discovering where the time is being spent.
* 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. GSS Requirements
We are currently targetting GSS as our early adoptors for this tool. We will also make early release available to the community and work with any early adopters when they apear.
* JTA-only at the moment then JTS. XTS and REST not a requirement for the forseable future.
* Display the following information* List of transactions with outcome (success or failure)* Detailed information on a per transaction basis* List of resources* JNDI name of resource
* Indication as to the type and vendor
* Outcome of its participation in the protocol
* Event log of the activities that occured in the transaction (with timings).
* If timeout, what caused it.
* Recovery information [VERIFY]
* List of subordinate transactions (in JTS case)
* Query transactions* By outcome.
* By failure reason
* Inflight* Stuck (inflight for a long time)
* Recovered transactions [VERIFY]
* Parse existing logs submitted by customers
* Target EAP 6.1 [VERIFY]
* Web and command-line interfaces [VERIFY]
* Single-server (JTA-only) requirement higher than distributed (JTS) requirement at the momment.
* Need a non-byteman solution. However, Byteman could be used for optional features, where no other alternative is available.* Many users will be unwilling to enable Byteman in production.
* The logs must not leave the business domain [VERIFY]* Many users will not be willing to have their logs submitted to some third-party service for processing.
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.
It is unlikely that this tool be used routinely in production. I think the sensible thing to do is to gather aggregate information in such a way that has minimal impact on the running system. This is mostly covered at the moment, as Narayana can obtain, rollback, commit and in-flight transaction counters. This information is great for identifying the presence of a problem, but in many cases the user would then need to turn up the logging to establish the root cause of the problem. This is similar to how developers improve the performance of a system. Aggregate data (i.e. average throughput, average response times) is used to identify that a problem exists. The developer then attaches a profiler to identify the root cause of the performance problem.
I see this tool more as a profiling tool to be used when the aggregate data has identified an issue. In which case, the overhead of gathering this data is less of an issue, assuming it doesn't impact the system to the point where it skews the data being gathered.
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-11-20... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-1...
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-11-20... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-1...
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-11-20... https://community.jboss.org/servlet/JiveServlet/downloadImage/102-48255-1...
--------------------------------------------------------------
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...]
10 years, 10 months
[JBoss AS 7 Development] - JMS messages not delivered anymore after warnings during XA recovery
by Wilhelm Berger
Wilhelm Berger [https://community.jboss.org/people/greendale] created the discussion
"JMS messages not delivered anymore after warnings during XA recovery"
To view the discussion, visit: https://community.jboss.org/message/825738#825738
--------------------------------------------------------------
Hi all,
I have migrated an application from AS 5 to AS 7 (*jboss-as-7.1.1.Final*) in *standalone-full mode*. Everything works quite fine, but when the server is running for 1 or 2 days, I get periodic JMS exceptions:
00:06:14,173 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery
at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:275) [hornetq-jms-2.2.13.Final.jar:]
at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:77) [hornetq-jms-2.2.13.Final.jar:]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.2.Final.jar:]
Caused by: java.lang.IllegalStateException: Cannot create session factory, server locator is closed (maybe it has been garbage collected)
at org.hornetq.core.client.impl.ServerLocatorImpl.assertOpen(ServerLocatorImpl.java:1823) [hornetq-core-2.2.13.Final.jar:]
at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:699) [hornetq-core-2.2.13.Final.jar:]
at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:321) [hornetq-jms-2.2.13.Final.jar:]
at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:251) [hornetq-jms-2.2.13.Final.jar:]
... 7 more
Whenever these exceptions occur the JMS messages are not delivered anymore to the JMS consumer. Only after a server restart the messages are delivered. My queue declaration in standalone-full.xml is
<jms-destinations>
<jms-queue name="MyQueue">
<entry name="queue/MyQueue"/>
<entry name="java:jboss/exported/jms/queue/MyQueue"/>
</jms-queue>
</jms-destinations>
I have found some related posts to this topic but none of them really applied.
Any idieas?
thx and best regards
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/825738#825738]
Start a new discussion in JBoss AS 7 Development at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
10 years, 10 months
.png){kind=link}
.png){kind=link}
