[JBoss JIRA] (JBTM-2308) New JTS record types are not showing up in the tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2308:
-----------------------------------
Summary: New JTS record types are not showing up in the tooling (was: New JTS participants are not showing up in the tooling)
> New JTS record types are not showing up in the tooling
> ------------------------------------------------------
>
> Key: JBTM-2308
> URL: https://issues.jboss.org/browse/JBTM-2308
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Tooling
> Affects Versions: 4.17.23, 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
> I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it).
> What is missing is instrumentation for new types:
> {code}
> AssumedCompleteHeuristicTransaction
> AssumedCompleteHeuristicServerTransaction
> AssumedCompleteTransaction
> AssumedCompleteServerTransaction
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2308) New JTS participants are not showing up in the tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2308:
-----------------------------------
Summary: New JTS participants are not showing up in the tooling (was: JTS participants are not showing up in the tooling)
> New JTS participants are not showing up in the tooling
> ------------------------------------------------------
>
> Key: JBTM-2308
> URL: https://issues.jboss.org/browse/JBTM-2308
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Tooling
> Affects Versions: 4.17.23, 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
> I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it).
> What is missing is instrumentation for new types:
> {code}
> AssumedCompleteHeuristicTransaction
> AssumedCompleteHeuristicServerTransaction
> AssumedCompleteTransaction
> AssumedCompleteServerTransaction
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2308) JTS participants are not showing up in the tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2308:
-----------------------------------
Description:
When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it).
What is missing is instrumentation for new types:
{code}
AssumedCompleteHeuristicTransaction
AssumedCompleteHeuristicServerTransaction
AssumedCompleteTransaction
AssumedCompleteServerTransaction
{code}
was:
When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
I've marked the JIRA as a bug rather than an enhancement since it used to work (I'll fix the missing test at the same time).
> JTS participants are not showing up in the tooling
> --------------------------------------------------
>
> Key: JBTM-2308
> URL: https://issues.jboss.org/browse/JBTM-2308
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Tooling
> Affects Versions: 4.17.23, 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
> I have marked the type to enhancement since JTS participants do show up in the tooling (using records that are in-lined with records of type /StateManager/BasicAction/TwoPhaseCoordinator/ArjunaTransactionImple). Note that the tooling implementation does not look at records of type CosTransactions/XAResourceRecord (the only potentially useful information for the user here is the Xid and I will leave that until someone asks for it).
> What is missing is instrumentation for new types:
> {code}
> AssumedCompleteHeuristicTransaction
> AssumedCompleteHeuristicServerTransaction
> AssumedCompleteTransaction
> AssumedCompleteServerTransaction
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2308) JTS participants are not showing up in the tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2308?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2308:
-----------------------------------
Issue Type: Enhancement (was: Bug)
> JTS participants are not showing up in the tooling
> --------------------------------------------------
>
> Key: JBTM-2308
> URL: https://issues.jboss.org/browse/JBTM-2308
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Tooling
> Affects Versions: 4.17.23, 5.0.3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.4
>
>
> When a JTS transaction record has participants of type CosTransactions/XAResourceRecord which are in the same object store then the tooling should create MBeans to represent them as participants of the JTS record.
> I've marked the JIRA as a bug rather than an enhancement since it used to work (I'll fix the missing test at the same time).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2288) Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2288?page=com.atlassian.jira.plugin.... ]
Amos Feng updated JBTM-2288:
----------------------------
Priority: Minor (was: Major)
> Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2288
> URL: https://issues.jboss.org/browse/JBTM-2288
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration, BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.4
>
>
> When deploy the balcktie admin ear, the wildfly throws NameNotFound Exception when deploying the BlacktiAdminService MBean
> {code}
> 11:39:30,059 INFO [org.jboss.narayana.blacktie.administration.BlacktieAdminService] (MSC service thread 1-8) Admin Server Started
> 11:39:30,060 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:77) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.service.StartStopService.start(StartStopService.java:57) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2288) Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2288?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-2288:
---------------------------------
[~tomjenkinson] it looks like the wildfly issue and you can see my comments on the WFLY-4008. This exception does not effect our blacktie tests. So I thinks it is safe to set the lower priority and wait for the WFLY-4008 being resolved.
> Deploy/Undeploy BlacktieAdminService MBean throws javax.naming.NameNotFoundException: java:comp/BeanManager
> -----------------------------------------------------------------------------------------------------------
>
> Key: JBTM-2288
> URL: https://issues.jboss.org/browse/JBTM-2288
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Application Server Integration, BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.4
>
>
> When deploy the balcktie admin ear, the wildfly throws NameNotFound Exception when deploying the BlacktiAdminService MBean
> {code}
> 11:39:30,059 INFO [org.jboss.narayana.blacktie.administration.BlacktieAdminService] (MSC service thread 1-8) Admin Server Started
> 11:39:30,060 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:77) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.as.service.StartStopService.start(StartStopService.java:57) [wildfly-sar-9.0.0.Alpha2-SNAPSHOT.jar:9.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 11:39:30,064 ERROR [org.jboss.as.weld] (MSC service thread 1-8) WFLYWELD0002: Failed to tear down Weld contexts: javax.naming.NameNotFoundException: java:comp/BeanManager
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:187)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:231)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184)
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_21]
> at org.jboss.as.weld.arquillian.WeldContextSetup.teardown(WeldContextSetup.java:108)
> at org.jboss.as.jmx.MBeanRegistrationService.start(MBeanRegistrationService.java:106) [wildfly-jmx-1.0.0.Alpha9.jar:1.0.0.Alpha9]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-1867) Confusing error logged after crash recovery on prepare when hornetq object store used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1867?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1867:
-----------------------------------------------
Hayk Hovsepyan <hhovsepy(a)redhat.com> changed the Status of [bug 992915|https://bugzilla.redhat.com/show_bug.cgi?id=992915] from ON_QA to VERIFIED
> Confusing error logged after crash recovery on prepare when hornetq object store used
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1867
> URL: https://issues.jboss.org/browse/JBTM-1867
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 4.17.7, 5.0.0.M3
> Reporter: Ondřej Chaloupka
> Assignee: Michael Musgrove
> Fix For: 4.17.9, 5.0.0.M5
>
>
> There is logged an confusing error after crash recovery happens when server crashed in prepare phase.
> {code}
> 14:47:59,697 ERROR [stderr] (RequestProcessor-10) com.arjuna.ats.arjuna.exceptions.ObjectStoreException: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:153)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqObjectStoreAdaptor.remove_committed(HornetqObjectStoreAdaptor.java:186)
> 14:47:59,698 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.destroyState(XAResourceRecord.java:1271)
> 14:47:59,699 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=TestXAResourceRecovered(TestXAResourceCommon(0, null)))
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.rollback(XAResourceRecord.java:411)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:213)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
> 14:47:59,699 ERROR [stderr] (RequestProcessor-10) at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) Caused by: java.lang.IllegalStateException: Cannot find add info 3
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:904)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalBase.appendDeleteRecord(JournalBase.java:163)
> 14:47:59,700 ERROR [stderr] (RequestProcessor-10) at org.hornetq.core.journal.impl.JournalImpl.appendDeleteRecord(JournalImpl.java:82)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) at com.arjuna.ats.internal.arjuna.objectstore.hornetq.HornetqJournalStore.remove_committed(HornetqJournalStore.java:151)
> 14:47:59,701 ERROR [stderr] (RequestProcessor-10) ... 7 more
> {code}
> This happens when hornetq object store is used. This is caused because of the rollback is called on resource two times. This is ok - this matches to OTS spec (https://bugzilla.redhat.com/show_bug.cgi?id=988724).
> But after the second call of rollback the TM tries to remove Xid from object store. But as the xid does not exist anymore the hornetq object store implementation throws exception that is logged directly on stderr:
> XAResourceRecord.destroyState does e.printStackTrace()
> I would propose to put this exception to debug or trace as it does not mean error in fact.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-2255:
-----------------------------------------------
Hayk Hovsepyan <hhovsepy(a)redhat.com> changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from ON_QA to VERIFIED
> Do not return StatusCommiting, if transaction was commited by the original transaction manager
> ----------------------------------------------------------------------------------------------
>
> Key: JBTM-2255
> URL: https://issues.jboss.org/browse/JBTM-2255
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Reporter: Gytis Trikleris
> Assignee: Gytis Trikleris
> Fix For: 4.17.23, 5.0.4
>
>
> We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing.
> However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (JBTM-1175) Add warning message during recovery if heuristic occurs
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1175?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1175 started by Mark Little.
-----------------------------------------
> Add warning message during recovery if heuristic occurs
> -------------------------------------------------------
>
> Key: JBTM-1175
> URL: https://issues.jboss.org/browse/JBTM-1175
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: JTA, JTS, Recovery, Transaction Core
> Affects Versions: 4.16.4
> Reporter: Mark Little
> Assignee: Mark Little
>
> Heuristics during recovery used to be treated via the OTS hooking in various notification mechanisms, e.g., the CORBA notification service. That code is gone and as a result we silently ignore heuristics during recovery. This is not an issue for consistency, because the heuristic resolution tool(s) were always intended to scan the object store and flag all logs that are in a heuristic state. However, it might be nice for admins to have a pro-active indication that a failure has occurred. Need to check all recovery instances for those that are now silent.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months