[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka edited comment on WFLY-12317 at 8/19/19 10:38 AM:
--------------------------------------------------------------
Hi [~bmaxwell],
we might need your insight here.
What is going on? Change node-identifier model attribute definition from reload required to JVM restart.
The problem is this will get to 7.3.0 eventually. Strictly speaking such change in API can not be part of minor release.
Moreover following scenario is possible for a customer
# start a server
# change node-identifier
# reload
The change takes no effect here - it is also the failing test scenario in this Jira
However there are arguments to support the change:
* Narayana expects node-identifier to require JVM restart after it is changed - might be considered as a bug in model
* It is said nowhere that reload is required when node-identifier (no documentation,...) - info is available only in model description
WDYT?
was (Author: istraka):
Hi [~bmaxwell],
we might need your insight here.
What is going on? Change node-identifier model attribute definition from reload required to JVM restart.
The problem is this will get to 7.3.0 eventually. Strictly speaking such change in API can not be part of minor release.
Moreover following scenario is possible for a customer
# start a server
# change node-identifier
# reload
The change takes no effect here - it is also the failing test scenario in this Jira
However there are arguments to support the change:
* Narayana is expecting node-identifier to require JVM restart after change
* It is said nowhere that reload is required when node-identifier (no documentation,...) - info is available only in model description
WDYT?
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JBEE-213) Update jacc to use jboss parent
by Darran Lofthouse (Jira)
Darran Lofthouse created JBEE-213:
-------------------------------------
Summary: Update jacc to use jboss parent
Key: JBEE-213
URL: https://issues.jboss.org/browse/JBEE-213
Project: JBoss Enterprise Spec APIs
Issue Type: Task
Components: jboss-jacc-api
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
This is required to be able to publish artefacts to the JBoss repo.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka commented on WFLY-12317:
------------------------------------
Hi [~bmaxwell],
we might need your insight here.
What is going on? Change node-identifier model attribute definition from reload required to JVM restart.
The problem is this will get to 7.3.0 eventually. Strictly speaking such change in API can not be part of minor release.
Moreover following scenario is possible for a customer
# start a server
# change node-identifier
# reload
The change takes no effect here - it is also the failing test scenario in this Jira
However there are arguments to support the change:
* Narayana is expecting node-identifier to require JVM restart after change
* It is said nowhere that reload is required when node-identifier (no documentation,...) - info is available only in model description
WDYT?
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ivan Straka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ivan Straka edited comment on WFLY-12317 at 8/19/19 10:25 AM:
--------------------------------------------------------------
Hi [~bmaxwell],
we might need your insight here.
What is going on? Change node-identifier model attribute definition from reload required to JVM restart.
The problem is this will get to 7.3.0 eventually. Strictly speaking such change in API can not be part of minor release.
Moreover following scenario is possible for a customer
# start a server
# change node-identifier
# reload
The change takes no effect here - it is also the failing test scenario in this Jira
However there are arguments to support the change:
* Narayana is expecting node-identifier to require JVM restart after change
* It is said nowhere that reload is required when node-identifier (no documentation,...) - info is available only in model description
WDYT?
was (Author: istraka):
Hi [~bmaxwell],
we might need your insight here.
What is going on? Change node-identifier model attribute definition from reload required to JVM restart.
The problem is this will get to 7.3.0 eventually. Strictly speaking such change in API can not be part of minor release.
Moreover following scenario is possible for a customer
# start a server
# change node-identifier
# reload
The change takes no effect here - it is also the failing test scenario in this Jira
However there are arguments to support the change:
* Narayana is expecting node-identifier to require JVM restart after change
* It is said nowhere that reload is required when node-identifier (no documentation,...) - info is available only in model description
WDYT?
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-177) Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-177?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFWIP-177:
-------------------------------
Description:
Use case is providing settings.xml as secret. I wonder if this could be some ubi7 file permission issue.
{code}
Receiving source from STDIN as archive ...
Using docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD... as the s2i builder image
error: Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
ERROR: Error occurred during injecting "/var/run/secrets/openshift.io/build/test-secret" to "/etc/test-secret": Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
error: build error: non-zero (13) exit code from docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
{code}
{code:yaml|title=BuildConfig}
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
creationTimestamp: '2019-08-19T13:20:41Z'
name: sti-secret-settings
namespace: mchoma
resourceVersion: '1345248'
selfLink: >-
/apis/build.openshift.io/v1/namespaces/mchoma/buildconfigs/sti-secret-settings
uid: 249b6a94-c284-11e9-b93c-fa163e9a0fb6
spec:
failedBuildsHistoryLimit: 5
nodeSelector: {}
output:
to:
kind: ImageStreamTag
name: 'sti-secret-settings:latest'
postCommit: {}
resources: {}
runPolicy: Serial
source:
binary: {}
secrets:
- destinationDir: /etc/test-secret
secret:
name: test-secret
type: Binary
strategy:
sourceStrategy:
env:
- name: MAVEN_ARGS
value: install -s /etc/test-secret/settings.xml
from:
kind: DockerImage
name: >-
docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
incremental: false
type: Source
successfulBuildsHistoryLimit: 5
triggers:
- generic:
allowEnv: true
secret: secret101
type: Generic
status:
lastVersion: 1
{code}
{code:yaml|title=Secret}
apiVersion: v1
data:
settings.xml: >-
PHNldHRpbmdzPgogPHByb2ZpbGVzPiAgPHByb2ZpbGU+ICAgICA8aWQ+dGVzdDwvaWQ+ICAgICA8cmVwb3NpdG9yaWVzPiAgICAgICA8cmVwb3NpdG9yeT4gICAgICAgICA8aWQ+RUFQLTc8L2lkPiAgICAgICAgIDxuYW1lPkVBUDcgcmVwbzwvbmFtZT4gICAgICAgICA8dXJsPmh0dHBzOi8vbWF2ZW4ucmVwb3NpdG9yeS5yZWRoYXQuY29tL2dhLzwvdXJsPiAgICAgICA8L3JlcG9zaXRvcnk+ICAgICA8L3JlcG9zaXRvcmllcz4gICA8L3Byb2ZpbGU+ICA8L3Byb2ZpbGVzPiAgPGFjdGl2ZVByb2ZpbGVzPiAgICA8YWN0aXZlUHJvZmlsZT50ZXN0PC9hY3RpdmVQcm9maWxlPiA8L2FjdGl2ZVByb2ZpbGVzPiA8L3NldHRpbmdzPg==
kind: Secret
metadata:
creationTimestamp: '2019-08-19T13:20:41Z'
name: test-secret
namespace: mchoma
resourceVersion: '1345244'
selfLink: /api/v1/namespaces/mchoma/secrets/test-secret
uid: 246843e8-c284-11e9-b93c-fa163e9a0fb6
type: Opaque
{code}
was:
Use case is providing settings.xml as secret. I wonder if this could be some ubi7 file permission issue.
{code}
Receiving source from STDIN as archive ...
Using docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD... as the s2i builder image
error: Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
ERROR: Error occurred during injecting "/var/run/secrets/openshift.io/build/test-secret" to "/etc/test-secret": Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
error: build error: non-zero (13) exit code from docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
{code}
{code:yaml|title=BuildConfig}
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
creationTimestamp: '2019-08-19T13:20:41Z'
name: sti-secret-settings
namespace: mchoma
resourceVersion: '1345248'
selfLink: >-
/apis/build.openshift.io/v1/namespaces/mchoma/buildconfigs/sti-secret-settings
uid: 249b6a94-c284-11e9-b93c-fa163e9a0fb6
spec:
failedBuildsHistoryLimit: 5
nodeSelector: {}
output:
to:
kind: ImageStreamTag
name: 'sti-secret-settings:latest'
postCommit: {}
resources: {}
runPolicy: Serial
source:
binary: {}
secrets:
- destinationDir: /etc/test-secret
secret:
name: test-secret
type: Binary
strategy:
sourceStrategy:
env:
- name: MAVEN_ARGS
value: install -s /etc/test-secret/settings.xml
from:
kind: DockerImage
name: >-
docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
incremental: false
type: Source
successfulBuildsHistoryLimit: 5
triggers:
- generic:
allowEnv: true
secret: secret101
type: Generic
status:
lastVersion: 1
{code}
> Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-177
> URL: https://issues.jboss.org/browse/WFWIP-177
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Ken Wills
> Priority: Major
>
> Use case is providing settings.xml as secret. I wonder if this could be some ubi7 file permission issue.
> {code}
> Receiving source from STDIN as archive ...
> Using docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD... as the s2i builder image
> error: Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
> ERROR: Error occurred during injecting "/var/run/secrets/openshift.io/build/test-secret" to "/etc/test-secret": Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
> error: build error: non-zero (13) exit code from docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
> {code}
> {code:yaml|title=BuildConfig}
> apiVersion: build.openshift.io/v1
> kind: BuildConfig
> metadata:
> creationTimestamp: '2019-08-19T13:20:41Z'
> name: sti-secret-settings
> namespace: mchoma
> resourceVersion: '1345248'
> selfLink: >-
> /apis/build.openshift.io/v1/namespaces/mchoma/buildconfigs/sti-secret-settings
> uid: 249b6a94-c284-11e9-b93c-fa163e9a0fb6
> spec:
> failedBuildsHistoryLimit: 5
> nodeSelector: {}
> output:
> to:
> kind: ImageStreamTag
> name: 'sti-secret-settings:latest'
> postCommit: {}
> resources: {}
> runPolicy: Serial
> source:
> binary: {}
> secrets:
> - destinationDir: /etc/test-secret
> secret:
> name: test-secret
> type: Binary
> strategy:
> sourceStrategy:
> env:
> - name: MAVEN_ARGS
> value: install -s /etc/test-secret/settings.xml
> from:
> kind: DockerImage
> name: >-
> docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
> incremental: false
> type: Source
> successfulBuildsHistoryLimit: 5
> triggers:
> - generic:
> allowEnv: true
> secret: secret101
> type: Generic
> status:
> lastVersion: 1
> {code}
> {code:yaml|title=Secret}
> apiVersion: v1
> data:
> settings.xml: >-
> PHNldHRpbmdzPgogPHByb2ZpbGVzPiAgPHByb2ZpbGU+ICAgICA8aWQ+dGVzdDwvaWQ+ICAgICA8cmVwb3NpdG9yaWVzPiAgICAgICA8cmVwb3NpdG9yeT4gICAgICAgICA8aWQ+RUFQLTc8L2lkPiAgICAgICAgIDxuYW1lPkVBUDcgcmVwbzwvbmFtZT4gICAgICAgICA8dXJsPmh0dHBzOi8vbWF2ZW4ucmVwb3NpdG9yeS5yZWRoYXQuY29tL2dhLzwvdXJsPiAgICAgICA8L3JlcG9zaXRvcnk+ICAgICA8L3JlcG9zaXRvcmllcz4gICA8L3Byb2ZpbGU+ICA8L3Byb2ZpbGVzPiAgPGFjdGl2ZVByb2ZpbGVzPiAgICA8YWN0aXZlUHJvZmlsZT50ZXN0PC9hY3RpdmVQcm9maWxlPiA8L2FjdGl2ZVByb2ZpbGVzPiA8L3NldHRpbmdzPg==
> kind: Secret
> metadata:
> creationTimestamp: '2019-08-19T13:20:41Z'
> name: test-secret
> namespace: mchoma
> resourceVersion: '1345244'
> selfLink: /api/v1/namespaces/mchoma/secrets/test-secret
> uid: 246843e8-c284-11e9-b93c-fa163e9a0fb6
> type: Opaque
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-177) Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink
by Martin Choma (Jira)
Martin Choma created WFWIP-177:
----------------------------------
Summary: Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink
Key: WFWIP-177
URL: https://issues.jboss.org/browse/WFWIP-177
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Ken Wills
Use case is providing settings.xml as secret. I wonder if this could be some ubi7 file permission issue.
{code}
Receiving source from STDIN as archive ...
Using docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD... as the s2i builder image
error: Uploading to container failed: Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
ERROR: Error occurred during injecting "/var/run/secrets/openshift.io/build/test-secret" to "/etc/test-secret": Error response from daemon: Error processing tar file(exit status 1): invalid symlink "/etc/test-secret/..data" -> "..2019_08_19_13_20_57.538692366"
error: build error: non-zero (13) exit code from docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
{code}
{code:yaml|title=BuildConfig}
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
creationTimestamp: '2019-08-19T13:20:41Z'
name: sti-secret-settings
namespace: mchoma
resourceVersion: '1345248'
selfLink: >-
/apis/build.openshift.io/v1/namespaces/mchoma/buildconfigs/sti-secret-settings
uid: 249b6a94-c284-11e9-b93c-fa163e9a0fb6
spec:
failedBuildsHistoryLimit: 5
nodeSelector: {}
output:
to:
kind: ImageStreamTag
name: 'sti-secret-settings:latest'
postCommit: {}
resources: {}
runPolicy: Serial
source:
binary: {}
secrets:
- destinationDir: /etc/test-secret
secret:
name: test-secret
type: Binary
strategy:
sourceStrategy:
env:
- name: MAVEN_ARGS
value: install -s /etc/test-secret/settings.xml
from:
kind: DockerImage
name: >-
docker-registry.engineering.redhat.com/kwills/eap73-openshift-rhel7:CLOUD...
incremental: false
type: Source
successfulBuildsHistoryLimit: 5
triggers:
- generic:
allowEnv: true
secret: secret101
type: Generic
status:
lastVersion: 1
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reassigned WFLY-12317:
---------------------------------------
Assignee: Thomas Jenkinson (was: Ondrej Chaloupka)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Thomas Jenkinson
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reassigned WFLY-12317:
---------------------------------------
Assignee: Ondrej Chaloupka (was: Thomas Jenkinson)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson reassigned WFLY-12317:
---------------------------------------
Assignee: Ondrej Chaloupka (was: Michael Musgrove)
> Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-12317
> URL: https://issues.jboss.org/browse/WFLY-12317
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Final
> Reporter: Ivan Straka
> Assignee: Ondrej Chaloupka
> Priority: Critical
> Attachments: server1_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log, server2_TxDifferentNodeCrashRecoveryTestCase_prepareHalt_jta_server.log
>
>
> We have following test scenario (3 servers) that fails:
> # node-identifier of server1, 2 & 3 is set to 'vkcd', 'FdOu' and 'GocW' (ts.jbosstsX.node.identifier property)
> # server2 is started, node-identifier is set to txdifferentnodeid and server2 is stopped
> # server1 is started, node-identifier is set to txdifferentnodeid and server1 is reloaded
> # server3 is running
> # client call an EJB bean (where a transaction is started) on the server1
> # the EJB sends JMS message to the server3 (broker)
> # the EJB enlists dummy xa resource
> # during 2PC the Server1 is halted when prepare on dummy xa resource is invoked
> # we move server1 object store directory to the server2
> # server2 is started
> # the server2 is expected to rollback whole transaction
> Transaction is unfinished because server2 has not performed rollback.
> {code:java}
> prepareHalt(org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase) Time elapsed: 810.354 sec <<< FAILURE!
> java.lang.AssertionError: Some unfinished xids on messaging server - expected 0 but was 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.checkAfterTestExecution(TxDifferentNodeCrashRecoveryTestCase.java:792)
> at org.jboss.as.test.jbossts.crashrec.differentnode.test.TxDifferentNodeCrashRecoveryTestCase.prepareHalt(TxDifferentNodeCrashRecoveryTestCase.java:565)
> {code}
> In the beginning servers' node-identifier are set to some value (lets say A,B,C). Before test execution node-identifier of server1 and server2 is set to the same value, let's say X.
> I see in logs that the transaction's node_name is set to the old value (vkcd vs txdifferentnodeid in the example below) on server1. Thus the server2 has not performed rollback.
> See node_name
> Server1:
> {code:java}
> 2019-07-22 17:40:54,616 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-5) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:41:11,931 TRACE [com.arjuna.ats.jta] (default task-2) XAResourceRecord.XAResourceRecord ( < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8 >, XAResourceWrapperImpl@4158c7ec[xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper(a)4a21a45f pad=false overrideRmValue=null productName=ActiveMQ Artemis productVersion=2.0 jndiName=java:/JmsXA NodeId:05b492ae-ac97-11e9-a446-2016b912eaa8] ), record id=0:ffff0a2804ed:26165251:5d35d902:47
> {code}
> Server2:
>
> {code:java}
> 2019-07-22 17:41:15,397 DEBUG [com.arjuna.ats.jta] (MSC service thread 1-3) Setting up node identifiers '[txdifferentnodeid]' for which recovery will be performed
> {code}
> {code:java}
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=32, bqual_length=36, tx_uid=0:ffff0a2804ed:26165251:5d35d902:3c, node_name=vkcd, branch_uid=0:ffff0a2804ed:26165251:5d35d902:46, subordinatenodename=null, eis_name=forgot eis name for: 1 > is vkcd
> 2019-07-22 17:43:56,062 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ABSTAIN
> {code}
> *When does the scenario pass*
> When I run the TS with
> {code:java}
> -Dts.jbossts1.node.identifier=txdifferentnodeid -Dts.jbossts2.node.identifier=txdifferentnodeid
> {code}
> the test passes (old and new node-identifier on both servers are same)
> When step 3 slightly differs:
> When restart is performed instead of reload op.
> Server1 is reloaded. If it is restarted, node name is set correctly to txdifferentnodeid
> *tldr;*
> The problem is that server1 set TX node name to old value after node identifier is changed and server is reloaded. If the server is restarted, everything is OK.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (DROOLS-4258) DMN UX - overlay information about a single scenario run
by Margot Menestrot (Jira)
[ https://issues.jboss.org/browse/DROOLS-4258?page=com.atlassian.jira.plugi... ]
Margot Menestrot commented on DROOLS-4258:
------------------------------------------
*Prototype: * https://marvelapp.com/1hd59jjg/screen/60430742
_Steps:_
1. Click on "Analyze scenario" button in coverage report
2. user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value)
3. User then clicks on actual node, then edit button, to open executed decision table to see which row has been evaluated
> DMN UX - overlay information about a single scenario run
> --------------------------------------------------------
>
> Key: DROOLS-4258
> URL: https://issues.jboss.org/browse/DROOLS-4258
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Margot Menestrot
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze the execution of a *single scenario* in the DMN model
> - user clicks on "a link" related to the scenario to analyze
> - user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value (from the scenario) and to open an executed decision table to see which row has been evaluated
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months