[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously
by Ian Rodgers (Jira)
[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ]
Ian Rodgers edited comment on WFLY-11535 at 2/8/19 8:09 AM:
------------------------------------------------------------
Have successfully recreated this issue, with Keycloak taken out of the equation.
We are now using the Wildfly 14 official docker image.
Attached is the latest standalone-ha file, the only change being a tweak to use JDBC_PING within JGroups as per our original config. It is the standalone file
If the 4 instances are started in a staggered fashion then they correctly form one cluster of 4.
If they are started simultaneously then they form 4 individual clusters.
This was not an issue when we had Keycloak 4.5 running on Wildfly 13.
Incidentally we noticed there was a modcluster definition in the Wildfly distribution standalone file, but not our original Keycloak standalone. We don't think it is necessary because we are using tcp rather than multicast. In any case we get the same outcome with and without modcluster present.
was (Author: ianrodgers):
Have successfully recreated this issue, with Keycloak taken out of the equation.
We are now using the Wildfly 14 official docker image.
Attached is the latest standalone-ha file, the only change being a tweak to use JDBC_PING within JGroups as per our original config.
If the 4 instances are started in a staggered fashion then they correctly form one cluster of 4.
If they are started simultaneously then they form 4 individual clusters.
This was not an issue when we had Keycloak 4.5 running on Wildfly 13.
Incidentally we noticed there was a modcluster definition in the standalone file and thought that this might be connected to the problem. We get the same outcome with and without modcluster present.
> Cluster fails to merge if instances started simultaneously
> ----------------------------------------------------------
>
> Key: WFLY-11535
> URL: https://issues.jboss.org/browse/WFLY-11535
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster
> Reporter: Ian Rodgers
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: standalone-ha.xml, standalone-ha.xml
>
>
> Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).
> We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join.
> This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix.
> On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (DROOLS-3616) [DMN Designer] Literal expression name and data type popup missing
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3616?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3616:
--------------------------------
Description:
If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
h2. Manual PR Check (/)
Other expression are not affected
- LE
- Relation
- Context
- DT
- Invocation
- Function
was:
If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
h2. Manual PR Check
Other expression are not affected
- LE
- Relation
- Context
- DT
- Invocation
- Function
> [DMN Designer] Literal expression name and data type popup missing
> ------------------------------------------------------------------
>
> Key: DROOLS-3616
> URL: https://issues.jboss.org/browse/DROOLS-3616
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-02-08 10-01-34.png
>
>
> If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
> h2. Manual PR Check (/)
> Other expression are not affected
> - LE
> - Relation
> - Context
> - DT
> - Invocation
> - Function
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously
by Ian Rodgers (Jira)
[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ]
Ian Rodgers commented on WFLY-11535:
------------------------------------
Have successfully recreated this issue, with Keycloak taken out of the equation.
We are now using the Wildfly 14 official docker image.
Attached is the latest standalone-ha file, the only change being a tweak to use JDBC_PING within JGroups as per our original config.
If the 4 instances are started in a staggered fashion then they correctly form one cluster of 4.
If they are started simultaneously then they form 4 individual clusters.
This was not an issue when we had Keycloak 4.5 running on Wildfly 13.
Incidentally we noticed there was a modcluster definition in the standalone file and thought that this might be connected to the problem. We get the same outcome with and without modcluster present.
> Cluster fails to merge if instances started simultaneously
> ----------------------------------------------------------
>
> Key: WFLY-11535
> URL: https://issues.jboss.org/browse/WFLY-11535
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster
> Reporter: Ian Rodgers
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: standalone-ha.xml, standalone-ha.xml
>
>
> Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).
> We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join.
> This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix.
> On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (DROOLS-3616) [DMN Designer] Literal expression name and data type popup missing
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3616?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3616:
--------------------------------
Description:
If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
h2. Manual PR Check
Other expression are not affected
- LE
- Relation
- Context
- DT
- Invocation
- Function
was:If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
> [DMN Designer] Literal expression name and data type popup missing
> ------------------------------------------------------------------
>
> Key: DROOLS-3616
> URL: https://issues.jboss.org/browse/DROOLS-3616
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-02-08 10-01-34.png
>
>
> If user tries to change name and data type of root Literal expression, the **Name && Data Type** popup is missing. Other expression types works fine.
> h2. Manual PR Check
> Other expression are not affected
> - LE
> - Relation
> - Context
> - DT
> - Invocation
> - Function
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
Kabir Khan edited comment on WFLY-11214 at 2/8/19 7:30 AM:
-----------------------------------------------------------
As Agroal is currently TP, I am lowering the priority of this to Critical CC [~msvehla]
was (Author: kabirkhan):
As Agroal is currently TP, I am lowering the priority of this to Critical
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Fix For: 16.0.0.Beta1
>
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
Kabir Khan commented on WFLY-11214:
-----------------------------------
As Agroal is currently TP, I am lowering the priority of this to Critical
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Fix For: 16.0.0.Beta1
>
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by Kabir Khan (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
Kabir Khan updated WFLY-11214:
------------------------------
Priority: Critical (was: Blocker)
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Fix For: 16.0.0.Beta1
>
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (DROOLS-3612) [DMN Designer] Java Function is context after reopening
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3612?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3612:
-------------------------------------
Issue from comment above resolved by new commits in pr.
> [DMN Designer] Java Function is context after reopening
> -------------------------------------------------------
>
> Key: DROOLS-3612
> URL: https://issues.jboss.org/browse/DROOLS-3612
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2019-02-07 09-37-09.png, Screenshot from 2019-02-07 09-37-27.png, after.png, before.png
>
>
> Spotted during DROOLS-2262 review, however probably it is not related.
> If user save and reopen expression that is java function, the designer renders it as context expression after reopening. See the attached screenshots, there is unexpected *result* row after reopening.
> h2. Manual PR check
> - Save and reopen BKM, with java function (/)
> - Save and reopen BKM, with PMML function (/)
> - Save and reopen BKM, with feel function (/)
> - Save and reopen Decision, with java function (/)
> - Save and reopen Decision, with PMML function (/)
> - Save and reopen Decision, with feel function (/)
> - Save and reopen Decision, with context (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (DROOLS-3612) [DMN Designer] Java Function is context after reopening
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3612?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3612:
--------------------------------
Description:
Spotted during DROOLS-2262 review, however probably it is not related.
If user save and reopen expression that is java function, the designer renders it as context expression after reopening. See the attached screenshots, there is unexpected *result* row after reopening.
h2. Manual PR check
- Save and reopen BKM, with java function (/)
- Save and reopen BKM, with PMML function (/)
- Save and reopen BKM, with feel function (/)
- Save and reopen Decision, with java function (/)
- Save and reopen Decision, with PMML function (/)
- Save and reopen Decision, with feel function (/)
- Save and reopen Decision, with context (/)
was:
Spotted during DROOLS-2262 review, however probably it is not related.
If user save and reopen expression that is java function, the designer renders it as context expression after reopening. See the attached screenshots, there is unexpected *result* row after reopening.
h2. Manual PR check
- Save and reopen BKM, with java function (/)
- Save and reopen BKM, with PMML function (/)
- Save and reopen BKM, with feel function (x)
- Save and reopen Decision, with java function (/)
- Save and reopen Decision, with PMML function (/)
- Save and reopen Decision, with feel function (x)
- Save and reopen Decision, with context (/)
> [DMN Designer] Java Function is context after reopening
> -------------------------------------------------------
>
> Key: DROOLS-3612
> URL: https://issues.jboss.org/browse/DROOLS-3612
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2019-02-07 09-37-09.png, Screenshot from 2019-02-07 09-37-27.png, after.png, before.png
>
>
> Spotted during DROOLS-2262 review, however probably it is not related.
> If user save and reopen expression that is java function, the designer renders it as context expression after reopening. See the attached screenshots, there is unexpected *result* row after reopening.
> h2. Manual PR check
> - Save and reopen BKM, with java function (/)
> - Save and reopen BKM, with PMML function (/)
> - Save and reopen BKM, with feel function (/)
> - Save and reopen Decision, with java function (/)
> - Save and reopen Decision, with PMML function (/)
> - Save and reopen Decision, with feel function (/)
> - Save and reopen Decision, with context (/)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFLY-11535) Cluster fails to merge if instances started simultaneously
by Ian Rodgers (Jira)
[ https://issues.jboss.org/browse/WFLY-11535?page=com.atlassian.jira.plugin... ]
Ian Rodgers updated WFLY-11535:
-------------------------------
Attachment: standalone-ha.xml
> Cluster fails to merge if instances started simultaneously
> ----------------------------------------------------------
>
> Key: WFLY-11535
> URL: https://issues.jboss.org/browse/WFLY-11535
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Environment: Keycloak 4.6.0 official docker image, AWS ECS cluster
> Reporter: Ian Rodgers
> Assignee: Paul Ferraro
> Priority: Major
> Attachments: standalone-ha.xml, standalone-ha.xml
>
>
> Our Keycloak docker cluster has four instances, clustered using Jgroups/Infinispan as per the standalone-ha.xml. If you start them all simultaneously the "Receive new cluster" logs indicate four separate clusters, each with a single member. They never get merged into the proper single cluster of four members. It seems to be the merging that has changed. The application then fails (we are not using sticky sessions, and each member is ignorant of the sessions on the other members).
> We can only start the cluster by first starting one instance, then when it is running, starting the other three. The logs then indicate the creation of a single cluster which subsequent instances join.
> This is consistent behaviour, and when we revert back to v.4.5.0, the issue goes away, Unfortunately we need 4.6.0 for an important fix.
> On 4.5.0 we get the message "Received new, MERGED cluster view for channel ejb: MergeView::" when it detects a number of subgroups to merge. This never appears in 4.6.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months