JeroMQ is a pure Java implementation of the ZeroMQ messaging library, offering high-performance asynchronous messaging for distributed or concurrent applications.
I’m seeing an issue with an expected DISCONNECTED event not received. I instantiate one client/server in PUB/SUB mode. Set following options for sockets:
ZMQ_HEARTBEAT_IVL = 5 sec
ZMQ_HEARTBEAT_TIMEOUT = 15 sec
ZMQ_HEARTBEAT_TTL = 0
ZMQ_LINGER = 0
Also attach a monitor to the created sockets. I can subscribe and receive data with no problem.
But then if I block trafficon the remote server via iptables like that:
_sudo iptables -A OUTPUT -p tcp -m tcp -d client_ip --dport clientport -j DROP
I would expect to get a DISCONNECTED notification from socket monitor in the client but I don’t (I see ZMQ automatically sends a UNSUBSCRIBE message to the server, so it’s able to detect it doesn’t receive HB though). What it looks strange to me is that if I unblock traffic on the same channel via iptables like that:
sudo iptables -D OUTPUT 1
after some time I get the missing DISCONNECTED notification from monitor, and immediately after a chain of following notifications too: CONNECT_RETRIED -> CONNECT_DELAYED -> CONNECTED
So it looks like DISCONNECTED is somehow stuck and is sent out only after traffic is unblocked.
Also I’ve noticed that after blocking the traffic the affected port remains for a long time in the FIN state:
FIN-WAIT-1 0 170 10.139.181.115:6690 10.139.172.40:40400
Is that expected behavior? Is there some socket option settings I should have applied here? I’ve also tried setting ZMQ_SNDHWM = 0, ZMQ_RCVHWM = 0, but got same results.
I have used JeroMQ rel 0.5.2, but got the same result with 0.6.0 too.
Also noticed that I if I use cppzmq C++ binding for libzmq in the same environment I do receive the DISCONNECTED notification from the monitor when traffic is blocked in the same way via iptables, I don’t need to unblock it.
I’m seeing an issue with an expected DISCONNECTED event not received. I instantiate one client/server in PUB/SUB mode. Set following options for sockets: ZMQ_HEARTBEAT_IVL = 5 sec ZMQ_HEARTBEAT_TIMEOUT = 15 sec ZMQ_HEARTBEAT_TTL = 0 ZMQ_LINGER = 0 Also attach a monitor to the created sockets. I can subscribe and receive data with no problem.
But then if I block trafficon the remote server via iptables like that: _sudo iptables -A OUTPUT -p tcp -m tcp -d client_ip --dport clientport -j DROP
I would expect to get a DISCONNECTED notification from socket monitor in the client but I don’t (I see ZMQ automatically sends a UNSUBSCRIBE message to the server, so it’s able to detect it doesn’t receive HB though). What it looks strange to me is that if I unblock traffic on the same channel via iptables like that: sudo iptables -D OUTPUT 1
after some time I get the missing DISCONNECTED notification from monitor, and immediately after a chain of following notifications too: CONNECT_RETRIED -> CONNECT_DELAYED -> CONNECTED So it looks like DISCONNECTED is somehow stuck and is sent out only after traffic is unblocked.
Also I’ve noticed that after blocking the traffic the affected port remains for a long time in the FIN state: FIN-WAIT-1 0 170 10.139.181.115:6690 10.139.172.40:40400
Is that expected behavior? Is there some socket option settings I should have applied here? I’ve also tried setting ZMQ_SNDHWM = 0, ZMQ_RCVHWM = 0, but got same results. I have used JeroMQ rel 0.5.2, but got the same result with 0.6.0 too.
Also noticed that I if I use cppzmq C++ binding for libzmq in the same environment I do receive the DISCONNECTED notification from the monitor when traffic is blocked in the same way via iptables, I don’t need to unblock it.