[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Aieksiei Illarionov (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Aieksiei Illarionov commented on JGRP-2335:
-------------------------------------------
I ended up making a new timeout variable to resolve this problem.
bq. If you set write_data_on_find to true, does that fix the issue?
Thanks. I will try this in about a week's time, - sorry, I'm vacationing.
bq. I noticed you set remove_all_data_on_view_change to true; this should clear the table on a view change, so no stale data of members killed with -9 should be in the table...
About this... well, the bad news is, remove_all_data_on_view_change doesn't really work. The table is never cleared, it's slowly growing in size. I've tried debugging the code, and I think there's a bug. I'll pin it down again and report it back to you, in about a week's time, sorry.
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2335.
----------------------------
Resolution: Cannot Reproduce
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2335:
--------------------------------
Re your suggestions:
a) somehow involve MembershipChangePolicy in ordering strategy
This is something you can do in your application. Both view creation _and_ address creation are pluggable and can be done is user code.
b) make the new server (joiner) the first in the sorted set, or
See a)
c) make UUID addresses to sort depending on their time of creation.
This can also be done with custom addresses (see above). Requirement of course is the same wall clock time everywhere, which requires time synchronization.
I'm closing this issue for now. Please feel free to reopen with exact steps to reproduce.
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2335:
--------------------------------
If you {{killall -9 java}}, then the table won't get cleared and you have to clear it manually.
Note that startup of new members will be delayed by {{GMS.max_join_attempts * GMS.join_timeout}}, and then a new joiner makes itself coordinator.
Subsequent joiners will find this coord and join its subcluster. On the next view change, the stale members will be cleared from the table.
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4382) Executable-model build error with "matches" and fuction with a fact property as an argument
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-4382?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-4382:
---------------------------------
Sprint: 2019 Week 32-34
> Executable-model build error with "matches" and fuction with a fact property as an argument
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-4382
> URL: https://issues.jboss.org/browse/DROOLS-4382
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.24.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> When a rule uses "matches" and class function and its argument is a property of the fact,
> for example)
> {noformat}
> import org.drools.modelcompiler.domain.Person;
> import static org.drools.modelcompiler.domain.MyFunctions.*;
> rule R when
> $a : Person( name matches testMatch(likes) )
> then
> end
> {noformat}
> It fails to build in executable-model
> {noformat}
> [ERROR] testMatchesClassFunctionWithArg[FLOW_DSL](org.drools.modelcompiler.CompilerTest) Time elapsed: 0.346 s <<< ERROR!
> java.lang.IllegalArgumentException: Cannot get expression type by name _this!
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.lambda$expressionTypeNameExpr$2(DrlxParseUtil.java:246)
> at java.util.Optional.orElseThrow(Optional.java:290)
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.expressionTypeNameExpr(DrlxParseUtil.java:246)
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.getExpressionType(DrlxParseUtil.java:180)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.processFirstNode(ExpressionTyper.java:549)
> {noformat}
> It works with non-executable-model.
> Additonal note: When running kie-maven-plugin with -DgenerateModel=YES in 7.23.0.Final-redhat-00002 (RHDM 7.4.0), the error message is "No value present".
> {noformat}
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:7.23.0.Final-redhat-00002:generateModel (default-generateModel) on project model-map-evaluation-rule: Execution default-generateModel of goal org.kie:kie-maven-plugin:7.23.0.Final-redhat-00002:generateModel failed: No value present -> [Help 1]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4381) BigDecimal and primitive comparison error in executable-model build
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-4381?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-4381:
---------------------------------
Sprint: 2019 Week 32-34
> BigDecimal and primitive comparison error in executable-model build
> -------------------------------------------------------------------
>
> Key: DROOLS-4381
> URL: https://issues.jboss.org/browse/DROOLS-4381
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.24.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> When you compare BigDecimal (but the field type is Object) with primitive int,
> {noformat}
> import org.drools.modelcompiler.domain.Result;
> rule "rule1"
> when
> $r : Result( value <= 20 )
> then
> end
> {noformat}
> executable-model build fails.
> {noformat}
> [ERROR] Failures:
> [ERROR] CompilerTest.testBigDecimalIntCoercion:1901->BaseModelTest.getKieSession:99->BaseModelTest.getKieSession:103->BaseModelTest.getKieContainer:107->BaseModelTest.getKieContainer:114->BaseModelTest.createKieBuilder:125->BaseModelTest.createKieBuilder:152 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=24, column=122
> text=no suitable method found for lessOrEqualNumbers(java.lang.Object,int)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Number,java.lang.Number) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Number)
> method org.drools.modelcompiler.util.EvaluationUtil.lessOrEqualNumbers(java.lang.Long,java.lang.Long) is not applicable
> (argument mismatch; java.lang.Object cannot be converted to java.lang.Long)], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesC992C95703C3473926B5B025D30097DARuleMethods0.java in error:
> {noformat}
> Non executable-model works with the rule.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2335) JDBC_PING: code for determining the coordinator hangs in certain conditions
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2335?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2335:
--------------------------------
If you set {{write_data_on_find}} to true, does that fix the issue? I noticed you set {{remove_all_data_on_view_change}} to true; this should clear the table on a view change, so no stale data of members killed with -9 should be in the table...
> JDBC_PING: code for determining the coordinator hangs in certain conditions
> ---------------------------------------------------------------------------
>
> Key: JGRP-2335
> URL: https://issues.jboss.org/browse/JGRP-2335
> Project: JGroups
> Issue Type: Bug
> Reporter: Aieksiei Illarionov
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
>
> Affected version:
> {code:xml}
> <dependency>
> <groupId>org.jgroups</groupId>
> <artifactId>jgroups</artifactId>
> <version>4.0.0.Final</version>
> </dependency>
> {code}
> ClientGmsImpl#joinInternal hangs because #firstOfAllClients always returns false when all of the following conditions are satisfied:
> - using JDBC_PING for discovery protocol
> - JGROUPSPING table contains data from previous sessions
> - all of the previous sessions were killed (kill -9)
> - AddressGenerator is not customized
> The sorted set
> {code:java}
> SortedSet<Address> clients=new TreeSet<>();
> {code}
> contains the dead servers discovered from JGROUPSPING. When the new server is added to the sorted set, it never becomes the first in the sorted set.
> Suggestions: either
> a) somehow involve MembershipChangePolicy in ordering strategy, or
> b) make the new server (joiner) the first in the sorted set, or
> c) make UUID addresses to sort depending on their time of creation.
> I've used the following config:
> {code:xml}
> <!--
> TCP based stack, with flow control and message bundling. This is usually used when IP
> multicasting cannot be used in a network, e.g. because it is disabled (routers discard multicast).
> Note that TCP.bind_addr and TCPPING.initial_hosts should be set, possibly via system properties, e.g.
> -Djgroups.bind_addr=192.168.5.2 and -Djgroups.tcpping.initial_hosts=192.168.5.2[7800]
> author: Bela Ban
> -->
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns="urn:org:jgroups"
> xmlns:fork="fork"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd fork http://www.jgroups.org/schema/fork-stacks.xsd">
> <TCP bind_port="7800"
> port_range="10"
> bind_addr="<placeholder here>"
> recv_buf_size="${tcp.recv_buf_size:130k}"
> send_buf_size="${tcp.send_buf_size:130k}"
> max_bundle_size="64K"
> sock_conn_timeout="300"
> thread_pool.min_threads="0"
> thread_pool.max_threads="20"
> thread_pool.keep_alive_time="30000"/>
> <JDBC_PING
> remove_all_data_on_view_change="true"
> connection_driver="com.microsoft.sqlserver.jdbc.SQLServerDriver"
> connection_url="jdbc:sqlserver://localhost:1433;databaseName=mydatabase"
> connection_username="user"
> connection_password="password"
> />
> <MERGE3 min_interval="10000"
> max_interval="30000"/>
> <FD_SOCK/>
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="1500" />
> <BARRIER />
> <pbcast.NAKACK2 use_mcast_xmit="false"
> discard_delivered_msgs="true"/>
> <UNICAST3
> conn_close_timeout="240000"
> xmit_interval="5000"/>
> <pbcast.STABLE desired_avg_gossip="50000"
> max_bytes="4M"/>
> <pbcast.GMS print_local_addr="true" join_timeout="2000"
> view_bundling="true"
> membership_change_policy="ru.illar.AppMembershipChangePolicy"/>
> <MFC max_credits="2M"
> min_threshold="0.4"/>
> <FRAG2 frag_size="60K" />
> <!--RSVP resend_interval="2000" timeout="10000"/-->
> <pbcast.STATE_TRANSFER/>
> </config>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months