[JBoss JIRA] (WFLY-11470) Cannot wire or start components while the registry is not running
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-11470:
-----------------------------------
Summary: Cannot wire or start components while the registry is not running
Key: WFLY-11470
URL: https://issues.jboss.org/browse/WFLY-11470
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 15.0.0.Final
Reporter: Paul Ferraro
Assignee: Dan Berindei
Looks like yet another clean shutdown issue surfaced after we changed WFLY-11324 to avoid some graceful shutdown bugs with the XA transaction table.
{noformat}
16:28:38,874 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionAccessMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionCreationMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionAttributesKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@72} org.infinispan.transaction.synchronization.SynchronizationAdapter@91: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11469) Cannot wire or start components while the registry is not running
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11469?page=com.atlassian.jira.plugin... ]
Paul Ferraro moved ISPN-9790 to WFLY-11469:
-------------------------------------------
Project: WildFly (was: Infinispan)
Key: WFLY-11469 (was: ISPN-9790)
Workflow: GIT Pull Request workflow (was: GIT Pull Request with Triage workflow)
Component/s: Clustering
(was: Core)
Affects Version/s: 15.0.0.Final
(was: 9.4.1.Final)
> Cannot wire or start components while the registry is not running
> ------------------------------------------------------------------
>
> Key: WFLY-11469
> URL: https://issues.jboss.org/browse/WFLY-11469
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 15.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Major
>
> Looks like yet another clean shutdown issue surfaced after we changed WFLY-11324 to avoid some graceful shutdown bugs with the XA transaction table.
> {noformat}
> 16:28:38,874 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionAccessMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionCreationMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionAttributesKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@72} org.infinispan.transaction.synchronization.SynchronizationAdapter@91: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
> at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
> at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
> at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
> at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
> at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
> at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3286) [DMN Designer] FunctionGrid: Move F, J, P selector to header
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3286?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3286:
----------------------------------------
[~dadossan] Hello,
Following the discussion in the Scrum meeting today:-
# Set the "class", "method name" etc parameter type to {{String}} in [this|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-...] loop. You should be able to do {{InformationItem.setTypeRef(BuiltInType.STRING.asQName())}}.
# Make sure the new column (containing the F, J, P header) has {{setMovable(false)}} called in its constructor.
> [DMN Designer] FunctionGrid: Move F, J, P selector to header
> -------------------------------------------------------------
>
> Key: DROOLS-3286
> URL: https://issues.jboss.org/browse/DROOLS-3286
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Michael Anstis
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> The {{FunctionGrid}} allows switching between FEEL, Java and PMML function definitions using the context menu. [~tirelli] has requested this be changed to a selector in the header. A new column needs to be added with the F, J, P selector in the new column header. The header should display F, J or P accordingly. Do not include row numbers (i.e. don't just add a {{RowNumberColumn}}!
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11450) Cannot get delegate of JMSContext during an beforeCompletion synch
by Jan-Willem Gmelig Meyling (Jira)
[ https://issues.jboss.org/browse/WFLY-11450?page=com.atlassian.jira.plugin... ]
Jan-Willem Gmelig Meyling commented on WFLY-11450:
--------------------------------------------------
I'll create a PR with a reproducer. Hopefully I can rather easily figure out how to enable JTA and JMS with a queue to write on, but I suppose ill find my way around rather easily.
But basically the test will come down to:
* Start a transaction
* Registrer a synchronization that accesses an injected JMS context in the beforeCompletion method.
* Don't interact with the JMS context.
* Try to create a producer from the JMSContext in the sync, notice that it will fail because the delegate tries to register a synchronization that will do the clean up of the jms context.
In reality my synchronization is not placed by myself, but Hibernate, which uses a synch to flush the entities prior to commit, but I think that aspect is mostly irrelevant to the reproducer.
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: WFLY-11450
> URL: https://issues.jboss.org/browse/WFLY-11450
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 14.0.1.Final, 8.0.0.CR1
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Assignee: Matej Novotny
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-3396:
---------------------------------
Sprint: 2018 Week 48-50
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-3396:
--------------------------------------
[~hiroko] I took a quick look and I can reproduce. Today I tried to narrow down the cause and I will continue the work tomorrow.
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola reassigned DROOLS-3396:
------------------------------------
Assignee: Toni Rikkola (was: Mario Fusco)
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-10841) XA recovery warnings when server reloaded
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-10841?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10841:
----------------------------------------
The issue should be fixed in the next Narayana release (most probably 5.9.1.Final) by fix of [~tomjenkinson] - https://github.com/jbosstm/narayana/pull/1378. The issue to be fixed in the WildFly requires the Narayana component upgrade.
> XA recovery warnings when server reloaded
> -----------------------------------------
>
> Key: WFLY-10841
> URL: https://issues.jboss.org/browse/WFLY-10841
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 13.0.0.Final, 14.0.0.Final
> Reporter: Chao Wang
> Assignee: Ondra Chaloupka
> Priority: Minor
>
> Following warning messages are outputted when server reloaded.
> {code}
> 15:33:52,740 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122015: Can not connect to XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=, factory=org-apache-activemq-artemi
> s-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA] on auto-generated resource recovery: ActiveMQNotConnectedException[errorType=NOT_CONNECTED m
> essage=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:311)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> 15:33:52,752 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122008: XA Recovery can not connect to any broker on recovery [XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=
> , factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA]]
> 15:33:52,752 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: Error trying to connect to any providers for xa reco
> very
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:258)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=null]
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:345)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month