[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Jaikiran Pai commented on WFCORE-4532:
--------------------------------------
FWIW - the JDK team have reverted back the "stateless ssl session" behaviour to what it was in previous versions of Java, by changing the default value of a system property. The recent EA release of JDK 13, build 31 seems to now work fine for these above test cases (of course after removing the Java 13 Assume.assumeFalse from those tests). I only tested it for 2-3 test cases noted in this JIRA.
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Priority: Critical
> Labels: jdk13
>
> Latest Open JDK 13 Early Access 25 introduced six new regressions in our test suites.
> Failing tests in WILDFLY-CORE are:
> * wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Failing tests in WILDFLY are:
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-3953) DMN UX - overlay validation error reporting
by Amy Glass (Jira)
[ https://issues.jboss.org/browse/DROOLS-3953?page=com.atlassian.jira.plugi... ]
Amy Glass reassigned DROOLS-3953:
---------------------------------
Assignee: Margot Menestrot (was: Tao Zhu)
> DMN UX - overlay validation error reporting
> -------------------------------------------
>
> Key: DROOLS-3953
> URL: https://issues.jboss.org/browse/DROOLS-3953
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Margot Menestrot
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
> Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-different kinds2.png, Error reporting after test run-popup.png, Error reporting after test run-popup.png, Error reporting after test run.png, ut.png, ux-decision button.png, ux-decision table.png
>
>
> As user during DMN model editing, I want to see validation errors on the model in case of wrong FEEL expression or invalid decision table.
> I want to see this kind of errors in the decisions and at diagram level.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Martin Stefanko updated JBJCA-1389:
-----------------------------------
Labels: downstream_dependency (was: )
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Assignee: Tomas Hofman
> Priority: Major
> Labels: downstream_dependency
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
> The NPE obscures the usage issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4440) Changes made via CLI in static-discovery are not reflected in host.xml
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/WFCORE-4440?page=com.atlassian.jira.plugi... ]
Martin Stefanko updated WFCORE-4440:
------------------------------------
Labels: downstream_dependency (was: )
> Changes made via CLI in static-discovery are not reflected in host.xml
> ----------------------------------------------------------------------
>
> Key: WFCORE-4440
> URL: https://issues.jboss.org/browse/WFCORE-4440
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 8.0.0.Final, 9.0.0.Beta3
> Reporter: Brian Stansberry
> Assignee: Teresa Miyar Gil
> Priority: Major
> Labels: downstream_dependency
> Fix For: 10.0.0.Beta1
>
>
> The value from this operation is not persisted in the host xml file, nor is it reflected in a read-resource response:
> /host=slave/core-service=discovery-options/static-discovery=primary:write-attribute(name=port,value=9999)
> It also doesn't put the HC in reload-required state.
> This works:
> /host=slave/core-service=discovery-options:write-attribute(name=options,value=[{static-discovery={name=primary,protocol="${jboss.domain.master.protocol:remote+http}",host="${jboss.domain.master.address}",port=9999}}]
> The /host=slave/core-service=discovery-options/static-discovery=* resources are meant to be a kind of alias for elements in that 'options' list to make it easier to manipulate the details. But that linkage has a bug. (Probably several.)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Michael Musgrove (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Michael Musgrove edited comment on WFLY-12317 at 7/29/19 7:01 AM:
------------------------------------------------------------------
[~ochaloup] yes it you want to a look that would be useful. [~istraka] reports that he test does a reload not a reboot
> 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: Michael Musgrove
> 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, 10 months
[JBoss JIRA] (WFLY-12317) Using JTA transaction's node_name attribute is set to an old value after node-identifier is changed
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12317?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFLY-12317:
-----------------------------------------
[~mmusgrov] ok, I see. Then the main failure is the attribute change is not defined as {{RESTART_JVM}} needed. Per design the {{:reload}} is not sufficient. Despite that it's just strange that it worked with reload with WFLY16. I will try to take a look.
> 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: Michael Musgrove
> 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, 10 months
[JBoss JIRA] (SWSQE-853) Make changes in kiali deployment permanent
by Filip Brychta (Jira)
Filip Brychta created SWSQE-853:
-----------------------------------
Summary: Make changes in kiali deployment permanent
Key: SWSQE-853
URL: https://issues.jboss.org/browse/SWSQE-853
Project: Kiali QE
Issue Type: Sub-task
Reporter: Filip Brychta
Assignee: Filip Brychta
We were using patching to update kiali deployment to pass correct parameters but it was overwritten by kiali operator after each reconciliation. We need to make those changes survive reconciliation.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 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 7/29/19 6:26 AM:
-------------------------------------------------------------
[~mmusgrov] yes, reload operation is performed. When I perform reboot op, test pass. However the original scenario passes with WF16.
was (Author: istraka):
[~mmusgrov] yes, reload is done. When I do reboot, test pass. However the original scenario passes with WF16.
> 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: Michael Musgrove
> 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, 10 months