[zeromq-dev] EINTR and company

sven.koebnick at t-online.de sven.koebnick at t-online.de
Fri Dec 19 10:33:41 CET 2014


 

Hi all and a merry christmas! 

I recently switched from ZMQ V2
(self compiled C++) to V4 installed as part of Linux-Distribution.


After several days of fixing the modified interfaces (classes formerly
delivered as "helper.cpp" and now are separately packaged etc.) the
system compiled fine and I had some effort to get a proper handling of
my LRU Queues etc. (wrapping, body-fetching, subscriptions etc.). 

The
code seems to be OK now (atleast as bugfree as the old code with ZMQ
V2). 

Formerly (using V2), I nearly never got EINTR-returns. Now, I get
plenty of them (not only in debugging, but also when just running
without any disturbance). I did what was recommented by compiler docu
etc.: I retryed, until sending, receiving or polling was a) successful
or b) delivered a real (not temporary) error (which only happens, when
it in deed should). 

BUT: now, I'm loosing messages. Sometimes they
just don't get through, debugging is very difficult as long as I don't
want to debug inside of ZMQ itself (I currently assume, that it's my
error and ZMQ works as it should do). 

The typical way, a request goes
is as follows: 

- requestor creates a google-protobuf message 

- this
gets serialized and sent through ZMQ to an (self-written) LRU-Queue 

-
the queue gives the message (through ZMQ) to one of several workers
(threads) 

- the worker parses the google-protobuf from it and call a
"real" worker function 

- at this point of time, this is a dispatcher
service that (optionally saves it to DB and) looks into the message
(request) 
 deciding what type of service has to deal with it and (e.g.)
if this is a request for 

 	* a single worker
 	* all workers of a
type
 	* one worker of each type
 	* all workers of all types

-
according to the decision, the message gets serialized again and sent to
the proper LRU-Queue (with the correct service type) according to an
internal service registry, that all dispatcher hold. The dispatcher
service waits for the answer. 

- again the message goes through an
LRU-queue to one (or several) workers 

- it (they) does something and
answer the request 

- now the reply goes through the LRU-Queue, back to
the (still waiting) dispatcher, through the dispatchers queue and
finally to the requestor. 

That sound pretty complicated, but worked
for two years now with ZMQ V2. At different positions the requests or
the answers get lost in ZMQ (!!!). I assume, I did something wrong, so
I'd like to ask, if s'one had the same problem and allready fixed it,
because I do not have anymore ideas where to look. A symptom is, that
for about 60-100 messages, I now get 10 to 15 EINTR returns and I guess,
that this has something to do with my lost messages. 

^5 

sven 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141219/dae07cd3/attachment.htm>


More information about the zeromq-dev mailing list