[JBoss JIRA] (JGRP-1670) Cluster doesn't heal after first discovery fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1670?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1670:
--------------------------------
(Copied from GB PR)
The reason I'm sending a null PingData when view_id is non-null is that I wanted to minimize message size on merge-triggered discovery requests. Your change means that we might now always send full discovery responses as well, which is something I wanted to avoid.
I need to dig deeper into the code though to see what the ramifications of your change are. Stay tuned, I can hopefully get to this next week...
> Cluster doesn't heal after first discovery fails
> ------------------------------------------------
>
> Key: JGRP-1670
> URL: https://issues.jboss.org/browse/JGRP-1670
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 on EC2 using OpenJDK 1.6.0_27 from the APT repositories.
> Reporter: Andy Caldwell
> Assignee: Bela Ban
> Fix For: 3.3.5, 3.4
>
>
> When using TCPPING for discovery, if the very first attempt to discover the rest of the cluster fails (in my case, the connections are timing out due to a suspected EC2 issue), the new node decides that it is alone in the cluster and creates a new view of just itself.
> Later, when performing periodic discovery, the new node successfully connects to the existing cluster and sends a GET_MBRS_REQ but, since it's already in a view (the one where it's alone), it doesn't fill in its local IP address (see the logic or this at https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). This means that the old nodes in the cluster cannot send a reply or any other cluster messages to the new node. Thus the new node, which never get a response to its GET_MBRS_REQ, continues to think it's alone in the world and the old members, who got a record of a new cluster member but no address to communicate with it on, start logging that they're dropping messages to <UUID> because they have no physical address. The cluster never heals.
> If the physical address were included in all GET_MBRS_REQ messages (e.g. if the if statement were removed from the file I linked above), then, even if initial discovery fails, future discovery would succeed and the cluster would heal itself.
> This is a superficially similar issue to https://issues.jboss.org/browse/JGRP-1203, but, in that case, the cluster will heal once A performs a discovery later while in this one it never heals.
--
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, 11 months
[JBoss JIRA] (WFLY-1686) Use HAL release stream version number in console footer
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1686?page=com.atlassian.jira.plugin.... ]
Harald Pehl resolved WFLY-1686.
-------------------------------
Labels: console_1.5.6 merged (was: console_1.5.4)
Resolution: Done
> Use HAL release stream version number in console footer
> -------------------------------------------------------
>
> Key: WFLY-1686
> URL: https://issues.jboss.org/browse/WFLY-1686
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
> Labels: console_1.5.6, merged
>
> Currently the version number of the Core Console is displayed in the footer of the Admin Console. This should be changed to the version number of the HAL Release Stream. There can be more than one HAL Release Stream based on one Core Console Version:
> {code}
> Core Console 1.5.4.Final --> HAL Release Stream 1.5.4.Final
> --> HAL Release Stream 1.5.5.Final
> {code}
--
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, 11 months
[JBoss JIRA] (WFLY-1442) Web console branding across community and product versions
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1442?page=com.atlassian.jira.plugin.... ]
Harald Pehl resolved WFLY-1442.
-------------------------------
Labels: console_1.5.6 merged (was: console_1.5.4)
Resolution: Done
> Web console branding across community and product versions
> -----------------------------------------------------------
>
> Key: WFLY-1442
> URL: https://issues.jboss.org/browse/WFLY-1442
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Harald Pehl
> Assignee: Harald Pehl
> Labels: console_1.5.6, merged
>
> Define a way to specify the branding for the web console across different community and product versions. The name and version used for the branding should be read from the {{product-name}} and {{product-version}} attributes of the root DMR resource. Regarding the logo there are different options:
> # Use a unique logo for the web console across all community and products / versions
> # Choose between a community (WildFly) and a product logo (RedHat)
> # Hold up all logos for any community / product version in the HAL release stream and choose dynamically.
--
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, 11 months
[JBoss JIRA] (JGRP-1670) Cluster doesn't heal after first discovery fails
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1670?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1670:
---------------------------
Fix Version/s: 3.3.5
3.4
> Cluster doesn't heal after first discovery fails
> ------------------------------------------------
>
> Key: JGRP-1670
> URL: https://issues.jboss.org/browse/JGRP-1670
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 on EC2 using OpenJDK 1.6.0_27 from the APT repositories.
> Reporter: Andy Caldwell
> Assignee: Bela Ban
> Fix For: 3.3.5, 3.4
>
>
> When using TCPPING for discovery, if the very first attempt to discover the rest of the cluster fails (in my case, the connections are timing out due to a suspected EC2 issue), the new node decides that it is alone in the cluster and creates a new view of just itself.
> Later, when performing periodic discovery, the new node successfully connects to the existing cluster and sends a GET_MBRS_REQ but, since it's already in a view (the one where it's alone), it doesn't fill in its local IP address (see the logic or this at https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). This means that the old nodes in the cluster cannot send a reply or any other cluster messages to the new node. Thus the new node, which never get a response to its GET_MBRS_REQ, continues to think it's alone in the world and the old members, who got a record of a new cluster member but no address to communicate with it on, start logging that they're dropping messages to <UUID> because they have no physical address. The cluster never heals.
> If the physical address were included in all GET_MBRS_REQ messages (e.g. if the if statement were removed from the file I linked above), then, even if initial discovery fails, future discovery would succeed and the cluster would heal itself.
> This is a superficially similar issue to https://issues.jboss.org/browse/JGRP-1203, but, in that case, the cluster will heal once A performs a discovery later while in this one it never heals.
--
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, 11 months
[JBoss JIRA] (JGRP-1670) Cluster doesn't heal after first discovery fails
by Andy Caldwell (JIRA)
Andy Caldwell created JGRP-1670:
-----------------------------------
Summary: Cluster doesn't heal after first discovery fails
Key: JGRP-1670
URL: https://issues.jboss.org/browse/JGRP-1670
Project: JGroups
Issue Type: Bug
Affects Versions: 3.3.1
Environment: Ubuntu 12.04 on EC2 using OpenJDK 1.6.0_27 from the APT repositories.
Reporter: Andy Caldwell
Assignee: Bela Ban
When using TCPPING for discovery, if the very first attempt to discover the rest of the cluster fails (in my case, the connections are timing out due to a suspected EC2 issue), the new node decides that it is alone in the cluster and creates a new view of just itself.
Later, when performing periodic discovery, the new node successfully connects to the existing cluster and sends a GET_MBRS_REQ but, since it's already in a view (the one where it's alone), it doesn't fill in its local IP address (see the logic or this at https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). This means that the old nodes in the cluster cannot send a reply or any other cluster messages to the new node. Thus the new node, which never get a response to its GET_MBRS_REQ, continues to think it's alone in the world and the old members, who got a record of a new cluster member but no address to communicate with it on, start logging that they're dropping messages to <UUID> because they have no physical address. The cluster never heals.
If the physical address were included in all GET_MBRS_REQ messages (e.g. if the if statement were removed from the file I linked above), then, even if initial discovery fails, future discovery would succeed and the cluster would heal itself.
This is a superficially similar issue to https://issues.jboss.org/browse/JGRP-1203, but, in that case, the cluster will heal once A performs a discovery later while in this one it never heals.
--
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, 11 months
[JBoss JIRA] (JGRP-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1613 at 8/2/13 6:28 AM:
--------------------------------------------------------
The above problem could be solved by declaratively defining FORK and the various fork channels, e.g. (pseudo config):
{noformat}
...
<MFC/>
<UFC/>
<FORK>
<fork id="1">
<CENTRAL_LOCK ... />
</fork>
<fork id="2">
<COUNTER ... />
</fork>
</FORK>
<FRAG2/>
<TOA/>
{noformat}
This defines
# A main (default) stack with MFC, UFC, FRAG2 and TOA at the top
# A stack (id=1) with CENTRAL_LOCK at the top and
# A stack (id=2) with COUNTER at the top
When a new fork-channel is created, we'd have to pick an ID and the channel could then be created over the corresponding entry in FORK. At node creation time, when the main-channel is created, FORK will also create the 2 fork-stacks. When a fork-channel with id=2 is created, it will be created over the fork-stack with id=2.
was (Author: belaban):
The above problem could be solved by declaratively defining FORK and the various fork channels, e.g. (pseudo config):
{noformat}
...
<MFC/>
<UFC/>
<FORK>
<fork id="1">
<CENTRAL_LOCK ... />
</fork>
<fork id="2">
<COUNTER ... />
</fork>
</FORK>
<FRAG2/>
<TOA/>
{noformat}
This defines
# A main (default) stack with MFC, UFC, FRAG2 and TOA at the top
# A stack (id=1) with CENTRAL_LOCK at the top and
# A stack (id=2) with COUNTER at the top
When a new fork-channel is created, we'd have to pick an ID and the channel could then be created over the corresponding entry in FORK
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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, 11 months
[JBoss JIRA] (JGRP-1613) FORK: cactus stacks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1613?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1613:
--------------------------------
The above problem could be solved by declaratively defining FORK and the various fork channels, e.g. (pseudo config):
{noformat}
...
<MFC/>
<UFC/>
<FORK>
<fork id="1">
<CENTRAL_LOCK ... />
</fork>
<fork id="2">
<COUNTER ... />
</fork>
</FORK>
<FRAG2/>
<TOA/>
{noformat}
This defines
# A main (default) stack with MFC, UFC, FRAG2 and TOA at the top
# A stack (id=1) with CENTRAL_LOCK at the top and
# A stack (id=2) with COUNTER at the top
When a new fork-channel is created, we'd have to pick an ID and the channel could then be created over the corresponding entry in FORK
> FORK: cactus stacks
> -------------------
>
> Key: JGRP-1613
> URL: https://issues.jboss.org/browse/JGRP-1613
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: IMAG0129.jpg
>
>
> Introduce cactus stacks where we can have multiple, different, stacks grafted onto the same base stack.
> The problem today is that different applications need different functionality (protocol stack configs) in the AS. For example, we have the default stack used by AS. Then, Hibernate Search wants to use distributed locking (CENTRAL_LOCK) and counting (COUNTER). The total order stack wants to use TOA/SEQUENCER and so on.
> Cactus stacks add the ability to:
> * Provide custom (partial) stacks that are grafted onto a base stack
> * Add/remove stacks at runtime
> See the attached picture for details.
--
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, 11 months