[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2092:
------------------------------------
This scenario happened several times in our lab. We no longer see the issue as it was worked around with staggering responses for all of the "bulk response" messages (ie: view change, etc). However, I believe that this could happen again with a marge enough network and low enough bandwidth. In other words my ounce of prevention is working out, be the pound of cure would still be the best solution. I had created a unit test as well and hound the same results. We also ran into partial scenarios where the consistency checker was being run by one functioning coordinator, but other, non-functioning coordinators would not respond to the merge and/or the coordinator running the checker did not think it should be merge leader. In all cases the issue is complicated by the fact that none of the non-coordinators will trust a new coordinator that is not a member of their group.
I believe that a solution will involve the 2nd rank host (and maybe the 3rd?) running a checker to see if the coordinator's viewInfo shows the coordinator as thinking it is, in fact, a coordinator.
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7094) Too much code duplication between AddStepHandler and BoottimeAddStepHandler
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7094:
----------------------------------
Summary: Too much code duplication between AddStepHandler and BoottimeAddStepHandler
Key: WFLY-7094
URL: https://issues.jboss.org/browse/WFLY-7094
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
As the logic in AddStepHandler grows, it needs to be duplicated by BoottimeAddStepHandler, since BoottimeAddStepHandler extends AbstractBoottimeAddStepHandler. To simplify maintenance of these classes, we should have BoottimeAddStepHandler extend AddStepHandler instead, and reimplement the logic from AbstractBoottimeAddStepHandler.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2092:
--------------------------------
The unit test in MergeTest5
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2092 at 9/12/16 11:58 AM:
----------------------------------------------------------
[~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing?
I never thought of such a scenario, but of course I need to address it...
The first problem is that since nobody is the coordinator or its local view, nobody will start the view consistency checker task which checks for inconsistent views.
The second issue is that even if a view consistency check task was started (e.g. via JMX), it would run a similar check as the one above and never become the _merge leader_!
was (Author: belaban):
[~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing?
I never thought of such a scenario, but of course I need to address it...
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2092:
--------------------------------
[~ndillman] How did you arrive at this scenario? Did this happen in real life, or did you bring the system into this state on purpose, e.g. in testing?
I never thought of such a scenario, but of course I need to address it...
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2092) MERGE3: merge never happens
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2092?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2092:
--------------------------------
So no member has a view in which it is the actual coordinator... We can probably shorten this to:
{noformat}
A: BAC
B: CAB
C: ABC
{noformat}, and would still get the same result. I need to verify this, as it would make testing simpler.
This definitely breaks {{MERGE3}} as no member will ever assume the task of merge leader as {{view[first] == local_addr}} will always be false!
> MERGE3: merge never happens
> ---------------------------
>
> Key: JGRP-2092
> URL: https://issues.jboss.org/browse/JGRP-2092
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.txt
>
>
> (Reported by Neal Dillman)
> In the case below, a merge doesn't seem to happen. Write a unit test to reprodue this.
> {noformat}
> Host A view: B, X, Y, Z, A (where B should be coordinator)
> Host B view: C, Q, R, S, B (where C should be coordinator)
> Host C view: A, M, N, O, C (where A should be coordinator)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-3636:
------------------------------
Fix Version/s: 11.0.0.Alpha1
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Alpha1
>
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-3636:
-----------------------------------
[~will.tatam] sorry, the code is not yet checked in WildFly (nor in EAP7). It's targeted for WFLY 11.
> Improve monitoring of JMS pooled connection in JBoss CLI
> --------------------------------------------------------
>
> Key: WFLY-3636
> URL: https://issues.jboss.org/browse/WFLY-3636
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 8.1.0.Final
> Environment: JBoss EAP 6.x
> Reporter: Tom Ross
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Alpha1
>
>
> At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools:
> {noformat}
> "pool" => {
> "ActiveCount" => "0",
> "AvailableCount" => "0",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "0",
> "CreatedCount" => "0",
> "DestroyedCount" => "0",
> "InUseCount" => "0",
> "MaxCreationTime" => "0",
> "MaxUsedCount" => "0",
> "MaxWaitCount" => "0",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "0",
> "statistics-enabled" => false
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months