[zeromq-dev] ROUTER->DEALER upon same dealer reconnect causing message to go 'pending' and causing router->dealer connection to term.
Dowd, Brian
Brian.Dowd at commerzbank.com
Tue Oct 2 18:20:05 CEST 2012
Hi All,
I have an issue in Linux OS, with java bindings, with a server-client pair I'd written where the topology was as folllows:
server client
ROUTER -----------> DEALER - socket-1
DEALER <----------- ROUTER - socket-2
I had issues with this and changed it to:
server client
ROUTER -----------> DEALER
PULL <----------- PUSH
I also had the same issues with this so changed it to:
server client
PUB -----------> SUB
PULL <----------- PUSH
This worked (for TCP traffic, but IPC fails as does using TCP over loopback...).
However, strangely they all fail in seemingly the same way:
1. I start up my server.
2. I start up the client - it sends in a login-request.
3. Login-request is read by the server
4. The server sends a login-response back to the client.
This works OK the first time, then subsequently when I kill and restart that-specific client with the same dealer identity,
the Login-response never makes it down to the client as that pipe is terminated ....
I read the guide, and checked JIRA and could not see anything like this ...
I also tried version 2.2.0 and it fails in the same way ...
I also tried this on a much simpler test-version and it works (perhaps my simple test version is missing something simple
but I dont believe so - as it does a login-req (client->server) and a login-resp the other way, then heartbeats....)
I cannot understand why anything in my more comprehensive version can be affecting this, so I started adding some debug messages into the
C++ library and rebuilding it (version 3.2.0-rc1)...
In C++ land I found:
- The server->client response gets as far as router.cpp::xsend()
- It looks like the msg "state" on the outbound pipe is being set to "pending"
- It looks like the msg for sending is pending because the previous zmq.cpp:zmq_msg_recv() call
results in some kind of terminate command being propogated to the command handler and causing a pipe term to
be called ie pipe.cpp:process_pipe_term() from the zmq_msg_recv() (I could not get a decent stacktrace unfortunately).
Any help/assistance would be much appreciated.
Chers,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121002/7e0e66d9/attachment.htm>
More information about the zeromq-dev
mailing list