May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1906) jdbc_ping doesn't delete crashed node

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1906?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1906: -------------------------------- You can always enable {{remove_old_coords_on_view_change}} and/or {{remove_all_files_on_view_change}}. Check out {{FILE_PING}} [1] [2] for details. [1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... [2] http://www.jgroups.org/manual/index.html#FILE_PING > jdbc_ping doesn't delete crashed node > ------------------------------------- > > Key: JGRP-1906 > URL: https://issues.jboss.org/browse/JGRP-1906 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: n/a > Reporter: rama rama > Assignee: Bela Ban > Priority: Critical > > Hi, > i am having trouble with jgroups. If a node crash, it doesn't get removed from jdbc table. > After 10 hours of work, the table contains 100 rows (that is not a problem) but, when the server start_up, GMS take _AGES_ to try to connect to all this dead node. > Since i am only a 'user' speaking about jgroup and i have no idea on how internally does it work, it this normal? > I don't think so, master of the cluster, or a governor or something like that, should be able to detect if a node is present or not (via FD,VERIFY_SUSPECT) and delete it from JDBC table to avoid issue on startup for the next time, correct me if i am wrong. > Here a copy/paste of my current config, configured in applicative way. > ------------------------------------------------------------------------------------ > int min_cores = 1; > int max_cores = 50; > InetAddress bind_addr = org.jgroups.util.Util.getAddressByPatternMatch("match-address:" + Config.get("Cluster.bind_addr")); > stack > .addProtocol(new UDP() > .setValue("bind_addr", bind_addr) > .setValue("loopback", true) > .setValue("thread_naming_pattern", "cl") > .setValue("timer_type", "new3") > .setValue("timer_min_threads", min_cores) > .setValue("timer_max_threads", max_cores) > .setValue("timer_keep_alive_time", Util.MIN * 10) > .setValue("timer_queue_max_size", 500) > .setValue("mcast_port", Config.get("Cluster.mcast_port", Constant.INT_NULL)) > .setValue("thread_pool_keep_alive_time", Util.MIN * 10) > .setValue("thread_pool_min_threads", min_cores) > .setValue("thread_pool_max_threads", max_cores) > .setValue("thread_pool_queue_enabled", false) > .setValue("thread_pool_queue_max_size", 500) > .setValue("oob_thread_pool_keep_alive_time", Util.MIN * 10) > .setValue("oob_thread_pool_min_threads", min_cores) > .setValue("oob_thread_pool_max_threads", max_cores) > .setValue("oob_thread_pool_queue_enabled", false) > .setValue("oob_thread_pool_queue_max_size", 500) > .setValue("internal_thread_pool_keep_alive_time", Util.MIN * 10) > .setValue("internal_thread_pool_min_threads", min_cores) > .setValue("internal_thread_pool_max_threads", max_cores) > .setValue("internal_thread_pool_queue_enabled", false) > .setValue("internal_thread_pool_queue_max_size", 600000) > .setValue("ucast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M")) > .setValue("ucast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K")) > .setValue("mcast_recv_buf_size", org.jgroups.util.Util.readBytesInteger("5M")) > .setValue("mcast_send_buf_size", org.jgroups.util.Util.readBytesInteger("640K")) > ) > .addProtocol(new JDBC_PING() > .setValue("connection_url", Config.get("DB.dbdriver") + ':' + Config.get("DB.dburl") + '/' + Config.get("DB.dbname")) > .setValue("connection_username", Config.get("DB.dbuser")) > .setValue("connection_password", Config.get("DB.dbpwd")) > .setValue("connection_driver", "org.postgresql.Driver") > .setValue("initialize_sql", "CREATE TABLE IF NOT EXISTS JGROUPSPING ( own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data bytea DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )") > ) > .addProtocol(new MERGE3() > .setValue("max_interval", 10000) > .setValue("min_interval", 1000) > ) > .addProtocol(new FD_SOCK() > .setValue("bind_addr", bind_addr) > ) > .addProtocol(new FD_ALL() > ) > .addProtocol(new VERIFY_SUSPECT() > .setValue("timeout", 1000) > .setValue("bind_addr", bind_addr) > ) > .addProtocol(new NAKACK2() > .setValue("xmit_interval", 500) > .setValue("xmit_table_num_rows", 100) > .setValue("xmit_table_msgs_per_row", 2000) > .setValue("xmit_table_max_compaction_time", 30000) > .setValue("max_msg_batch_size", 500) > .setValue("use_mcast_xmit", false) > .setValue("discard_delivered_msgs", true) > ) > .addProtocol(new UNICAST3() > .setValue("xmit_table_num_rows", 100) > .setValue("xmit_table_msgs_per_row", 1000) > .setValue("xmit_table_max_compaction_time", 30000) > .setValue("max_msg_batch_size", 500) > ) > .addProtocol(new STABLE() > .setValue("stability_delay", 2000) > .setValue("desired_avg_gossip", 60000) > .setValue("max_bytes", org.jgroups.util.Util.readBytesInteger("4M")) > .setValue("cap", 0.1) > ) > .addProtocol(new GMS() > .setValue("join_timeout", 3000) > .setValue("view_bundling", false) > .setValue("print_local_addr", false) > .setValue("print_physical_addrs", false) > ) > .addProtocol(new UFC() > .setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M")) > .setValue("min_threshold", 0.4) > ) > .addProtocol(new MFC() > .setValue("max_credits", org.jgroups.util.Util.readBytesInteger("4M")) > .setValue("min_threshold", 0.4) > ) > .addProtocol(new FRAG2() > .setValue("frag_size", org.jgroups.util.Util.readBytesInteger("60K")) > ) > .addProtocol(new RSVP() > .setValue("resend_interval", 2000) > .setValue("timeout", 10000) > ) > ; > stack.init(); > ---------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2062: -------------------------------- I'd rather leave TYPE_STRING and _add_ another TYPE_UTF which uses UTF encoding. Good idea about the deprecation; I might even remove that constructor in 4.0 (and deprecate it in 3.x). Thanks for the kudos! > TYPE_STRING does not handle unicode > ----------------------------------- > > Key: JGRP-2062 > URL: https://issues.jboss.org/browse/JGRP-2062 > Project: JGroups > Issue Type: Bug > Reporter: Cody Ebberson > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. > For example, see objectToByteBuffer lines 561-567: > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > {{case TYPE_STRING: > String str=(String)obj; > int len=str.length(); > ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); > for(int i=0; i < len; i++) > retval.put((byte)str.charAt(i)); > return retval.array();}} > This code will incorrectly encode any String with non ASCII encoding. > There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6569) Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it.

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-6569?page=com.atlassian.jira.plugin.... ] Lin Gao commented on WFLY-6569: ------------------------------- Leave this issue as it is since it is not a critical issue. This will be superseded by Elytron, see: http://lists.jboss.org/pipermail/wildfly-dev/2016-May/005012.html > Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it. > ------------------------------------------------------------------------------------- > > Key: WFLY-6569 > URL: https://issues.jboss.org/browse/WFLY-6569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Lin Gao > > Vault.sh can create keystore when doesn't exist. But we can't define KEY_SIZE for it. > Vault.sh have -t, --create-keystore parameter for create new keystore when it doesn't exist. > But we need define KEY_SIZE too in other case KEY_SIZE = 128 is used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should just DTRT and return a list

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-1558: ----------------------------------- [~harald.pehl] do you have any concerns if we change the return values for this? (Let me know if you need more info, or we can chat in hipchat). > read-children-names on server-group deployments returns empty list, when it should just DTRT and return a list > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) > See OperationContextImpl.readResourceFromRoot for /server-group=* > The OSHs are based on AbstractMultiTargetHandler. > Output should be something like: > { > "outcome" => "success", > "result" => [ > { > "address" => [("server-group" => "main-server-group")], > "outcome" => "success", > "result" => ["simple-servlet.war"] > } > }, > { > "address" => [("server-group" => "other-server-group")], > "outcome" => "success", > "result" => > "result" => ["simple-servlet.war"] > } > ] > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should just DTRT and return a list

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1558: ------------------------------ Summary: read-children-names on server-group deployments returns empty list, when it should just DTRT and return a list (was: read-children-names on server-group deployments returns empty list, when it should probably fail.) > read-children-names on server-group deployments returns empty list, when it should just DTRT and return a list > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) > See OperationContextImpl.readResourceFromRoot for /server-group=* > The OSHs are based on AbstractMultiTargetHandler. > Output should be something like: > { > "outcome" => "success", > "result" => [ > { > "address" => [("server-group" => "main-server-group")], > "outcome" => "success", > "result" => ["simple-servlet.war"] > } > }, > { > "address" => [("server-group" => "other-server-group")], > "outcome" => "success", > "result" => > "result" => ["simple-servlet.war"] > } > ] > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should probably fail.

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1558: ------------------------------ Description: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) See OperationContextImpl.readResourceFromRoot for /server-group=* The OSHs are based on AbstractMultiTargetHandler. Output should be something like: { "outcome" => "success", "result" => [ { "address" => [("server-group" => "main-server-group")], "outcome" => "success", "result" => ["simple-servlet.war"] } }, { "address" => [("server-group" => "other-server-group")], "outcome" => "success", "result" => "result" => ["simple-servlet.war"] } ] } was: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) See OperationContextImpl.readResourceFromRoot for /server-group=* The OSHs are based on AbstractMultiTargetHandler. > read-children-names on server-group deployments returns empty list, when it should probably fail. > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) > See OperationContextImpl.readResourceFromRoot for /server-group=* > The OSHs are based on AbstractMultiTargetHandler. > Output should be something like: > { > "outcome" => "success", > "result" => [ > { > "address" => [("server-group" => "main-server-group")], > "outcome" => "success", > "result" => ["simple-servlet.war"] > } > }, > { > "address" => [("server-group" => "other-server-group")], > "outcome" => "success", > "result" => > "result" => ["simple-servlet.war"] > } > ] > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should probably fail.

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1558: ------------------------------ Description: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) See OperationContextImpl.readResourceFromRoot for /server-group=* The OSHs are based on AbstractMultiTargetHandler. was: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) See OperationContextImpl.readResourceFromRoot for /server-group=* > read-children-names on server-group deployments returns empty list, when it should probably fail. > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) > See OperationContextImpl.readResourceFromRoot for /server-group=* > The OSHs are based on AbstractMultiTargetHandler. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should probably fail.

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1558: ------------------------------ Description: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) See OperationContextImpl.readResourceFromRoot for /server-group=* was: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error. See OperationContextImpl.readResourceFromRoot for /server-group=* > read-children-names on server-group deployments returns empty list, when it should probably fail. > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error, or the right answer ;) > See OperationContextImpl.readResourceFromRoot for /server-group=* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should probably fail.

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1558?page=com.atlassian.jira.plugi... ] Ken Wills updated WFCORE-1558: ------------------------------ Description: Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error. See OperationContextImpl.readResourceFromRoot for /server-group=* was:Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error. > read-children-names on server-group deployments returns empty list, when it should probably fail. > ------------------------------------------------------------------------------------------------- > > Key: WFCORE-1558 > URL: https://issues.jboss.org/browse/WFCORE-1558 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error. > See OperationContextImpl.readResourceFromRoot for /server-group=* -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1558) read-children-names on server-group deployments returns empty list, when it should probably fail.

by Ken Wills (JIRA)

Ken Wills created WFCORE-1558: --------------------------------- Summary: read-children-names on server-group deployments returns empty list, when it should probably fail. Key: WFCORE-1558 URL: https://issues.jboss.org/browse/WFCORE-1558 Project: WildFly Core Issue Type: Bug Reporter: Ken Wills Using a wildcard :read-children-names on deployments returns an empty list, when it should probably just return an error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 May 2016