November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1976) Choose the next coordinator from the largest sub-cluster when merge

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/JGRP-1976?page=com.atlassian.jira.plugin.... ] Osamu Nagano commented on JGRP-1976: ------------------------------------ Thanks for the prompt addition. It would be great if this is the default because the effect is minimum comparing to {{DefaultMembershipPolicy}}. > Choose the next coordinator from the largest sub-cluster when merge > ------------------------------------------------------------------- > > Key: JGRP-1976 > URL: https://issues.jboss.org/browse/JGRP-1976 > Project: JGroups > Issue Type: Enhancement > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.7 > > Attachments: LargestWinningPolicy.java > > > When sub-clusters merge, the current DefaultMembershipPolicy collects all coordinators from the sub-clusters and sorts it, then chooses the first one as the next coordinator (JGRP-1002). The sort is done by UUID which is random. Please consider to change the algorithm slightly to choose the one from the largest (in terms of the number of members) sub-cluster and make it the default. > Choosing the largest one is reasonable from many point of views. For example, a WildFly cluster hosting a singleton service becomes more robust. Another scenario is about a large Inifnispan cluster. When you add an extra node and the node resides into another network segment, the new node tends to become an isolated coordinator initially (because a switch requires some time to reflect a new multicast route between the segments) then merges later. With the current implementation, this new node becomes the coordinator frequently and affects stability of the cluster by a cluster-wide rebalance. This is bad because the intention is to ease the cluster, not to unstabilize it. > The implementation can be customized by membership_change_policy property of pbcast.GMS. I attach my implementation as LargestWinningPolicy.java as a reference. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/JGRP-1977?page=com.atlassian.jira.plugin.... ] Osamu Nagano updated JGRP-1977: ------------------------------- Issue Type: Enhancement (was: Bug) > More redundant initial join logic to avoid becoming a fake coordinator > ---------------------------------------------------------------------- > > Key: JGRP-1977 > URL: https://issues.jboss.org/browse/JGRP-1977 > Project: JGroups > Issue Type: Enhancement > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.7 > > > If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes. > This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable. > Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator

by Osamu Nagano (JIRA)

[ https://issues.jboss.org/browse/JGRP-1977?page=com.atlassian.jira.plugin.... ] Osamu Nagano commented on JGRP-1977: ------------------------------------ I tried inserting a sleep code just after {{MulticastSocket#joinGroup()}} in {{UDP}}, but it didn't help. And I created a PR which works as expected in such a network environment. This is just an example which is not intended to be merged. It has one disadvantage that the real coordinator will take more time to start up. https://github.com/belaban/JGroups/pull/245 Another idea at {{ClientGmsImpl#joinInternal()}} level is introducing another retry loop for discovery, not for join. > More redundant initial join logic to avoid becoming a fake coordinator > ---------------------------------------------------------------------- > > Key: JGRP-1977 > URL: https://issues.jboss.org/browse/JGRP-1977 > Project: JGroups > Issue Type: Bug > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.7 > > > If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes. > This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable. > Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-977) Error in combining str[contains] with OR results

by hoon lee (JIRA)

hoon lee created DROOLS-977: ------------------------------- Summary: Error in combining str[contains] with OR results Key: DROOLS-977 URL: https://issues.jboss.org/browse/DROOLS-977 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Environment: CentOS 6.4, WildFly Reporter: hoon lee Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-976) Exception when comparing dates with after operator

by Demian Calcaprina (JIRA)

[ https://issues.jboss.org/browse/DROOLS-976?page=com.atlassian.jira.plugin... ] Demian Calcaprina updated DROOLS-976: ------------------------------------- Priority: Minor (was: Major) > Exception when comparing dates with after operator > -------------------------------------------------- > > Key: DROOLS-976 > URL: https://issues.jboss.org/browse/DROOLS-976 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Demian Calcaprina > Assignee: Mario Fusco > Priority: Minor > > It seems when we have a LHS like this: > Order( $current.time after[1m] time ) > Drools will fail in the evaluation with this exception: > Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long > at org.drools.core.base.extractors.ConstantValueReader.getLongValue(ConstantValueReader.java:48) [drools-core-6.1.0.Final.jar:6.1.0.Final] > at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:365) [drools-core-6.1.0.Final.jar:6.1.0.Final] > This is a PR that demonstrates the issue > https://github.com/droolsjbpm/drools/pull/554 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-976) Exception when comparing dates with after operator

by Demian Calcaprina (JIRA)

[ https://issues.jboss.org/browse/DROOLS-976?page=com.atlassian.jira.plugin... ] Demian Calcaprina updated DROOLS-976: ------------------------------------- Description: It seems when we have a LHS like this: Order( $current.time after[1m] time ) Drools will fail in the evaluation with this exception: Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long at org.drools.core.base.extractors.ConstantValueReader.getLongValue(ConstantValueReader.java:48) [drools-core-6.1.0.Final.jar:6.1.0.Final] at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:365) [drools-core-6.1.0.Final.jar:6.1.0.Final] This is a PR that demonstrates the issue https://github.com/droolsjbpm/drools/pull/554 was: It seems when we have a LHS like this: Order( $current.time after[1m] time ) Drools will fail in the evaluation with this exception: Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long at org.drools.core.base.extractors.ConstantValueReader.getLongValue(ConstantValueReader.java:48) [drools-core-6.1.0.Final.jar:6.1.0.Final] at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:365) [drools-core-6.1.0.Final.jar:6.1.0.Final] > Exception when comparing dates with after operator > -------------------------------------------------- > > Key: DROOLS-976 > URL: https://issues.jboss.org/browse/DROOLS-976 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Demian Calcaprina > Assignee: Mario Fusco > > It seems when we have a LHS like this: > Order( $current.time after[1m] time ) > Drools will fail in the evaluation with this exception: > Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long > at org.drools.core.base.extractors.ConstantValueReader.getLongValue(ConstantValueReader.java:48) [drools-core-6.1.0.Final.jar:6.1.0.Final] > at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:365) [drools-core-6.1.0.Final.jar:6.1.0.Final] > This is a PR that demonstrates the issue > https://github.com/droolsjbpm/drools/pull/554 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-976) Exception when comparing dates with after operator

by Demian Calcaprina (JIRA)

Demian Calcaprina created DROOLS-976: ---------------------------------------- Summary: Exception when comparing dates with after operator Key: DROOLS-976 URL: https://issues.jboss.org/browse/DROOLS-976 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Reporter: Demian Calcaprina Assignee: Mario Fusco It seems when we have a LHS like this: Order( $current.time after[1m] time ) Drools will fail in the evaluation with this exception: Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long at org.drools.core.base.extractors.ConstantValueReader.getLongValue(ConstantValueReader.java:48) [drools-core-6.1.0.Final.jar:6.1.0.Final] at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluate(AfterEvaluatorDefinition.java:365) [drools-core-6.1.0.Final.jar:6.1.0.Final] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5666) Infinispan enables statistics instrumentation even though statistics-enabled is false

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-5666: ---------------------------------- Summary: Infinispan enables statistics instrumentation even though statistics-enabled is false Key: WFLY-5666 URL: https://issues.jboss.org/browse/WFLY-5666 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 10.0.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5665) Infinispan enables statistics instrumentation even though statistics-enabled is false

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5665?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5665: ------------------------------- Summary: Infinispan enables statistics instrumentation even though statistics-enabled is false (was: Infinispan enables statistics instrumentation even though statistics-enabled is false.) > Infinispan enables statistics instrumentation even though statistics-enabled is false > ------------------------------------------------------------------------------------- > > Key: WFLY-5665 > URL: https://issues.jboss.org/browse/WFLY-5665 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Labels: clustering_performance > Fix For: 10.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5665) Infinispan enables statistics instrumentation even though statistics-enabled is false.

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5665?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5665: ------------------------------- Summary: Infinispan enables statistics instrumentation even though statistics-enabled is false. (was: Infinispan collects statistics even though statistics-enabled is false.) > Infinispan enables statistics instrumentation even though statistics-enabled is false. > -------------------------------------------------------------------------------------- > > Key: WFLY-5665 > URL: https://issues.jboss.org/browse/WFLY-5665 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Labels: clustering_performance > Fix For: 10.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015