JGroups Activity
Brought to you by:
belaban
Activity for JGroups
-
Jürgen Westerkamp posted a comment on discussion Help
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,...
-
Bela Ban posted a comment on discussion Help
First off: this config isn't correct: message_processing_policy="0" will not create a MessageProcessingPolicy (has to be "submit" or "max" (default)), so incoming messages will get dropped, with an exception If UNICAST3 is removed, messages will indeed get received in the right order, but the thread pool might reorder their delivery, so correct ordering is not guaranteed The big problem here is that you're using JGroups in a client-server mode, which is not what the idea is: peer-to-peer. Various...
-
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...
-
On 15.09.21 12:45, Rainer Stransky wrote: I am using a small Notification application based on "JGroups V5.0.0 Final" in a small office Windows 10 network. All worked perfect. Since a view weeks ago a new security policy has now enabled the Windows 10 firewall and my notification application was not able to find the other instances. I have now changed the Windows 10 firewall settings. In the extended setting I changed the incoming rules for the used "OpenJDK Platform binary" to allow incomming connections....
-
Rainer Stransky posted a comment on discussion javagroups-users
I am using a small Notification application based on "JGroups V5.0.0 Final" in a small office Windows 10 network. All worked perfect. Since a view weeks ago a new security policy has now enabled the Windows 10 firewall and my notification application was not able to find the other instances. I have now changed the Windows 10 firewall settings. In the extended setting I changed the incoming rules for the used "OpenJDK Platform binary" to allow incomming connections. After this change it is now working...
-
You need to set this attribute directly in the GossipRouter: GossipRouter g=new GossipRouter(...); g.maxLength(100_000); On 19.05.21 19:50, Michael Cirioli wrote: One more question - my understanding is that the gossip router is used for TCP communication, so setting max_length on TCP_NIO2 (for example) should ensure that no messages larger than max_length actually get routed, right? Also, I am not sure if you should expect to be able to set max_length for <tcpgossip ...="">, it fails for me with...
-
On 19.05.21 17:48, Michael Cirioli wrote: Thanks for the quick turnaround! I've grabbed the latest (4.2.15) and I am now able to use the new attribute. My simple test shows that it is working as expected! Excellent! Bear in mind that the main use case was that a (possibly malicious) service connects to a JGroups port incidentally, and should not cause the service to allocate too much memory. Cheers, thanks again -mike cirioli On 5/19/2021 8:57:12 AM, Michael Cirioli mikecirioli@gmail.com mikecirioli@gmail.com...
-
Michael Cirioli posted a comment on discussion Help
One more question - my understanding is that the gossip router is used for TCP communication, so setting max_length on TCP_NIO2 (for example) should ensure that no messages larger than max_length actually get routed, right? Also, I am not sure if you should expect to be able to set max_length for <tcpgossip ...="">, it fails for me with </tcpgossip> java.lang.IllegalArgumentException: JGRP000001: configuration error: the following properties in TCPGOSSIP are not recognized: {max_length=64K} thanks...
-
Thanks for the quick turnaround! I've grabbed the latest (4.2.15) and I am now able to use the new attribute. My simple test shows that it is working as expected! thanks again -mike cirioli On 5/19/2021 8:57:12 AM, Michael Cirioli mikecirioli@gmail.com wrote: Bela - lol, no worries! it happens to the best of us :) Thank you! -mike cirioli On 5/19/2021 2:17:23 AM, Bela Ban belaban@users.sourceforge.net wrote: Hi Michael I'm embarassed: max_length is only used by GossipRouter, but not by either TCP...
-
Note that I just released 4.2.15.Final. Should take ~1hr to sync to maven central. Cheers, On 19.05.21 15:27, Michael Cirioli wrote: Bela - lol, no worries! it happens to the best of us :) Thank you! -mike cirioli On 5/19/2021 2:17:23 AM, Bela Ban belaban@users.sourceforge.net belaban@users.sourceforge.net wrote: Hi Michael I'm embarassed: max_length is only used by GossipRouter, but not by either TCP or TCP_NIO2! :-) I created [1] to change this. Cheers, [1] https://issues.redhat.com/browse/JGRP-2559...
-
Bela - lol, no worries! it happens to the best of us :) Thank you! -mike cirioli On 5/19/2021 2:17:23 AM, Bela Ban belaban@users.sourceforge.net wrote: Hi Michael I'm embarassed: max_length is only used by GossipRouter, but not by either TCP or TCP_NIO2! :-) I created [1] to change this. Cheers, [1] https://issues.redhat.com/browse/JGRP-2559 [https://issues.redhat.com/browse/JGRP-2559] On 18.05.21 23:56, Michael Cirioli wrote: I am using org.jgroups:jgroups:jar:4.2.14.Final, my configuration file...
-
Hi Michael I'm embarassed: max_length is only used by GossipRouter, but not by either TCP or TCP_NIO2! :-) I created [1] to change this. Cheers, [1] https://issues.redhat.com/browse/JGRP-2559 On 18.05.21 23:56, Michael Cirioli wrote: I am using org.jgroups:jgroups:jar:4.2.14.Final, my configuration file looks like this excerpt: <config xmlns="urn:org:jgroups" ="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="urn:org:jgroups <a href=" http:="" www.jgroups.org="" schema=""...
-
Running ant make-schema and examining the .xsd it produced and it also doesn't list a max_length attribute. On 5/18/2021 4:54:18 PM, Michael Cirioli mikecirioli@gmail.com wrote: I am using org.jgroups:jgroups:jar:4.2.14.Final, my configuration file looks like this excerpt: <config xmlns="urn:org:jgroups" ="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="urn:org:jgroups <a href=" http:="" www.jgroups.org="" schema="" jgroups.xsd"="">http://www.jgroups.org/schema/JGroups.xsd"></config>...
-
I am using org.jgroups:jgroups:jar:4.2.14.Final, my configuration file looks like this excerpt: <config xmlns="urn:org:jgroups" ="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="urn:org:jgroups <a href=" http:="" www.jgroups.org="" schema="" jgroups.xsd"="">http://www.jgroups.org/schema/JGroups.xsd"></config> <TCP_NIO2 recv_buf_size="${tcp.recv_buf_size:128K}" send_buf_size="${tcp.send_buf_size:128K}" max_bundle_size="64K" sock_conn_timeout="300" max_length="100K" thread_pool.enabled="true"...
-
Do you have the correct version? You need at least 4.2.11. What does the error say? On 16.05.21 21:03, Michael Cirioli wrote: Which configuration sections accept that parameter? I assume tcp and nio, but my app doesn't start due to an error saying invalid attributes. Thanks -mike On Sun, May 16, 2021, 2:17 PM Bela Ban belaban@users.sourceforge.net belaban@users.sourceforge.net wrote: The attribute is max_length Bela Ban -------- Original message -------- From: Michael Cirioli mikecirioli@users.sourceforge.net...
-
Which configuration sections accept that parameter? I assume tcp and nio, but my app doesn't start due to an error saying invalid attributes. Thanks -mike On Sun, May 16, 2021, 2:17 PM Bela Ban belaban@users.sourceforge.net wrote: The attribute is max_length Bela Ban -------- Original message -------- From: Michael Cirioli mikecirioli@users.sourceforge.net Date: Fri, May 14, 2021, 11:11 PM To: "[javagroups:discussion] " 18795@discussion.javagroups.p.re.sourceforge.net Subject: [javagroups:discussion]...
-
The attribute is max_lengthBela Ban -------- Original message --------From: Michael Cirioli <mikecirioli@users.sourceforge.net>Date: Fri, May 14, 2021, 11:11 PMTo: "[javagroups:discussion] " <18795@discussion.javagroups.p.re.sourceforge.net>Subject: [javagroups:discussion] Configuration example for how to cap max data read by TcpConnection or NioConnectionFrom what I can tell, its not listed in any .xsd and therefore my test app won't even start. Configuration example for how to cap max data read...
-
From what I can tell, its not listed in any .xsd and therefore my test app won't even start.
-
I am trying to understand how i adjust my configuration to take advantage of the fix for JGRP-2523 but am unable to figure out what element the new attribute should be applied to in my configuration. Here is my sample config: <!-- HA setup; may be overridden with $JENKINS_HOME/jgroups.xml --> <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups-4.0.xsd"> <TCP_NIO2 recv_buf_size="${tcp.recv_buf_size:128K}"...
-
I am trying to understand how i adjust my configuration to take advantage of the fix for JGRP-2523 but am unable to figure out what element the new attribute should be applied to in my configuration. Here is my sample config: <!-- HA setup; may be overridden with $JENKINS_HOME/jgroups.xml --> <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups-4.0.xsd"> <TCP_NIO2 recv_buf_size="${tcp.recv_buf_size:128K}"...
-
Subhash C posted a comment on discussion Help
Hi @belaban, I don't support such an old version. IIRC, the issue you've run into has been fixed a while ago, don't remember in which version. Yes, i think it is fixed as part of https://issues.redhat.com/browse/JGRP-2092. Versions: 3.6.11, 4.0 Thanks, Subhash C
-
Hi Subhash I don't support such an old version. IIRC, the issue you've run into has been fixed a while ago, don't remember in which version. Regards On 12.01.21 3:30 pm, Subhash C wrote: Hi Bela Ban, Thanks for your reply. First off, I highly recommend to upgrade to a newer version (3.6.7 is 4+ years old)... We have maintaining this version to support an old version of application If the particular packet with the new view is missed by any member, Will the coordinator resend the view again to that...
-
Hi @belaban Thanks for your reply. First off, I highly recommend to upgrade to a newer version (3.6.7 is 4+ years old)... We have maintaining this version to support an old version of application If the particular packet with the new view is missed by any member, Will the coordinator resend the view again to that member? Yes If the coordinator resends the view then will that call invoke the ReceiverAdapter set in the channel? yes Thank you very much for confirming the behavior. This makes us difficulty...
-
Hi Bela Ban, Thanks for your reply. First off, I highly recommend to upgrade to a newer version (3.6.7 is 4+ years old)... We have maintaining this version to support an old version of application If the particular packet with the new view is missed by any member, Will the coordinator resend the view again to that member? Yes If the coordinator resends the view then will that call invoke the ReceiverAdapter set in the channel? yes Thank you very much for confirming the behavior. This makes us difficulty...
-
Hi Bela Ban, Thanks for your reply. First off, I highly recommend to upgrade to a newer version (3.6.7 is 4+ years old)... We have maintaining this version to support an old version of application If the particular packet with the new view is missed by any member, Will the coordinator resend the view again to that member? Yes If the coordinator resends the view then will that call invoke the ReceiverAdapter set in the channel? yes Thank you very much for confirming the behavior. This makes us difficulty...
-
First off, I highly recommend to upgrade to a newer version (3.6.7 is 4+ years old)... Comments inline On 12.01.21 2:16 pm, Subhash C wrote: In our code, we have attached custom org.jgroups.ReceiverAdapter to the channel for the callback. private JChannel channel = new JChannel(is) channel.setReceiver(new JGroupsListener()); class JGroupsListener extends ReceiverAdapter { @Override publicvoidviewAccepted(finalViewview){ viewChange(view); } @Override publicvoidreceive(finalMessagemessage){ processMessage(message);...
-
In our code, we have attached custom org.jgroups.ReceiverAdapter to the channel for the callback. private JChannel channel = new JChannel(is) channel.setReceiver(new JGroupsListener()); class JGroupsListener extends ReceiverAdapter { @Override public void viewAccepted(final View view) { viewChange(view); } @Override public void receive(final Message message) { processMessage(message); } } One of the members left the cluster, and the coordinator sent the new view to all existing members. But only...
-
Hi Cyndy removing use_fork_join_pool was a simplification; one less knob in the configuration and better maintainability of the code. This setting never yielded better performance, but only added complexity to the configuration. When you use virtual threads (use_fibers=true), the thread pools are ignored, and a new virtual thread is started each time. This is the recommended way to use virtual threads. Cheers On 30.10.20 10:14 pm, Cyndy Koobs wrote: I was wondering what the thought process was for...
-
Cyndy Koobs posted a comment on discussion Open Discussion
I was wondering what the thought process was for removing this configuration setting. I see (and remember reading somewhere) that the use of "virtual threads" is now supported in Loom but I don't see any way to change the type of thread pool as was possible in 4.x. Is there some way to do this that I have missed? We are using the Amazon JDK (Corretto) which doesn't have any virtual thread development as far as I can see. At least they are not advertising that.
-
Hi Bela, Sorry I didn't get this out earlier. Thank you so much for taking the time to respond and point me to the information I was looking for. It helped a lot. You were definitely right about the transition being trivial. It's a pretty nice library once you get a few concepts straight in your mind. Thank you again. Your response was greatly appreciated and very helpful, Cyndy Koobs On Wed, Oct 7, 2020 at 11:47 PM Bela Ban belaban@users.sourceforge.net wrote: The best place is JIRA [1]. For an...
-
The best place is JIRA [1]. For an overview, see [2] and [3]. 95% of you changes will be to change 'new Message(...)' into 'new BytesMessage(...)' or 'new ObjectMessage(...)'. The transition from 4 to 5 should be trivial. If you run into problems, don't hesitate to post them here. Cheers, [1] https://issues.redhat.com/projects/JGRP?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=released-unreleased [2] http://belaban.blogspot.com/2020/01/first-alpha-of-jgroups-50.html [3]...
-
I see that JGroups 5.0.4 was released recently. What are the major changes between this release and the last 4.0.x release? Are there release notes I could read?
-
I don't support 3.5; it is from 2014. BTW, your config is missing UNICAST2{3} On 07.08.20 14:17, reeta Aggarwal wrote: we are using jgroups-3.5.0.Final.jar yes we are using TCPPING as below we are passing current local host in initial_hosts , below is configuration at run time : 04Aug202016:31:14,842[main]DEBUG[JGroupsChannelProvider]initialize():usingthefollowingprotocolstack... 04 Aug 2020 16:31:14,842 [main] DEBUG [JGroupsChannelProvider] TCP(bind_addr=172.17.152.5;bind_port=6800):TCPPING(initial_hosts=172.17.152.7[6800];port_range=1;timeout=15000;num_initial_members=2):FD(timeout=7500;max_tries=2):VERIFY_SUSPECT(timeout=30000):pbcast.NAKACK2(use_mcast_xmit=false;discard_delivered_msgs=true):pbcast.STABLE(desired_avg_gossip=20000;stability_delay=2000):pbcast.GMS(join_timeout=5000;print_local_addr=false)...
-
reeta Aggarwal posted a comment on discussion Open Discussion
we are using jgroups-3.5.0.Final.jar yes we are using TCPPING as below we are passing current local host in initial_hosts , below is configuration at run time : 04 Aug 2020 16:31:14,842 [main] DEBUG [JGroupsChannelProvider] initialize(): using the following protocol stack... 04 Aug 2020 16:31:14,842 [main] DEBUG [JGroupsChannelProvider] TCP(bind_addr=172.17.152.5;bind_port=6800):TCPPING(initial_hosts=172.17.152.7[6800];port_range=1;timeout=15000;num_initial_members=2):FD(timeout=7500;max_tries=2...
-
On 07.08.20 07:55, sneha thakur wrote: Hi, We are getting this issue [TransferQueueBundler,controlChannelSAS_CLUSTER,LABECSAP01-60365] WARN [TCP] JGRP000032: LABECSAP01-60365: no physical address for 766961e5-ebd6-5e5f-6e27-e9321d827688, dropping message Every nodes has a cache, mapping UUIDs (like the one above) to IP addresses:ports. The cache is populated by the discovery protocol. In your case, the cache didn't have an entry for 766961e5-ebd6-5e5f-6e27-e9321d827688, which means JGroups was unable...
-
Hi, We are getting below issue ,after one of the node is rebooted [TransferQueueBundler,controlChannelSAS_CLUSTER,LABECSAP01-60365] WARN [TCP] JGRP000032: LABECSAP01-60365: no physical address for 766961e5-ebd6-5e5f-6e27-e9321d827688, dropping message .can you please provide the reason for this. if forcing jvm to use ipv4 stack as below will help?? -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false
-
Hi, We are getting this issue ,after one of the node is rebooted [TransferQueueBundler,controlChannelSAS_CLUSTER,LABECSAP01-60365] WARN [TCP] JGRP000032: LABECSAP01-60365: no physical address for 766961e5-ebd6-5e5f-6e27-e9321d827688, dropping message .can you please provide the reason for this. if forcing jvm to use ipv4 stack as below will help?? -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false
-
Hi, We are getting this issue [TransferQueueBundler,controlChannelSAS_CLUSTER,LABECSAP01-60365] WARN [TCP] JGRP000032: LABECSAP01-60365: no physical address for 766961e5-ebd6-5e5f-6e27-e9321d827688, dropping message after one of the node is rebooted .can you please provide the reason for this. if forcing jvm to use ipv4 stack as below will help?? -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false
-
JGroups released /JGroups/5.0.0.Final/jgroups-5.0.0.Final.jar
-
-
I guess DNS_PING for simple deployments. If you use cross-site (RELAY2) deployments, you'd want to use TUNNEL/GossipRouter, as described in my blog. On 01.07.20 18:17, Abhijeet wrote: Thanks Bela for quick help. I have tried DNS_PING and its working for me. Just a short question, Any preference, between using TCPPING, TCPGOSSIP or DNS_PING on K8S? Suggestion to Deploy Jgroup in Kubernetes https://sourceforge.net/p/javagroups/discussion/134002/thread/b0a6db3645/?limit=25#4929 Sent from sourceforge.net...
-
Abhijeet posted a comment on discussion javagroups-development
Thanks Bela for quick help. I have tried DNS_PING and its working for me. Just a short question, Any preference, between using TCPPING, TCPGOSSIP or DNS_PING on K8S?
-
On 23.06.20 07:53, Abhijeet wrote: Currently we are using JGroup 4.0.10 in our project using UDP and PING protocol [multicasting]. We are planning to create the docker image of our project and will deploy in K8S (Not using openShift etc). I am very new to K8S, and dont have very much deep understanding on same. While going through Github and forums I found TCP with DNS_PING is viable option to deploy in K8S. So using Jgroup version 4.1.9.Final in our project. Below is Protocol list I am using Protocol[]...
-
Currently we are using JGroup 4.0.10 in our project using UDP and PING protocol [multicasting]. We are planning to create the docker image of our project and will deploy in K8S (Not using openShift etc). I am very new to K8S, and dont have very much deep understanding on same. While going through Github and forums I found TCP with DNS_PING is viable option to deploy in K8S. So using Jgroup version 4.1.9.Final in our project. Below is Protocol list I am using Protocol[] protocolStack={ new TCP().setValue("bind_port",...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Heiko Tappe posted a comment on discussion Help
Tried 4.0.21.Final. Unfortunately without success.
-
Oops. Missed the method: org.jgroups.conf.XmlConfigurator.getInstance(Ljava/net/URL;) And it's correct. There is no getInstance with a URL param any more.
-
Tried with CENTRAL_LOCK2. Same behaviour. As for 4.1.8 - I don't know if I can just replace the jgroups wildfly module 4.0.19.Final with 4.1.8. First attempt gives me a java.lang.NoSuchMethodError: org.jgroups.conf.XmlConfigurator.getInstance(Ljava/net/URL;)Lorg/jgroups/conf/XmlConfigurator
-
Works for me, with CENTRAL_LOCK2 though... haven't looked at CENTRAL_LOCK for a while. Have you tried with 4.1.8? On 27.11.19 13:06, Heiko Tappe wrote: I see a different behaviour. Client 1 obviously does not release the lock if a tryLock of client 2 is busy. There is no error. But I can tell from calling printLocks afterwards. Without a running tryLock of client 2 releasing the lock works as expected. Join problems https://sourceforge.net/p/javagroups/discussion/18795/thread/ffd1a67189/?limit=25#8111/6404/c432...
-
I see a different behaviour. Client 1 obviously does not release the lock if a tryLock of client 2 is busy. There is no error. But I can tell from calling printLocks afterwards. Without a running tryLock of client 2 releasing the lock works as expected.
-
As for the mcast_addr - I found this in my wildfly socket bindings config and removed it: <socket-binding name="jgroups-diagnostics" multicast-address="${jboss.jgroups.diagnostics_addr:192.168.1.21}" multicast-port="${jboss.jgroups.diagnostics_port:7500}"/>
-
On 27.11.19 12:42, Heiko Tappe wrote: Oh. I just noticed that releasing the lock on client 1 does not succeed if client 2 is trying to get a lock with timeout. Is that the expected behaviour? Client1 holds lock X Client2 does a trylock X 20000 // 20secs Client1 unlocks X within 20 secs Client2 will be able to acquire lock X Join problems https://sourceforge.net/p/javagroups/discussion/18795/thread/ffd1a67189/?limit=25#8111 Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/javagroups/discussion/18795/...
-
On 27.11.19 12:40, Heiko Tappe wrote: Hmm. Things improved. A lot :-) But I am not exactly sure why. In the last tests I was so focused on the log messages ("Could not join ...") that I didn't check the lock functionality itself. And surprise - it works now, as far as I can tell! But the warnings in the log still remain. Perhaps you should post the full logs of the 2 members' startup One thing I noticed was some strange socket binding with a multi cast address of "192.168.1.21". Maybe things got...
-
Oh. I just noticed that releasing the lock on client 1 does not succeed if client 2 is trying to get a lock with timeout. Is that the expected behaviour?
-
Hmm. Things improved. A lot :-) But I am not exactly sure why. In the last tests I was so focused on the log messages ("Could not join ...") that I didn't check the lock functionality itself. And surprise - it works now, as far as I can tell! But the warnings in the log still remain. One thing I noticed was some strange socket binding with a multi cast address of "192.168.1.21". Maybe things got better after removing that. I will recheck... As for the lock functionality... What is the expected behaviour...
-
Try setting receive_on_all_interfaces to false, and use 4.1.8.Final
-
I switched to 232.5.5.5 with no success. netstat -nr gives me: IPv4-Routentabelle =========================================================================== Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.1.7 192.168.1.21 25 127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331 127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331 127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331 192.168.1.0 255.255.255.0 Auf Verbindung 192.168.1.21 281 192.168.1.21...
-
You probably have no route (netstat -nr will show you) from 192.168. to 224.. I suggest do not use 224.x.x.x, as routers may even discard application traffic to these addrs. I suggest use sth like 232.5.5.5 and perhaps add a route to it: sudo route add -net 232.0.0.0/5 192.168.1.21 On 27.11.19 9:00 AM, Heiko Tappe wrote: Here is what I got... I explicitly defined UDP like this: <udp mcast_port="${jgroups.udp.mcast_port:45588}" bind_addr="${jgroups.bind_addr:192.168.1.21}" mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"...
-
Here is what I got... I explicitly defined UDP like this: <UDP mcast_port="${jgroups.udp.mcast_port:45588}" mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}" bind_addr="${jgroups.bind_addr:192.168.1.21}" receive_on_all_interfaces="true" enable_diagnostics="true" /> When I start my server (Wildfly 17.0.1.Final) and call probe like this: $ java -cp jgroups-4.0.19.Final.jar -Djava.net.preferIPv4Stack=true org.jgroups.tests.Probe I get 0 responses (0 matches, 0 non matches) If I then init the LockService...
-
On 26.11.19 11:27 AM, Heiko Tappe wrote: Let's start with: I am a newbie to jgroups. So be patient with me ;-) always am... :-) What I try to achieve are distributed locks. Right now I do my first tests locally with one node. And some things seem to work already (a bit): I can get a lock and a second attempt in the same session (same lock service instance) to get a lock fails. But another instance of the lock service does not seem to "see" any locks held by the other "session". The problem might...
-
Let's start with: I am a newbie to jgroups. So be patient with me ;-) What I try to achieve are distributed locks. Right now I do my first tests locally with one node. And some things seem to work already (a bit): I can get a lock and a second attempt in the same session (same lock service instance) to get a lock fails. But another instance of the lock service does not seem to "see" any locks held by the other "session". The problem might be related to the warnings I see in the server log: WARN [org.jgroups.protocols.UDP]...
-
-
-
-
-
-
-
Apparently, the member whose log is shown below didn't receive any heartbeats from all of the 4 members for 14 secs and excluded them (after the double-check by VERIFY_SUSPECT). On 02.10.19 16:06, ankit kumar garg wrote: HI , The members are leaving the view in running system. Attaching the logs : could not understand the root cause or fix. pls help 2019-09-21 05:18:58.479 TRACE org.jgroups.protocols.UNICAST3 - seliics02331-8367 --> DATA(seliics02333-52690: #1760889, conn_id=6) 2019-09-21 05:18:58.479...
-
ankit kumar garg modified a comment on discussion javagroups-users
-
HI , The members are leaving the view in running system. Attaching the logs : could not understand the root cause or fix. pls help 2019-09-21 05:18:58.479 TRACE org.jgroups.protocols.UNICAST3 - seliics02331-8367 --> DATA(seliics02333-52690: #1760889, conn_id=6) 2019-09-21 05:18:58.479 TRACE org.jgroups.protocols.UDP - seliics02331-8367: sending msg to seliics02333-52690, src=seliics02331-8367, headers are UFC: CREDIT_REQUEST, UNICAST3: DATA, seqno=1760889, conn_id=6, TP: [cluster_name=TRAFFIC] 2019-09-21...
-
-
-
-
-
-
-
-
1 >