From 7bc21b2020e561d4418815aeebc9b62daf8bdda8 Mon Sep 17 00:00:00 2001 From: Eduardo Martins Date: Tue, 14 Jan 2025 09:37:19 +0000 Subject: [PATCH] Remove obsolete properties --- jta-crash-rec/README-source.adoc | 2 +- pom.xml | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/jta-crash-rec/README-source.adoc b/jta-crash-rec/README-source.adoc index c60a72608d..46837bf3cc 100644 --- a/jta-crash-rec/README-source.adoc +++ b/jta-crash-rec/README-source.adoc @@ -169,7 +169,7 @@ WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:1040a11d:534ede43:1c, node_name=1, branch_uid=0:ffff7f000001:1040a11d:534ede43:20, subordinatenodename=null, eis_name=java:jboss/datasources/JTACrashRecQuickstartDS > ---- + -This is normal. What actually happened is that the first resource, `JTACrashRecQuickstartDS`, committed before the {productName} server was halted to insert the recovery record. The transaction logs are only updated/deleted after the outcome of the transaction is determined. If the transaction manager did update the log as each participant (database and JMS queue) completed then throughput would suffer. Notice you do not get a similar message for the JMS resource since that is the resource that recovered and the log record was updated to reflect this change. You need to manually remove the record for the first participant if you know which one is which or, if you are using the community version of the ${product.name} server, then you can also inspect the transaction logs using a JMX browser. For the demo it is simplest to delete the records from the file system, however, *be wary of doing this on a production system*. +This is normal. What actually happened is that the first resource, `JTACrashRecQuickstartDS`, committed before the {productName} server was halted to insert the recovery record. The transaction logs are only updated/deleted after the outcome of the transaction is determined. If the transaction manager did update the log as each participant (database and JMS queue) completed then throughput would suffer. Notice you do not get a similar message for the JMS resource since that is the resource that recovered and the log record was updated to reflect this change. You need to manually remove the record for the first participant if you know which one is which or, if you are using the community version of the ${productName} server, then you can also inspect the transaction logs using a JMX browser. For the demo it is simplest to delete the records from the file system, however, *be wary of doing this on a production system*. . Do NOT forget to link:{configureBytemanDisableDocUrl}[Disable the Byteman script] by restoring the backup server configuration file. The Byteman rule must be removed to ensure that your application server will be able to commit 2PC transactions! diff --git a/pom.xml b/pom.xml index dd6fc7b64b..9156ac4821 100644 --- a/pom.xml +++ b/pom.xml @@ -48,8 +48,6 @@ ${project.basedir} - WILDFLY_HOME - WildFly 2.1.0 1.0.7.Final