May 2019 - jboss-jira - Jboss List Archives

[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] thanks for the fix for the WFTC-62. I would like to understand what is the relation of this issue (WFLY-12090) to the WFTC-64? Is it something the customer hits and makes issues? I mean I think the WFTC-64 is not an issue. For the full correct recovery it's expected that the remote server will be restarted with the same object store as it was before plus with the same node id as it has before the failure. >From the transaction consistency perspective it's not fully secure to remove the record as you lose the information about existence of some unfinished transaction on the remote side. I have in mind cases like (maybe we can discuss which one is real or not but still...) * the remote server fails, administrator starts another blank new server at the same address (as WFTC-64 mentions), recovery occurs, WFTC removes the record, administrator realizes he did not port `/data` directory, restarts the server once again with txn records and we have never recovered data here (_this situation expects an error of the administrator_) * the remote server fails, administrator starts another blank new server, recovery occurs, WFTC removes the record, administrator slowly migrates unfinished transactions to the newly started server, those migrated transactions won't be never recovered as the parent EAP node lost the information about them (_we were thinking about such option for the txn recovery management on OpenShift - even this idea was never implemented I think it's still feasible. It would be similar as migration of messages from a killed broker to an active one.) My PoV is that the records should be left untouched for some time (ie. for hours) until they are really deleted. The Narayana has For the sake of completeness, when remembering correctly these WFTC records - which we are talking about in WFTC-64 - are for orphan detection thus the transaction was defined to be rollback (WFTC-38, WFLY-10201). The records are not necessary if information about participant is saved in the Narayana transaction log and the transaction outcome was defined to be commit. > 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-4073) Scenario throw an error for columns bound to collection field

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4073: ----------------------------------- Summary: Scenario throw an error for columns bound to collection field Key: DROOLS-4073 URL: https://issues.jboss.org/browse/DROOLS-4073 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.23.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: Screenshot from 2019-05-23 14-40-23.png, collections.zip If the column is bound to a collection field and user tries to edit some data cell, an error is thrown. The issue was spotted during DROOLS-3855 review however not sure if that one is the root cause. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools

by Fabio Bonfante (Jira)

[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ] Fabio Bonfante commented on DROOLS-1540: ---------------------------------------- Thank's for the clarification. For the 2nd point, you're right I've the wrong perception of probabilities about how much this problem can happen ;-) > Drools does not work with spring-boot-devtools > ---------------------------------------------- > > Key: DROOLS-1540 > URL: https://issues.jboss.org/browse/DROOLS-1540 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final, 7.20.0.Final > Reporter: G Xiong > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.zip > > > Drools does work with spring-boot-devtools. > If you add in pom.xml the following, no rules will be fired in Drools. > <dependency> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-devtools</artifactId> > </dependency> > if you comment out this, then rules will be fired in Drools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name

by Edson Tirelli (Jira)

[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-3997: --------------------------------------- [~dadossan] can you keep me posted on the status of this please? > [DMN Designer] Included Model Name marshalling issues depending on imported model name > -------------------------------------------------------------------------------------- > > Key: DROOLS-3997 > URL: https://issues.jboss.org/browse/DROOLS-3997 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-05-10 08-20-54.png, Screenshot from 2019-05-10 08-28-42.png, connect-imported-error.log, connect-imported-node.webm, routes.zip > > > There is issue in marshalling, if the included model name contains *whitespace* character. In such case xml editor is opened instead of the dmn editor. See the attached picture and steps to reproduce for more details. > Issue spotted during review of DROOLS-3720 and DROOLS-3721. However it is probably not related. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1540) Drools does not work with spring-boot-devtools

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-1540?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1540: ------------------------------------- [~fabio.bonfante] As found by [~awilkinson] (thanks for it) the problem was caused by that additional droolsClassLoader referenced by our ProjectClassLoader. That (ugly) ack is only necessary when you run inside an OSGi container, but we were use it regardless. What I'm doing now is just limiting the scope of the ack only when you're effectively running inside OSGi, thus eliminating the cause of the problem with spring-boot-devtools when you aren't. As for your 2nd question we could in theory do what you wrote, but this will require some reflection and slow down the whole engine for something that is useless in 99.9% of cases, so I don't t think it would be a good idea. > Drools does not work with spring-boot-devtools > ---------------------------------------------- > > Key: DROOLS-1540 > URL: https://issues.jboss.org/browse/DROOLS-1540 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final, 7.20.0.Final > Reporter: G Xiong > Assignee: Mario Fusco > Priority: Critical > Attachments: complete.zip > > > Drools does work with spring-boot-devtools. > If you add in pom.xml the following, no rules will be fired in Drools. > <dependency> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-devtools</artifactId> > </dependency> > if you comment out this, then rules will be fired in Drools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4487) Migrate domain-management module to new MSC API

by Richard Opalka (Jira)

Richard Opalka created WFCORE-4487: -------------------------------------- Summary: Migrate domain-management module to new MSC API Key: WFCORE-4487 URL: https://issues.jboss.org/browse/WFCORE-4487 Project: WildFly Core Issue Type: Task Components: Server Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 9.0.0.CR1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12117) Upgrade jgroups-kubernetes to 1.0.10.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12117?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-12117: ---------------------------------- Description: Currently a placeholder for release containing fixes around CA parsing. (was: Currently a placeholder for release containing fixes around CA parsing/verification.) > Upgrade jgroups-kubernetes to 1.0.10.Final > ------------------------------------------ > > Key: WFLY-12117 > URL: https://issues.jboss.org/browse/WFLY-12117 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Currently a placeholder for release containing fixes around CA parsing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name

by Daniel José dos Santos (Jira)

[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ] Daniel José dos Santos commented on DROOLS-3997: ------------------------------------------------ At first doesn't look to be related, because the test you did is the basic test that I did too, but I'm checking. > [DMN Designer] Included Model Name marshalling issues depending on imported model name > -------------------------------------------------------------------------------------- > > Key: DROOLS-3997 > URL: https://issues.jboss.org/browse/DROOLS-3997 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.22.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2019-05-10 08-20-54.png, Screenshot from 2019-05-10 08-28-42.png, connect-imported-error.log, connect-imported-node.webm, routes.zip > > > There is issue in marshalling, if the included model name contains *whitespace* character. In such case xml editor is opened instead of the dmn editor. See the attached picture and steps to reproduce for more details. > Issue spotted during review of DROOLS-3720 and DROOLS-3721. However it is probably not related. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12117) Upgrade jgroups-kubernetes to 1.0.10.Final

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-12117: ------------------------------------- Summary: Upgrade jgroups-kubernetes to 1.0.10.Final Key: WFLY-12117 URL: https://issues.jboss.org/browse/WFLY-12117 Project: WildFly Issue Type: Component Upgrade Components: Clustering Reporter: Radoslav Husar Assignee: Radoslav Husar Currently a placeholder for release containing fixes around CA parsing/verification. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12113) Upgrade jgroups-kubernetes to 1.0.9.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12113?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-12113: ---------------------------------- Description: Resolves WFLY-12112. (was: e.g. resolves WFLY-12112. ) > Upgrade jgroups-kubernetes to 1.0.9.Final > ----------------------------------------- > > Key: WFLY-12113 > URL: https://issues.jboss.org/browse/WFLY-12113 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 16.0.0.Final, 17.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Resolves WFLY-12112. -- 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