[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:
-----------------------------------------
Just to point out that by default Narayana does not expire any transactions:
https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/narayana-jts-id...
You need to enable that behaviour and to be aware of what you are doing when you do that.
> 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
[JBoss JIRA] (WFLY-12118) kubernetes.KUBE_PING using token does not verify CA and defaults to insecure stream
by Radoslav Husar (Jira)
Radoslav Husar created WFLY-12118:
-------------------------------------
Summary: kubernetes.KUBE_PING using token does not verify CA and defaults to insecure stream
Key: WFLY-12118
URL: https://issues.jboss.org/browse/WFLY-12118
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 17.0.0.Alpha1, 16.0.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
The recommendation is to do verify is file is available:
{quote}If available, a certificate bundle is placed into the filesystem tree of each container at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, and should be used to verify the serving certificate of the apiserver.{quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12118) kubernetes.KUBE_PING using token auth does not verify CA and defaults to insecure stream
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12118?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12118:
----------------------------------
Summary: kubernetes.KUBE_PING using token auth does not verify CA and defaults to insecure stream (was: kubernetes.KUBE_PING using token does not verify CA and defaults to insecure stream)
> kubernetes.KUBE_PING using token auth does not verify CA and defaults to insecure stream
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-12118
> URL: https://issues.jboss.org/browse/WFLY-12118
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 16.0.0.Final, 17.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> The recommendation is to do verify is file is available:
> {quote}If available, a certificate bundle is placed into the filesystem tree of each container at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt, and should be used to verify the serving certificate of the apiserver.{quote}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3997:
-------------------------------------
[~tirelli] [~dadossan] there is a good progress. I am now able to create the DMN while import alias has whitespace, however I am not able to test it using Scenarios. See the attached project [^routes-v2.zip] . Import it to workbench and click the Test button. The [^routes-v2.log] erro will appear in server log.
> [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-v2.log, routes-v2.zip, 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
[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3997:
--------------------------------
Attachment: routes-v2.zip
routes-v2.log
> [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-v2.log, routes-v2.zip, 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
[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 edited comment on WFLY-12090 at 5/23/19 8:59 AM:
------------------------------------------------------------------
[~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 recovery `expiryScanInterval` which defines the time (by default 12h) after which similar records are removed.
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.
was (Author: ochaloup):
[~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