[JBoss JIRA] (JGRP-2382) JGroups version 4.0.13.Final.jar is causing memory leaks
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2382?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2382:
--------------------------------
As I said before, removing UNICAST3 is a bad idea and will break your application unless it
* tolerates unordered messages
* tolerates missing messages
> JGroups version 4.0.13.Final.jar is causing memory leaks
> --------------------------------------------------------
>
> Key: JGRP-2382
> URL: https://issues.jboss.org/browse/JGRP-2382
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.13
> Environment: AIX machine 7.1 with JDK 1.8
> Reporter: Rashmi Acharya
> Assignee: Bela Ban
> Priority: Major
> Attachments: dumps_TEST_node1_20190918_after_3_hours.zip, dumps_TEST_node1_20190918_right_after_restart.zip, dumps_TEST_node2_20190918_after_3_hours.zip, dumps_TEST_node2_20190918_right_after_restart.zip
>
>
> We are observing a constant memory growth and leak with JGroup version 4.0.13 ..
> One of our customer is having two node cluster environment and in one node we are observing org.Group.Messages which contain org.groups.Header and org.groups.Stack.ipAddress objects.. these are not getting cleared from memory..
> We dont see any exception related to Jgroups from logs and but it is causing a gradual emory growth and OOM.
> Here is the Jgroups cluster configuration we have:
> dynamic.cluster.property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT2;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000" />
> <FD_ALL timeout="20000" interval="15000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48" />
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000"/>
> <pbcast.GMS print_local_addr="true" join_timeout="15000" />
> </config>
> =================================
> dynamic.cluster.distribution_property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_port="&MULTICAST_NODE_PORT1;" />
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> </config>
> ================================
> dynamic.cluster.lock.protocolStack
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT3;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_ALL timeout="20000" interval="5000"/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="20000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> <FRAG2 frag_size="8096"/>
> <CENTRAL_LOCK2/>
> </config>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2274:
--------------------------------
Excellent!
I intend to add TLS support directly to BaseServer and subclasses, so this will take a bit of time, and only once I've released an initial 5.0. This won't be available in 4.x (unless someone backports it).
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.jboss.org/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ELY-1872) elytron-tool.sh usage with symbolic links
by Ivo Studensky (Jira)
[ https://issues.jboss.org/browse/ELY-1872?page=com.atlassian.jira.plugin.s... ]
Ivo Studensky updated ELY-1872:
-------------------------------
Labels: downstream_dependency (was: )
> elytron-tool.sh usage with symbolic links
> -----------------------------------------
>
> Key: ELY-1872
> URL: https://issues.jboss.org/browse/ELY-1872
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 2.0.0.Alpha4
> Environment: Red Hat JBoss Enterprise Application Platform (7.2.3)
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Major
> Labels: downstream_dependency
>
> It looks like elytron-tool.sh doesn't work well with symbolic links.
> The soft link becomes a credential store - in a "standard" file - with the newly added alias but the original credential store will not be updated.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (JGRP-2385) Node heartbeat checks are failing with TCP
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2385?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-2385.
--------------------------
Resolution: Rejected
3.4.0 was released 6 years ago: I don't support such an old version.
Besides, please use the forums or mailing list to ask questions, not JIRA!
Regards,
> Node heartbeat checks are failing with TCP
> ------------------------------------------
>
> Key: JGRP-2385
> URL: https://issues.jboss.org/browse/JGRP-2385
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.6.19
> Environment: Windows
> Reporter: Rashmi Acharya
> Assignee: Bela Ban
> Priority: Critical
>
> Hi Bela,
> One of our customer which is still on 3.4.0 Jgroups are facing issue with Node -Node cluster heartbeat communication with TCP.
> Node is not responding intermittently and moved out of cluster group (around 3 nodes as part of the cluster along with 3 container nodes)
> when port_range=0 setting, it works fine.. Can you please explain the significance of this with TCP option ? What is the recommended value which is suggested with Jgroups ?
> Here is the property String:
> jgroups_cluster.property_string=TCP(bind_addr=10.1.231.73;bind_port=8141):TCPPING(initial_hosts=10.1.231.73,10.1.231.10;port_range=1;timeout=5000;num_initial_members=2):MERGE2(min_interval=3000;max_interval=5000):FD_ALL(interval=5000;time
> out=20000):FD(timeout=5000;max_tries=48;level=ERROR):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(retransmit_timeout=100,200,300,600,1200,2400,4800;discard_delivered_msgs=true):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pb
> cast.GMS(print_local_addr=true;join_timeout=5000)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years