May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Flavia Rainone (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on WFLY-12090: --------------------------------------- [~tomjenkinson] The explanation is that EJB deployment triggers EJBRemote startup and triggers RemotingTransactionServiceService startup (those services are lazy). Any of them will satisfy the recovery in the sense that they will trigger registration of "ejb" and "txn" as remote service (notice that these remote services are another type of service, they are not MSC services nor are related with capabilities, but they will leave Remoting in a satisfactory state so it can be used for communications with the other server). Once those EJB components are missing, the RemotingTransacctionServiceService is installed but, given it is lazy, it does not start. The EJB themselves are not registered with the transactions, it is just a matter of dependency of MSC services in the server. The only way to reproduce this bug is having pending XaSubordinateResources in the file system to be recovered without any app installed. The only way of having that is having a previous instance of the server gone bad and having the original application undeployed before the server restarts. [~ochaloup] I'm not talking about WFTC-62. It appears that this bug does not exist, on a discussion in our weekly call with [~tomekadamski] I explained to him that the resources were supposed to not be removed unless there was the recovery afterwards, and he told me he didn't wait long enough to certify that, so he is going to review that Jira at some point to see if it was a misunderstanding of the algorithm or if there is really a bug. I'm talking about the files not being removed because there is no actual recovery being performed, i.e., those files represent a non-existent resource in the other server. I'm investigating to see what to do with that. I'm submitting a patch soon for this, after a discussion with [~bstansberry2] the conclusion was that we should make RemotingServiceService active, vs keeping it lazy and adding a mechanism in wildfly-transaction-client that would create a service dependent on that service every time we needed to recover subordinate resources from the file system. > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on WFLY-12090: ----------------------------------------- Thanks for the update [~flavia.rainone], I am wondeirng why missing EJB components would prevent the recovery if you are able to start up RemotingTransactionServiceService is that not enough for the recovery propagation to take place? I don't think the EJB's themselves should be registered with the transactions. /cc [~ochaloup] [~mmusgrov] > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on WFLY-12090: ----------------------------------------- [~flavia.rainone] does have the subordinate resources list never being cleaned something to do with the https://issues.jboss.org/browse/WFTC-62 or not at all? > Unknown service name jboss.ejb and txn > -------------------------------------- > > Key: WFLY-12090 > URL: https://issues.jboss.org/browse/WFLY-12090 > Project: WildFly > Issue Type: Bug > Components: EJB, Transactions > Affects Versions: 17.0.0.Alpha1 > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 17.0.0.Beta1 > > > When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error: > {code} > 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201) > at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226) > at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770) > at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382) > Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429) > at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591) > Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4065) Update JavaParser from 3.10.2 to 3.13.10

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4065?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-4065: --------------------------------- Sprint: 2019 Week 20-22 (was: 2019 Week 23-25) > Update JavaParser from 3.10.2 to 3.13.10 > ---------------------------------------- > > Key: DROOLS-4065 > URL: https://issues.jboss.org/browse/DROOLS-4065 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4065) Update JavaParser from 3.10.2 to 3.13.10

by Luca Molteni (Jira)

[ https://issues.jboss.org/browse/DROOLS-4065?page=com.atlassian.jira.plugi... ] Luca Molteni updated DROOLS-4065: --------------------------------- Sprint: 2019 Week 23-25 > Update JavaParser from 3.10.2 to 3.13.10 > ---------------------------------------- > > Key: DROOLS-4065 > URL: https://issues.jboss.org/browse/DROOLS-4065 > Project: Drools > Issue Type: Enhancement > Reporter: Luca Molteni > Assignee: Luca Molteni > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4065) Update JavaParser from 3.10.2 to 3.13.10

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4065: ------------------------------------ Summary: Update JavaParser from 3.10.2 to 3.13.10 Key: DROOLS-4065 URL: https://issues.jboss.org/browse/DROOLS-4065 Project: Drools Issue Type: Enhancement Reporter: Luca Molteni Assignee: Luca Molteni -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4064) Improve keyboard usability in Test Scenario

by Daniele Zonca (Jira)

Daniele Zonca created DROOLS-4064: ------------------------------------- Summary: Improve keyboard usability in Test Scenario Key: DROOLS-4064 URL: https://issues.jboss.org/browse/DROOLS-4064 Project: Drools Issue Type: Enhancement Components: Scenario Simulation and Testing Reporter: Daniele Zonca Assignee: Daniele Zonca Implement additional keyboard navigation's path to cover this use case: "When I use TAB the next cell is highlighted but it's not in edit mode, so I have to press enter to enter in edit mode. If I press TAB twice, I lose the cell focus (my browser bring the focus on the address bar!) I expect the same behavior of google sheet." ([~dmarrazzo]) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2311) Drools Engine not able to load rules in spring-Boot project

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-2311?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2311: -------------------------------- Sprint: 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29, 2019 Week 20-22 (was: 2018 Week 05-06, 2018 Week 07-08, 2018 Week 09-10, 2018 Week 11-12, 2018 Week 13-14, 2018 Week 15-16, 2018 Week 17-18, 2018 Week 19-22, 2018 Week 23-24, 2018 Week 25-26, 2018 Week 27-29) > Drools Engine not able to load rules in spring-Boot project > ----------------------------------------------------------- > > Key: DROOLS-2311 > URL: https://issues.jboss.org/browse/DROOLS-2311 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Chandresh Mishra > Assignee: Mario Fusco > Priority: Major > Attachments: Drools-Issue.rar > > > am using the Drools 7.5.0-final in the spring Boot project. > I am working on a multi-module Gradle project. Rules and kmodule.xml is present in the sub-module project. This module is packaged as a Jar inside a fat spring boot Jar file. > I am building the container from the classpath. > KieContainer kContainer = kieService.newKieClasspathContainer(); > on server start-up (java -jar) it loads the Kmodule.xml and prints all the kbase and sessionName. > But when I fire rules it returns zero rules fired. > It works fine when I run as spring boot app from Eclipse. Please help. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4063) DMN Node Update is not reflected in Scenario

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4063: ----------------------------------- Summary: DMN Node Update is not reflected in Scenario Key: DROOLS-4063 URL: https://issues.jboss.org/browse/DROOLS-4063 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.23.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: constant.dmn The issue is when user do some updates to the DMN and recretae new Scenario for the same DMN. The scenario assumes the first verison of the DMN. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11890) Upgrade JGroups to 4.1.1.Final

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11890?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-11890: -------------------------------- Summary: Upgrade JGroups to 4.1.1.Final (was: Upgrade JGroups to 4.1.0.Final) > Upgrade JGroups to 4.1.1.Final > ------------------------------ > > Key: WFLY-11890 > URL: https://issues.jboss.org/browse/WFLY-11890 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 16.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Major > > Placeholder for now. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2019