Hi *!
I found the bug that I thought to be caused by
EINTR:
The EINTR-thingy was gone, when I fixed some illegal refference
usages, that the gcc compiler didn't complain about (but clang of LLVM
did ;o)
... the lost messages problem was still there.
BUT: when I
switched from ZMQ2 to
In CZMQ v3 the context is hidden and zctx is deprecated.
However if you use the old CZMQ v2 API, or you use the libzmq API
directly, you should be able to use multiple contexts safely.
If you've a short example that shows the problem, we can investigate.
-Pieter
On Tue, Jan 27, 2015 at 10:05
another related thing buthers me in this context:
When zmsg_send()
indeed returns with rc==-1 and a NULLed message (data is definitely
lost) I have a chance to check for this lost message (simply asserting
on rc==-1 message==NULL).
BUT (!!) what is with zmsg_recv() ?
Situation: I
I've fixed the error in zmsg and in zframe, see
https://github.com/zeromq/czmq/pull/886
On Fri, Jan 9, 2015 at 10:46 AM, Pieter Hintjens p...@imatix.com wrote:
Can you make a minimal reproducible test case?
On Fri, Jan 9, 2015 at 9:41 AM, sven.koebn...@t-online.de wrote:
another related
Can you make a minimal reproducible test case?
On Fri, Jan 9, 2015 at 9:41 AM, sven.koebn...@t-online.de wrote:
another related thing buthers me in this context:
When zmsg_send() indeed returns with rc==-1 and a NULLed message (data is
definitely lost) I have a chance to check for this lost
the referenced fix should work for zmsg_send() but the same bug is
in zmsg_recv() and there the application does not (yet) have any data.
zmsg_recv() destroyes properly received frames 1 to n-1 if receiving
frame n failes. Since the data is ONLY inside ZMQ at this time, the
application cannot
In theory you cannot get an error between frames. Also, EINTR means
the process is shutting down, so the benefit of retrying seems vague.
Can you provide a reproducible test case? I do not like discussing
abstracts we cannot actually disprove.
On Fri, Jan 9, 2015 at 12:08 PM,
I get that error only during debuging inside Eclipse C++ (gdb).
It
seems irrelevant, if there are breakpoints set or not (but if there are
any breakpoints, that stop the program, the number of EINTR is
significantly higher).
I also wonder about getting EINTR because of a
debugger. Thet is
I now use some code doublicate of your cmzq code, that does frame
send()ing with REUSE and retries in case of EINTR:
I copied
zmsg_recv() and wrapped the frame receiving in a loop checking EINTR.
zmsg_t *zmsg_recv (void *source)
{
assert (source);
zmsg_t *self =
zmsg_new ();
if (!self)
On Fri, Jan 9, 2015 at 1:25 PM, sven.koebn...@t-online.de wrote:
I get that error only during debuging inside Eclipse C++ (gdb).
Makes sense. The debugger is sending interrupt signals. It's going to
make a mess of any logic that uses them. I don't think you can make
the code robust against
Just a guess, are any watchpoints set in the debugging session?
On Friday, January 9, 2015, sven.koebn...@t-online.de wrote:
I get that error only during debuging inside Eclipse C++ (gdb).
It seems irrelevant, if there are breakpoints set or not (but if there are
any breakpoints, that stop
Hi * !
I recently switched from ZMQ2 (pretty old) to ZMQ 4 and
since then have some problems in debugging with EINTR.
Following code:
do {
rc = zmsg_send (zrep, clsocket_);
if (rc0) {
if (errno ==
EINTR || errno == EAGAIN) {
logWarn(temporary failure in zmq send()
... will be tried
12 matches
Mail list logo
