Hi all, I seem to have a problem getting one of our software to use zmq...
I have multiple clients which connect to a server and request some data. The server processes the requests and eventually sends back an acknowledge or some piece of data. What we did so far: for each new connecting client a thread was started which processed the request and sent the reply back (through the same TCP/IP socket). One problem is, from time to time it might take a while before the server can send back the data because he has to wait for an other (slow) process to make this data available. In our current implementation the client and his communication link just blocks until the requested data got available. I saw this example: http://www.zeromq.org/blog:multithreaded-server but I'm not sure how I can get this to scale up well with zmq and our application. I can create a number of threads at startup but what can I do when all threads happen to be in a blocked state and a new client (with a non blocking request) attempts to connect (and wants to get his answer back)? If I want to naively use the REQ/REP pattern and create a thread after recv() returns, how can I map the 'answer' of the thread (which might of course arrive in any order) to the respective send() ? One way could be to have some kind of resource manager and check when the number of unblocked threads gets too low and then start more threads. But this seems a bit too muck like a hack around for a standard problem. And I'm sure there must be an elegant way/pattern to design this problem with zmq!? Do I miss something? Does anyone has an idea? Thanks for any hints.. Regards, Jan _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
