[JBoss JIRA] (DROOLS-3425) Unexpected behavior of docks when multiple editors are opened
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3425?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3425:
-------------------------------------
[~karreiro] Hi, just bringing this to your attention. Decision navigator dock is shown for all stunner based designers in workbench.
> Unexpected behavior of docks when multiple editors are opened
> -------------------------------------------------------------
>
> Key: DROOLS-3425
> URL: https://issues.jboss.org/browse/DROOLS-3425
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor, Scenario Simulation and Testing, Stunner
> Reporter: Klara Kufova
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: ScenarioSimulation, drools-tools
> Attachments: screencast-11-12-18.webm, screencast-12-12-18.webm
>
>
> When multiple assets are opened in different editors, their docks incorrectly interfere. After opening two assets in a row, the Business Central freezes with an unexpected error. Closing one asset causes unexpected disappearance of the left panel.
> See the attached screencast for detailed information. After the assets are opened for the first time, everything seems correct. Once the {{.dmn}} file is opened for the second time, the issues start to occur.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3425) Unexpected behavior of docks when multiple editors are opened
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3425?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3425:
--------------------------------
Labels: ScenarioSimulation drools-tools (was: ScenarioSimulation)
> Unexpected behavior of docks when multiple editors are opened
> -------------------------------------------------------------
>
> Key: DROOLS-3425
> URL: https://issues.jboss.org/browse/DROOLS-3425
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor, Scenario Simulation and Testing, Stunner
> Reporter: Klara Kufova
> Assignee: Toni Rikkola
> Priority: Critical
> Labels: ScenarioSimulation, drools-tools
> Attachments: screencast-11-12-18.webm, screencast-12-12-18.webm
>
>
> When multiple assets are opened in different editors, their docks incorrectly interfere. After opening two assets in a row, the Business Central freezes with an unexpected error. Closing one asset causes unexpected disappearance of the left panel.
> See the attached screencast for detailed information. After the assets are opened for the first time, everything seems correct. Once the {{.dmn}} file is opened for the second time, the issues start to occur.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-5914?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-5914.
--------------------------------
Fix Version/s: 14.0.0.Final
Resolution: Done
I've tried attached standalone-full.xml with Wildfly 14 and list jndi view. I cannot reproducer this issue any more. Closing.
> JNDI view ClassNotFoundException with remote entry
> --------------------------------------------------
>
> Key: WFLY-5914
> URL: https://issues.jboss.org/browse/WFLY-5914
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
> Assignee: Eduardo Martins
> Priority: Major
> Fix For: 14.0.0.Final
>
> Attachments: domain.xml, domain.zip, standalone-full.xml
>
>
> When a binding to a remote Artemis Topic/ConnectionFactory is created, JNDI view fails with a ClassNotFoundException. Both servers are running the "full" profile.
> I attach my domain.xml for reference porpuses. No application needs to be deployed.
> Full operation result:
> [domain@localhost:9990 /] /host=master/server=app-ins01/subsystem=naming:jndi-view()
> {
> "outcome" => "failed",
> "result" => {"java: contexts" => {
> "java:" => {
> "ConnectionFactory" => {
> "class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
> "value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=in-vm, factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
> },
> "JmsXA" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> },
> "TransactionManager" => {
> "class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
> "value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
> },
> "jms" => {
> "class-name" => "javax.naming.Context",
> "children" => {"queue" => {
> "class-name" => "javax.naming.Context",
> "children" => {
> "DLQ" => {
> "class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
> "value" => "ActiveMQQueue[DLQ]"
> },
> "ExpiryQueue" => {
> "class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
> "value" => "ActiveMQQueue[ExpiryQueue]"
> }
> }
> }}
> },
> "jboss" => {
> "class-name" => "javax.naming.Context",
> "value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@d2c52f"
> },
> "global" => {
> "class-name" => "javax.naming.Context",
> "value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@932e80"
> },
> "ejb" => {
> "class-name" => "javax.naming.Context",
> "children" => {"mgmt" => {
> "class-name" => "javax.naming.Context",
> "children" => {"MEJB" => {
> "class-name" => "javax.management.j2ee.ManagementHome",
> "value" => "Proxy for remote EJB EJBHomeLocator for \"jsr-77/jsr-77/EJB\", view is interface javax.management.j2ee.ManagementHome, affinity is None"
> }}
> }}
> }
> },
> "java:jboss" => {
> "ORB" => {
> "class-name" => "com.sun.corba.se.impl.orb.ORBImpl",
> "value" => "com.sun.corba.se.impl.orb.ORBImpl@1306d15"
> },
> "TransactionManager" => {
> "class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
> "value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
> },
> "TransactionSynchronizationRegistry" => {
> "class-name" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper",
> "value" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@206b4c"
> },
> "UserTransaction" => {
> "class-name" => "javax.transaction.UserTransaction",
> "value" => "UserTransaction"
> },
> "corbanaming" => {
> "class-name" => "org.omg.CosNaming._NamingContextExtStub",
> "value" => "IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000000000010000000000000110000102000000000a3132372e302e302e31000e3600000039afabcb00000000220000000100000001000000000000000200000008526f6f74504f4100000000074e616d696e67000000000004726f6f741400000000000005000000010000002000000000000100010000000205010001000100200001010900000001000101000000002600000002000200000000000300000014000000000000000a3132372e302e302e31000e3700000014000000080000001a00000e370000002100000050000000000000000100000000000000220000000000400000000000080606678102010101000000170401000806066781020101010000000744656661756c740000000000000000000000000000000000"
> },
> "irpoa" => {
> "class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
> "value" => "POA[ObjectAdapterID[RootPOA/IRPOA], uniquePOAId=2, state=RUN, invocationCount=0]"
> },
> "jaas" => {
> "class-name" => "com.sun.proxy.$Proxy58",
> "value" => "java:jboss/jaas/ Context proxy"
> },
> "poa" => {
> "class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
> "value" => "POA[ObjectAdapterID[RootPOA], uniquePOAId=0, state=RUN, invocationCount=0]"
> },
> "ee" => {
> "class-name" => "javax.naming.Context",
> "children" => {"concurrency" => {
> "class-name" => "javax.naming.Context",
> "children" => {
> "scheduler" => {
> "class-name" => "javax.naming.Context",
> "children" => {"default" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> }}
> },
> "factory" => {
> "class-name" => "javax.naming.Context",
> "children" => {"default" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> }}
> },
> "executor" => {
> "class-name" => "javax.naming.Context",
> "children" => {"default" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> }}
> },
> "context" => {
> "class-name" => "javax.naming.Context",
> "children" => {"default" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> }}
> }
> }
> }}
> },
> "infinispan" => {
> "class-name" => "javax.naming.Context",
> "children" => {"container" => {
> "class-name" => "javax.naming.Context",
> "children" => {
> "ejb" => {
> "class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
> "value" => "ejb"
> },
> "hibernate" => {
> "class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
> "value" => "hibernate"
> },
> "server" => {
> "class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
> "value" => "server"
> },
> "web" => {
> "class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
> "value" => "web"
> }
> }
> }}
> },
> "datasources" => {
> "class-name" => "javax.naming.Context",
> "children" => {"ExampleDS" => {
> "class-name" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource",
> "value" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource@c79ae8"
> }}
> },
> "mail" => {
> "class-name" => "javax.naming.Context",
> "children" => {"Default" => {
> "class-name" => "javax.mail.Session",
> "value" => "javax.mail.Session@1e9f277"
> }}
> },
> "clustering" => {
> "class-name" => "javax.naming.Context",
> "children" => {"registry" => {
> "class-name" => "javax.naming.Context",
> "children" => {"ejb" => {
> "class-name" => "javax.naming.Context",
> "children" => {"client-mappings" => {
> "class-name" => "org.wildfly.clustering.server.registry.CacheRegistryFactory",
> "value" => "org.wildfly.clustering.server.registry.CacheRegistryFactory@12ac291"
> }}
> }}
> }}
> }
> },
> "java:jboss/exported" => {"jms" => {
> "class-name" => "javax.naming.Context",
> "children" => {"RemoteConnectionFactory" => {
> "class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
> "value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=8190&host=127-0-0-1], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
> }}
> }},
> "java:global" => undefined
> }},
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory from [Module \"org.jboss.as.naming:main\" from local module loader @130015a (finder: local module finder @9f0666 (roots: c:\\wildfly-10.0.0.CR5\\modules,c:\\wildfly-10.0.0.CR5\\modules\\system\\layers\\base))]]",
> "rolled-back" => true
> }
> Injection of the resources via @Resource in an application works as expected. I found this same problem where manually doing the remote lookup from application code, which I resolved adding a dependency to Artemis module in META-INF.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-2443) JMS service shutsdown and doesn't recover after disk fills up.
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-2443?page=com.atlassian.jira.plugin.... ]
Miroslav Novak resolved WFLY-2443.
----------------------------------
Fix Version/s: 16.0.0.Beta1
Resolution: Done
> JMS service shutsdown and doesn't recover after disk fills up.
> --------------------------------------------------------------
>
> Key: WFLY-2443
> URL: https://issues.jboss.org/browse/WFLY-2443
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Environment: RHEL 5.2
> JDK 1.7.0_07
> Reporter: Corey Puffalt
> Assignee: Jeff Mesnil
> Priority: Major
> Fix For: 16.0.0.Beta1
>
>
> In AS 7.1.2 we had a disk fill up and we see warnings (not an error??):
> {code}
> 06:07:40,641 WARNING [org.hornetq.core.server.impl.HornetQServerImpl] (Thread-1973 (HornetQ-remoting-threads-HornetQServerImpl::serverUUID=d7fd8a09-5f3c-11e2-a072-49b352663c05-1554718086-1713338353)) Critical IO Error, shutting down the server. code=6, message=No space left on device
> 06:07:40,892 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (Thread-15478 (HornetQ-client-global-threads-251718996)) Connection failure has been detected: The connection was disconnected because of server shutdown [code=4]
> 06:07:40,893 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-15478 (HornetQ-client-global-threads-251718996)) being disconnected for server shutdown: HornetQException[errorCode=4 message=The connection was disconnected because of server shutdown]
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl$Channel0Handler$1.run(ClientSessionFactoryImpl.java:1468) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> {code}
> After the disk space issue was resolved JMS services didn't recover (though we didn't notice this for awhile) so we didn't restart JBoss as we didn't realize there was an issue. In checking the logs after the fact we see periodic warnings (again, it seems strange this is just a warning instead of an error):
> {code}
> 08:28:51,564 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null] on auto-generated resource recovery: HornetQException[errorCode=2 message=Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:774) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:347) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:]
> 08:28:51,646 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Periodic Recovery) Can't connect to any hornetq server on recovery [XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]]
> 08:28:51,647 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: Error trying to connect to any providers for xa recovery
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:286) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.recover(HornetQXAResourceWrapper.java:76) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:503) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:471) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:385) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:166) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [jbossjts-4.16.4.Final.jar:]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [jbossjts-4.16.4.Final.jar:]
> Caused by: HornetQException[errorCode=2 message=null]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.connect(HornetQXAResourceWrapper.java:396) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.jms.server.recovery.HornetQXAResourceWrapper.getDelegate(HornetQXAResourceWrapper.java:262) [hornetq-jms-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> ... 7 more
> {code}
> It seems if the whole server process isn't going to shutdown when the disk fills up then services like JMS should just reject messages if the disk fills up rather than shutting down. That way services nicely recover as soon as there's disk space again. The way it is currently, it's easy to miss that JBoss is only partially inoperable.
> Thanks,
> Corey
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-6761) Wrong XAException return code when broker timeout is hit
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6761?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6761:
--------------------------------------
Based on reading https://issues.apache.org/jira/browse/ARTEMIS-591 this issue is fixed in Wildfly 12. Closing.
> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>
> Key: WFLY-6761
> URL: https://issues.jboss.org/browse/WFLY-6761
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Priority: Minor
> Fix For: 12.0.0.Final
>
>
> By creating testcases for checking behavior of transaction timeout I've hit an issue of wrong error code being returned when broker transaction timeout is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no longer consider the calling thread associated with that resource manager (although it must consider the resource manager part of the transaction branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at
> org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean$$$endpoint1.afterDelivery(Unknown
> Source)
> at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:321)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:932)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1045)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-6761) Wrong XAException return code when broker timeout is hit
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-6761?page=com.atlassian.jira.plugin.... ]
Miroslav Novak closed WFLY-6761.
--------------------------------
Fix Version/s: 12.0.0.Final
Resolution: Done
> Wrong XAException return code when broker timeout is hit
> --------------------------------------------------------
>
> Key: WFLY-6761
> URL: https://issues.jboss.org/browse/WFLY-6761
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
> Priority: Minor
> Fix For: 12.0.0.Final
>
>
> By creating testcases for checking behavior of transaction timeout I've hit an issue of wrong error code being returned when broker transaction timeout is hit before TM transaction timeout expires.
> It uses {{XAER_PROTO}} instead of {{RBTIMEOUT}}.
> This issue does not cause data inconsistency.
> Scenario:
> * ejb sends a message to a queue
> * processing inside of the ejb takes long time
> ** TM transaction timeout is set big enough to not hit the timeout
> ** jms broker internal transaction timeout is smaller than time needed for processing ejb method
> * jms broker txn timeout occurs - broker local txn is rolled back
> ** txn is removed from list of broker's local in-process transactions
> * TM calls XAResource.end
> ** the call returns {{XAException.XAER_PROTO}}
> That's current implementation returns {{XAER_PROTO}} in this scenario but {{RBTIMEOUT}} would be more appropriate.
> From discussion with Narayana developers, RM should return the most specific error return code as possible. In this scenario it's {{RBTIMEOUT}}.
> Other notes from TM dev point of view:
> {code}
> "[XA_RBTIMEOUT]
> The work represented by this transaction branch took too long."
> {code}
> _per XA spec page 39._
> The more complex question is, at what point can the resource manager forget about that branch (and therefore return NOTA to subsequent calls)?
> The XA spec says "After the transaction manager calls xa_end(), it should no longer consider the calling thread associated with that resource manager (although it must consider the resource manager part of the transaction branch when it prepares the branch.)"
> which implies the branch is still considered live at that point, a view corroborated by:
> {code}
> "[XA_RB∗]
> The resource manager has dissociated the transaction branch from the thread of control and has marked rollback-only the work performed on behalf of ∗xid."
> {code}
> Exception being thrown
> {code}
> WARN [com.arjuna.ats.jta] (Thread-0
> (ActiveMQ-client-global-threads-1468293951)) ARJUNA016056:
> TransactionImple.delistResource - caught exception during delist :
> XAException.XAER_PROTO: javax.transaction.xa.XAException
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.xaEnd(ActiveMQSessionContext.java:346)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.end(ClientSessionImpl.java:1115)
> at
> org.apache.activemq.artemis.ra.ActiveMQRAXAResource.end(ActiveMQRAXAResource.java:112)
> at
> org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.end(ActiveMQXAResourceWrapperImpl.java:81)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:897)
> at
> org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.beforeCompletion(TxConnectionListener.java:1063)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeBefore(TransactionSynchronizer.java:438)
> at
> org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.beforeCompletion(TransactionSynchronizer.java:376)
> at
> org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:130)
> at
> com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371)
> at
> com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at
> com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at
> com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.handle(AbstractInvocationHandler.java:60)
> at
> org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:135)
> at
> org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at
> org.jboss.as.test.jbossts.crashrec.jms.mdb.JMSCrashMessageDrivenBean$$$endpoint1.afterDelivery(Unknown
> Source)
> at
> org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:321)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:932)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:47)
> at
> org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1045)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:100)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months