[JBoss JIRA] (JBTM-2394) Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-2394?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben updated JBTM-2394:
------------------------------------------
Description:
The scenario is as follows:
An regular JBoss application thread uses the connection associated with an XAResource for it's work with the database backend. Start(xid) had been invoked, which means, the associated connection is "switched" to that xid. After finishing work, the regular JBoss application thread would eventually call end(xid, TMSUCCESS).
The application executes a query that takes longer than the configured timeout.
The work with the database is done via database specific RPC invocations, caused by a enterprise bean (which uses the JPA API and the JPA implementation eventually talks to the database via the database protocol).
The (lower-level) connection is --unsurprisingly-- a TCP/IP connection, and
the RPC protocol --also unsurprisingly-- if of the form: "send data to server, then wait for server reply"
At this point it should be clear, that the TCP/IP connection should not be shared by another thread whilst in the middle of an RPC invocation, because neither does the database server expect any data at this moment on this particular TCP/IP connection nor does it work, that then 2 threads wait on the same socket to receive a reply. (E.g. a ClosedByInterruptException is likely, there might be other error though, depending how wrong data is interpreted, e.g. BufferUnderflowException).
Unfortunately, this is exactly the behavior of the JBoss "Transaction Reaper" thread, that uses the very same XAResource, that had been used by the regular JBoss application thread and is currently associated to a connection, "switched" to the current xid.
By definition of the XA specification, any other XAResource could be used to terminate that transaction branch, and it would be fine, if the transaction reaper thread would use any XAResource (regular one, or one from our recovery module) to do that.
This is a conceptual flaw of the transaction reaper implementation, and we can't implement a workaround (except extremely silly things like reaper thread recognition by comparing thread names ...)
We could synchronized access to the TCP/IP connection, to not allow another thread communication, while another thread is active doing so, however, that kind of defeats the purpose of the reaper thread, as it would be blocked indefinitely.
was:
The scenario is as follows:
An regular JBoss application thread uses the connection associated with an XAResource for it's work with the database backend. Start(xid) had been invoked, which means, the associated connection is "switched" to that xid. After finishing work, the regular JBoss application thread would eventually call end(xid, TMSUCCESS).
The work with the database is done via database specific RPC invocations, caused by a enterprise bean (which uses the JPA API and the JPA implementation eventually talks to the database via the database protocol).
The (lower-level) connection is --unsurprisingly-- a TCP/IP connection, and
the RPC protocol --also unsurprisingly-- if of the form: "send data to server, then wait for server reply"
At this point it should be clear, that the TCP/IP connection should not be shared by another thread whilst in the middle of an RPC invocation, because neither does the database server expect any data at this moment on this particular TCP/IP connection nor does it work, that then 2 threads wait on the same socket to receive a reply. (E.g. a ClosedByInterruptException is likely, there might be other error though, depending how wrong data is interpreted, e.g. BufferUnderflowException).
Unfortunately, this is exactly the behavior of the JBoss "Transaction Reaper" thread, that uses the very same XAResource, that had been used by the regular JBoss application thread and is currently associated to a connection, "switched" to the current xid.
By definition of the XA specification, any other XAResource could be used to terminate that transaction branch, and it would be fine, if the transaction reaper thread would use any XAResource (regular one, or one from our recovery module) to do that.
This is a conceptual flaw of the transaction reaper implementation, and we can't implement a workaround (except extremely silly things like reaper thread recognition by comparing thread names ...)
We could synchronized access to the TCP/IP connection, to not allow another thread communication, while another thread is active doing so, however, that kind of defeats the purpose of the reaper thread, as it would be blocked indefinitely.
> Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
> ---------------------------------------------------------------------------------
>
> Key: JBTM-2394
> URL: https://issues.jboss.org/browse/JBTM-2394
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> The scenario is as follows:
> An regular JBoss application thread uses the connection associated with an XAResource for it's work with the database backend. Start(xid) had been invoked, which means, the associated connection is "switched" to that xid. After finishing work, the regular JBoss application thread would eventually call end(xid, TMSUCCESS).
> The application executes a query that takes longer than the configured timeout.
> The work with the database is done via database specific RPC invocations, caused by a enterprise bean (which uses the JPA API and the JPA implementation eventually talks to the database via the database protocol).
> The (lower-level) connection is --unsurprisingly-- a TCP/IP connection, and
> the RPC protocol --also unsurprisingly-- if of the form: "send data to server, then wait for server reply"
> At this point it should be clear, that the TCP/IP connection should not be shared by another thread whilst in the middle of an RPC invocation, because neither does the database server expect any data at this moment on this particular TCP/IP connection nor does it work, that then 2 threads wait on the same socket to receive a reply. (E.g. a ClosedByInterruptException is likely, there might be other error though, depending how wrong data is interpreted, e.g. BufferUnderflowException).
> Unfortunately, this is exactly the behavior of the JBoss "Transaction Reaper" thread, that uses the very same XAResource, that had been used by the regular JBoss application thread and is currently associated to a connection, "switched" to the current xid.
> By definition of the XA specification, any other XAResource could be used to terminate that transaction branch, and it would be fine, if the transaction reaper thread would use any XAResource (regular one, or one from our recovery module) to do that.
> This is a conceptual flaw of the transaction reaper implementation, and we can't implement a workaround (except extremely silly things like reaper thread recognition by comparing thread names ...)
> We could synchronized access to the TCP/IP connection, to not allow another thread communication, while another thread is active doing so, however, that kind of defeats the purpose of the reaper thread, as it would be blocked indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2394) Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
by Christian von Kutzleben (JIRA)
Christian von Kutzleben created JBTM-2394:
---------------------------------------------
Summary: Transaction Reaper "abuses" in-use connection, leading to RPC protocol corruption
Key: JBTM-2394
URL: https://issues.jboss.org/browse/JBTM-2394
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Christian von Kutzleben
Assignee: Tom Jenkinson
The scenario is as follows:
An regular JBoss application thread uses the connection associated with an XAResource for it's work with the database backend. Start(xid) had been invoked, which means, the associated connection is "switched" to that xid. After finishing work, the regular JBoss application thread would eventually call end(xid, TMSUCCESS).
The work with the database is done via database specific RPC invocations, caused by a enterprise bean (which uses the JPA API and the JPA implementation eventually talks to the database via the database protocol).
The (lower-level) connection is --unsurprisingly-- a TCP/IP connection, and
the RPC protocol --also unsurprisingly-- if of the form: "send data to server, then wait for server reply"
At this point it should be clear, that the TCP/IP connection should not be shared by another thread whilst in the middle of an RPC invocation, because neither does the database server expect any data at this moment on this particular TCP/IP connection nor does it work, that then 2 threads wait on the same socket to receive a reply. (E.g. a ClosedByInterruptException is likely, there might be other error though, depending how wrong data is interpreted, e.g. BufferUnderflowException).
Unfortunately, this is exactly the behavior of the JBoss "Transaction Reaper" thread, that uses the very same XAResource, that had been used by the regular JBoss application thread and is currently associated to a connection, "switched" to the current xid.
By definition of the XA specification, any other XAResource could be used to terminate that transaction branch, and it would be fine, if the transaction reaper thread would use any XAResource (regular one, or one from our recovery module) to do that.
This is a conceptual flaw of the transaction reaper implementation, and we can't implement a workaround (except extremely silly things like reaper thread recognition by comparing thread names ...)
We could synchronized access to the TCP/IP connection, to not allow another thread communication, while another thread is active doing so, however, that kind of defeats the purpose of the reaper thread, as it would be blocked indefinitely.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2393) Add google analytics to the docs and narayana.io
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2393:
-----------------------------------
Summary: Add google analytics to the docs and narayana.io
Key: JBTM-2393
URL: https://issues.jboss.org/browse/JBTM-2393
Project: JBoss Transaction Manager
Issue Type: Task
Components: Documentation
Reporter: Tom Jenkinson
Assignee: Gytis Trikleris
Fix For: 5.next
For the docs, see an example here:
https://github.com/pressgang/pressgang-tools/blob/master/pressgang-tools-...
<transformerParameters>
<html.googleAnalyticsId>UA-XXXXXXX-X</html.googleAnalyticsId>
<html.googleTagManagerId>GTM-NJWS5L</html.googleTagManagerId>
<html.googleTagManagerChannel>MyProject</html.googleTagManagerChannel>
</transformerParameters>
We don't want that in normal builds, maybe add it in a release profile and update brp.xml to generate the docs with that enabled.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2392?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-2392.
---------------------------------
Resolution: Duplicate Issue
> XA recovery exceptions
> ----------------------
>
> Key: JBTM-2392
> URL: https://issues.jboss.org/browse/JBTM-2392
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: wildfly-8.2.0.Final + Windows 7 + Microsoft SQL Server 2008 (SP2) + Microsoft JDBC 4.0 and 4.1 Drivers
> Reporter: Mark S
> Assignee: Tom Jenkinson
>
> h3. Wildfly Exception Stack Trace of Issue:
> {code}
> 12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> h3. SQL Server Profiler Stack Trace of Issue:
> declare @p2 int
> set @p2=-3
> declare @p3 nvarchar(max)
> set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
> declare @p5 varbinary(max)
> set @p5=NULL
> exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
> select @p2, @p3, @p5
> h3. Possible Related Issues:
> * https://issues.jboss.org/browse/JBTM-1433
> * http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2392?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2392:
-------------------------------------
Looks like a duplicate of JBTM-2216 to me. https://github.com/jbosstm/narayana/blame/master/ArjunaJTA/jta/classes/co...
Its fixed in WFLY master version (was fixed in Narayana 5.0.4 which should be in WFLY since 9.Beta1).
> XA recovery exceptions
> ----------------------
>
> Key: JBTM-2392
> URL: https://issues.jboss.org/browse/JBTM-2392
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: wildfly-8.2.0.Final + Windows 7 + Microsoft SQL Server 2008 (SP2) + Microsoft JDBC 4.0 and 4.1 Drivers
> Reporter: Mark S
> Assignee: Tom Jenkinson
>
> h3. Wildfly Exception Stack Trace of Issue:
> {code}
> 12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> h3. SQL Server Profiler Stack Trace of Issue:
> declare @p2 int
> set @p2=-3
> declare @p3 nvarchar(max)
> set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
> declare @p5 varbinary(max)
> set @p5=NULL
> exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
> select @p2, @p3, @p5
> h3. Possible Related Issues:
> * https://issues.jboss.org/browse/JBTM-1433
> * http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Mark S (JIRA)
[ https://issues.jboss.org/browse/JBTM-2392?page=com.atlassian.jira.plugin.... ]
Mark S updated JBTM-2392:
-------------------------
Description:
h3. Wildfly Exception Stack Trace of Issue:
{code}
12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
{code}
h3. SQL Server Profiler Stack Trace of Issue:
declare @p2 int
set @p2=-3
declare @p3 nvarchar(max)
set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
declare @p5 varbinary(max)
set @p5=NULL
exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
select @p2, @p3, @p5
h3. Possible Related Issues:
* https://issues.jboss.org/browse/JBTM-1433
* http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
was:
h3. Wildfly Exception Stack Trace of Issue:
{code}
12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
{code}
h3. SQL Server Profiler Stack Trace of Issue:
declare @p2 int
set @p2=-3
declare @p3 nvarchar(max)
set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
declare @p5 varbinary(max)
set @p5=NULL
exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
select @p2, @p3, @p5
Possible Related Issues:
* https://issues.jboss.org/browse/JBTM-1433
* http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
> XA recovery exceptions
> ----------------------
>
> Key: JBTM-2392
> URL: https://issues.jboss.org/browse/JBTM-2392
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: wildfly-8.2.0.Final + Windows 7 + Microsoft SQL Server 2008 (SP2) + Microsoft JDBC 4.0 and 4.1 Drivers
> Reporter: Mark S
> Assignee: Tom Jenkinson
>
> h3. Wildfly Exception Stack Trace of Issue:
> {code}
> 12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> h3. SQL Server Profiler Stack Trace of Issue:
> declare @p2 int
> set @p2=-3
> declare @p3 nvarchar(max)
> set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
> declare @p5 varbinary(max)
> set @p5=NULL
> exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
> select @p2, @p3, @p5
> h3. Possible Related Issues:
> * https://issues.jboss.org/browse/JBTM-1433
> * http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Mark S (JIRA)
[ https://issues.jboss.org/browse/JBTM-2392?page=com.atlassian.jira.plugin.... ]
Mark S updated JBTM-2392:
-------------------------
Environment: wildfly-8.2.0.Final + Windows 7 + Microsoft SQL Server 2008 (SP2) + Microsoft JDBC 4.0 and 4.1 Drivers (was: * wildfly-8.2.0.Final
* Windows 7
* Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) Feb 25 2011 13:56:11 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
* Both Microsoft JDBC Driver for SQL Server 4.0 and 4.1 Drivers)
> XA recovery exceptions
> ----------------------
>
> Key: JBTM-2392
> URL: https://issues.jboss.org/browse/JBTM-2392
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: wildfly-8.2.0.Final + Windows 7 + Microsoft SQL Server 2008 (SP2) + Microsoft JDBC 4.0 and 4.1 Drivers
> Reporter: Mark S
> Assignee: Tom Jenkinson
>
> h3. Wildfly Exception Stack Trace of Issue:
> {code}
> 12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> h3. SQL Server Profiler Stack Trace of Issue:
> declare @p2 int
> set @p2=-3
> declare @p3 nvarchar(max)
> set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
> declare @p5 varbinary(max)
> set @p5=NULL
> exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
> select @p2, @p3, @p5
> Possible Related Issues:
> * https://issues.jboss.org/browse/JBTM-1433
> * http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Mark S (JIRA)
[ https://issues.jboss.org/browse/JBTM-2392?page=com.atlassian.jira.plugin.... ]
Mark S updated JBTM-2392:
-------------------------
Environment:
* wildfly-8.2.0.Final
* Windows 7
* Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) Feb 25 2011 13:56:11 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
* Both Microsoft JDBC Driver for SQL Server 4.0 and 4.1 Drivers
was:
* wildfly-8.2.0.Final
* Windows 7
* Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) Feb 25 2011 13:56:11 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
* Both Microsoft JDBC Driver for SQL Server 4.0 and 4.1 Drivers
> XA recovery exceptions
> ----------------------
>
> Key: JBTM-2392
> URL: https://issues.jboss.org/browse/JBTM-2392
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Environment: * wildfly-8.2.0.Final
> * Windows 7
> * Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) Feb 25 2011 13:56:11 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
> * Both Microsoft JDBC Driver for SQL Server 4.0 and 4.1 Drivers
> Reporter: Mark S
> Assignee: Tom Jenkinson
>
> h3. Wildfly Exception Stack Trace of Issue:
> {code}
> 12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> 12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
> at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> h3. SQL Server Profiler Stack Trace of Issue:
> declare @p2 int
> set @p2=-3
> declare @p3 nvarchar(max)
> set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
> declare @p5 varbinary(max)
> set @p5=NULL
> exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
> select @p2, @p3, @p5
> Possible Related Issues:
> * https://issues.jboss.org/browse/JBTM-1433
> * http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month
[JBoss JIRA] (JBTM-2392) XA recovery exceptions
by Mark S (JIRA)
Mark S created JBTM-2392:
----------------------------
Summary: XA recovery exceptions
Key: JBTM-2392
URL: https://issues.jboss.org/browse/JBTM-2392
Project: JBoss Transaction Manager
Issue Type: Feature Request
Environment: * wildfly-8.2.0.Final
* Windows 7
* Microsoft SQL Server 2008 (SP2) - 10.0.4064.0 (X64) Feb 25 2011 13:56:11 Copyright (c) 1988-2008 Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
* Both Microsoft JDBC Driver for SQL Server 4.0 and 4.1 Drivers
Reporter: Mark S
Assignee: Tom Jenkinson
h3. Wildfly Exception Stack Trace of Issue:
{code}
12:12:42,427 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:650) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
12:12:42,431 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: The function RECOVER: failed. The status is: -3. Error: "*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***"
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.DTC_XA_Interface(SQLServerXAResource.java:550)
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.recover(SQLServerXAResource.java:728)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:362)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:740) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:431) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:212) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
{code}
h3. SQL Server Profiler Stack Trace of Issue:
declare @p2 int
set @p2=-3
declare @p3 nvarchar(max)
set @p3=N'*** SQLJDBC_XA DTC_ERROR Context: xa_recover, state=1, StatusCode:-3 (0xFFFFFFFD) ***'
declare @p5 varbinary(max)
set @p5=NULL
exec sp_execute 1,@p2 output,@p3 output,8388608,@p5 output
select @p2, @p3, @p5
Possible Related Issues:
* https://issues.jboss.org/browse/JBTM-1433
* http://stackoverflow.com/questions/14476414/jboss-spamming-xa-recovery-wa...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 1 month