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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
