Welcome to JGroups Discussions!

[belaban]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[sergei-d]

Hello Bela,

Firstly I wanted to thank you for the great product that you are developing.

I am playing around with JGroups (4.2.10 version) and have run into one issue.
I have a cluster with 2 nodes N1 and N2. They are communicating with each other via RPC sync calls.
The issue happens when there is a roundtrip call between 2 nodes. The calls get blocked and timed out.
Example:
N1 calls N2 (N1 is keeping connection open and waiting for response from N2)
N2 excepts the call from N1 and makes synchronous call back to N1 (it is expected that N1 responds back to N2 and N2 responds back to N1 to its original call)

In this situation first call (N1 to N2) never returns and fails with timeout error.

Is this by design that you cannot make a sync call to the original caller?
If I make N2 to N1 call on a separate thread then it works. But then N1 does not receive proper response.

Thanks,
Sergei

[sergei-d]

As for configuration I use this one https://github.com/belaban/JGroups/blob/master/conf/tcp-nio.xml (also tried with TCP). Instead of UFC and MFC I also use NFC_NB and MFC_NB

[belaban]

This sounds pretty much like a deadlock. Why don't you simply use a synchronous RPC? I don't grok the need for making a call back to the sender from the receiver... If you absolutely have to, you could make that second call OOB, then it would resolve the deadlock...

…

On 11.02.21 21:20, Siarhei Dzemidavets wrote: Hello Bela, Firstly I wanted to thank you for the great product that you are developing. I am playing around with JGroups (4.2.10 version) and have run into one issue. I have a cluster with 2 nodes N1 and N2. They are communicating with each other via RPC sync calls. The issue happens when there is a roundtrip call between 2 nodes. The calls get blocked and timed out. Example: N1 calls N2 (N1 is keeping connection open and waiting for response from N2) N2 excepts the call from N1 and makes synchronous call back to N1 (it is expected that N1 responds back to N2 and N2 responds back to N1 to its original call) In this situation first call (N1 to N2) never returns and fails with timeout error. Is this by design that you cannot make a sync call to the original caller? If I make N2 to N1 call on a separate thread then it works. But then N1 does not receive proper response. Thanks, Sergei — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#526 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADPZXMF5ZWD4QZ6JU6YAGTS6Q3Z7ANCNFSM4XCIPTLQ>.

-- Bela Ban | http://www.jgroups.org

[sergei-d]

Thank you. I did not think of OOB. That option seems to be working. Not sure about consequences of using OOB. I will need to do some tests.

As to the comments in the first part of your message, unfortunately, I am making changes to already existing application that has this design in place. I am just replacing RMI communication with JGroups to make the app running as a cluster on kubernetes.

[belaban]

The diff is that OOB messages are not ordered wrt the sender. You're getting the deadlock because N1's request being processed at N2 blocks the delivery of N1's response at N2. In other words, N2 gets 2 messages from N1 (a request and a response), but the second message cannot get delivered because the first message has not yet completed.
This is the default for regular messages in JGroups: they are delivered in the order in which the sender sent them. OOB changes this, consult the manual for details.

[sergei-d]

This makes complete sense. Thank you again for your help

[belaban]

Glad to be of help! Note that if you processed the request on a separate thread, the response would be able to be delivered. This just as another option...