ZMQ socket - disconnect when all request are served

Question

I am trying to implement ZMQ REQ/REP model in Java

I have a Server-role, running on post 5564, which acts as Replier

ZMQ.Socket repSock = context.socket(ZMQ.REP);

I have a Client-role, running on post 5563

ZMQ.Socket syncclient = context.socket(ZMQ.REQ);

I have a proxy-server in middle, which passes request and response

ZMQ.proxy(reqSocket, repSocket, null);

Good thing about having a proxy is I can add multiple Servers

repSocket.connect("tcp://" + addr.getHostAddress() + ":" + port);

Which is working fine .

Now, when I remove a Server node from Proxy

repSocket.disconnect("tcp://" + addr.getHostAddress() + ":" + port);

Client gets stuck, as an request has being made and the REQ-socket waits for a response.

So the process stucks at syncclient.recvStr()

for (int request_nbr = 0; request_nbr < (request_nbr + 1); request_nbr++) {          

    syncclient.send(str.getBytes(),0);
    System.out.println("Send Dataaaa....... " );
    String data = syncclient.recvStr(Charset.defaultCharset());
    System.out.println(" here.. " +data);

    request_nbr++;
}  

I searched and couldn't find a way to track the REQ-socket

---

I need any one of 2 things:

1. A way to keep track on a Socket-instance, which I am about to disconnect, wait till all messages are processed, so that syncclient.recvStr() will not be blocked

2. A way to reset the syncclient-socket, so that I can keep getting REQ/REP respond without an interruption

Answer 1

In real-world scenarios, rather avoid using a blocking-mode of the ZeroMQ .send() / .recv() methods and better use .poll().

While this may require a bit more SLOCs of code, the results are leaving you in a control, whereas a blocking SLOC takes all the control from your code and you cannot do much about that until ( if at all ) a next message gets delivered. That's a very wrong design practice and except the most simplistic schoolbook examples, that are actually sort of anti-patterns for the real-world.

So, do not expect Question 2 to become somehow magically solved, this is not a part of ZeroMQ API ( for many rather aloud evangelisated reasons ). Better decide between .setsockopt( ZMQ.REQ_RELAXED, 1 ), if API version and context of use permits, or do not use the trivial REQ/REP pattern at all ( due it's known risk of falling into an unsalvageable mutual dead-lock ( ref. other my posts on this very subject, where this phenomenon was both illustrated and countless times explained ) ).

In a similar manner, asking Question 1 seems reasonable in cases you have never read the ZeroMQ specifications and/or documentation and ZeroMQ "Best Practices". Having spent some time in this, your options would be crystal-clear. There are none such tools for doing this built-in. One can add some add-on, if in a need to add any similar non-core logic for her/his own need. The only setting that indirectly influences the behaviour on aSocket.close() is available in .setsockopt( ZMQ.LINGER, 0 ), which may help to prevent a system from a transition into an effective hangup-state, once aSocket waits infinitely for a state that will never happen in cases, when a message-queue is still non-empty ( messages still waiting for getting delivered ).

Going into Distributed-Systems design is like entering a new world. No sequences are guarranteed ( non-serial code execution paths happen ). No means of any local control of remote entities, their states, their failures, their presence at all, their actual ZeroMQ API version.

Indeed a challenging world to enter into.

N.b.:
You might already know, that one can .connect() aSocket-instance ( better an Access Point to aSocket-instance ) to more than one remote ends without using the proxy. With some additional .setsockopt() tuning ZMQ.IMMEDIATE to a value of 1, will help better manage the round-robin distribution policy, irrespective of the transport-classes used for the actual message delivery ( { tcp:// | ipc:// | vmci:// | pgm:// | epgm:// | inproc:// } ). All that at your fingertips.