[JBoss JIRA] (JGRP-1682) STOP_FLUSH race condition in 3.x
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1682?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1682:
---------------------------
Fix Version/s: 3.5
(was: 3.4)
> STOP_FLUSH race condition in 3.x
> --------------------------------
>
> Key: JGRP-1682
> URL: https://issues.jboss.org/browse/JGRP-1682
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.4
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Fix For: 3.3.6, 3.5
>
>
> Similar to JGRP-1674.
> flush_unblock_promise in FLUSH is not reset before use in waitForUnblock.
> *Any* UNBLOCK (such as another node running FLUSH) will set it, not just the expected UNBLOCK.
> The next call to waitForUnblock will not block.
> (and if the UNBLOCK it was waiting for comes later, it will trigger the issue again on the next waitForUnblock).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge views
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1705.
----------------------------
Resolution: Done
> MERGE3 handles fake merge views
> -------------------------------
>
> Key: JGRP-1705
> URL: https://issues.jboss.org/browse/JGRP-1705
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge views
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1705:
--------------------------------
The merging seems to work fine as Karim achieved a cluster of 1538 nodes: http://belaban.blogspot.ch/2013/09/new-record-for-large-jgroups-cluster.html.
Made a few more changes:
* When a TMP_VIEW is received, the InfoSender and ViewConsistencyChecker are stopped (restarted on VIEW)
* When an INFO is received from sender P, we remove P's previous INFO registrations
> MERGE3 handles fake merge views
> -------------------------------
>
> Key: JGRP-1705
> URL: https://issues.jboss.org/browse/JGRP-1705
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge views
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1705 at 9/30/13 9:30 AM:
---------------------------------------------------------
In the log, we can see that a MERGE event was sent up with the *same view-id*:
{noformat}
[Sender: 172.29.190.189-svc2-serv-00832070-38705, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.39-svc0-serv-00832097-62076, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.155-svc3-serv-ETJ104516289-45232, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
{noformat}
Of course, we also need to fix suppression of these events, but the second line of defense is to quickly check if all view-ids are the same and simply drop the MERGE event in this case.
was (Author: belaban):
In the log, we can see that a MERGE event was sent up with the *same view-id*L
{noformat}
[Sender: 172.29.190.189-svc2-serv-00832070-38705, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.39-svc0-serv-00832097-62076, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.155-svc3-serv-ETJ104516289-45232, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
{noformat}
Of course, we also need to fix suppression of these events, but the second line of defense is to quickly check if all view-ids are the same and simply drop the MERGE event in this case.
> MERGE3 handles fake merge views
> -------------------------------
>
> Key: JGRP-1705
> URL: https://issues.jboss.org/browse/JGRP-1705
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Karim AMMOUS
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2184) Probe operations not visible in access control meta data
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-2184?page=com.atlassian.jira.plugin.... ]
Heiko Braun reassigned WFLY-2184:
---------------------------------
Assignee: Kabir Khan (was: Brian Stansberry)
[~kabirkhan] Can you take a look at this? I would expect the operation to appear within the access control meta data when operating as "administrator"
> Probe operations not visible in access control meta data
> --------------------------------------------------------
>
> Key: WFLY-2184
> URL: https://issues.jboss.org/browse/WFLY-2184
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Kabir Khan
> Fix For: 8.0.0.CR1
>
>
> See
> {noformat}
> [domain@localhost:9999 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store:read-resource-description(access-control=trim-descriptions, operations=true){roles=administrator}
> {
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {"transactions" => {"model-description" => undefined}},
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {"type" => {
> "read" => true,
> "write" => false
> }},
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (WFLY-2184) Probe operations not visible in access control meta data
by Heiko Braun (JIRA)
Heiko Braun created WFLY-2184:
---------------------------------
Summary: Probe operations not visible in access control meta data
Key: WFLY-2184
URL: https://issues.jboss.org/browse/WFLY-2184
Project: WildFly
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
See
{noformat}
[domain@localhost:9999 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store:read-resource-description(access-control=trim-descriptions, operations=true){roles=administrator}
{
"outcome" => "success",
"result" => {
"description" => undefined,
"attributes" => undefined,
"operations" => undefined,
"children" => {"transactions" => {"model-description" => undefined}},
"access-control" => {
"default" => {
"read" => true,
"write" => true,
"attributes" => {"type" => {
"read" => true,
"write" => false
}},
"operations" => {
"read-children-names" => {"execute" => true},
"read-operation-description" => {"execute" => true},
"read-operation-names" => {"execute" => true},
"read-children-types" => {"execute" => true},
"undefine-attribute" => {"execute" => true},
"read-children-resources" => {"execute" => true},
"read-resource-description" => {"execute" => true},
"read-resource" => {"execute" => true},
"read-attribute" => {"execute" => true},
"write-attribute" => {"execute" => true}
}
},
"exceptions" => {}
}
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months