Jürgen Westerkamp

Hi, regarding the errors in the configuration... message_processing_policy="0" : Sorry, that was a copy and paste failure. We're using the "submit" policy. The UNICAST3 was intentionally removed from the stack, because we don't need ordering and (re-)transmission of messages. But yeah, we try to use it as an mixture of client-server and peer-to-peer. Not all clients have to communicate between one another, essentially is the connection to the server/coordinator. Until the problem with the firewall,...

Hi, I'm using JGroups 5.2.11.Final for a cluster application with one coordinator and various satellite members. The satellite members are using the state transfer to get configuration data from the one coordinator. A connection between the satellites is not required. Due to multiple routers between the nodes, I've to use TCP connections between them. My configuration looks like this: <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups...

Hi, it turned out that the problem was the UNICAST3 protocol. The protocol tries to re-send every message to a reconnected cluster member before they are actually allowed to be merged as member into the cluster. This was the reason for all the SEQNO messages between the nodes. After we removed the protocol from the stack it works fine because in our application we don't need this feature.

Hi, I still try to find a solution for this problem. I'm currently analyzing the TRACE logs for the TCP protocol but still can't point out the reason why the two nodes need several minutes to merge again. When I restart the NODE_2 while both (NODE_1 = 1.1.1.1, NODE_2 = 1.1.1.2) are connected and everything is working fine. On both sides I see that a connection is established: NODE_1: 2019-01-17 09:51:55.089 [TQ-Bundl | ] TRACE TCP - 1.1.1.1:7800: failed connecting to 1.1.1.2:7800: java.net.SocketException:...

Hi, I still try to find a solution for this problem. I'm currently analyzing the TRACE logs for the TCP protocol but still can't point out the reason why the two nodes need several minutes to merge again. When I restart the NODE_2 while both (NODE_1 = 1.1.1.1, NODE_2 = 1.1.1.2) are connected and everything is working fine. On both sides I see that a connection is established: NODE_1: 2019-01-17 09:51:55.089 [TQ-Bundl | ] TRACE TCP - 1.1.1.1:7800: failed connecting to 1.1.1.2:7800: java.net.SocketException:...

Hi, I'm using JGroups 4.0.15.Final to implement a cluster application. Everything works fine when I startup the two nodes, they got connected and start working. But when I kill (SIGKILL) one node and restart it, the nodes wont join together anymore. I've tried to find the problem for hours but I just can't find it. Sometimes the nodes got connected again after several connection attempts but that can take from few minutes to over an hour. I think it has something to do with the reincarnation problem...

Hi, I'm using JGroups 4.0.15.Final to implement a cluster application. Everything works fine when I startup the two nodes, they got connected and start working. But when I kill (SIGKILL) one node and restart it, the nodes wont join together anymore. I've tried to find the problem for hours but I just can't find it. Sometimes the nodes got connected again after several connection attempts but that can take from few minutes to over an hour. I think it has something to do with the reincarnation problem...