Re: [zeromq-dev] lost message due to EINTR

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 successf

[zeromq-dev] Bug found: lost message due to EINTR

Sorry for spamming with the third mail today ... I had a look into your implementation of zmsg_send() and there indeed is alogical bug: sorry for sending the third mail today ... I had a look into your implementation of zmsg_send() and indeed found a logical bug. The following code assur

Re: [zeromq-dev] Should I use socket option ZMQ_TCP_ACCEPT_FILTER in ZeroMQ 4.0?

I'd say write that it is deprecated. One should use the ZAP API as it's more flexible and allows for more configuration. As soon as the ZAP API is available, encourage your user to use it over other means of filtering / securing connection. At least that's my opinion. On Thu, Jan 8, 2015 at 3:35

Re: [zeromq-dev] Understanding Broker

You can change anything you like. Be clear about the semantics however. The load balancing broker is sending requests for action to workers. It's not a symmetric flow. On Fri, Jan 9, 2015 at 6:24 AM, Kenneth Adam Miller wrote: > Can the mechanism of load balancing broker be changed so that exactl

Re: [zeromq-dev] lost message due to EINTR

Can you make a minimal reproducible test case? On Fri, Jan 9, 2015 at 9:41 AM, 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 message (simply > asse

Re: [zeromq-dev] Bug found: lost message due to EINTR

On Fri, Jan 9, 2015 at 10:05 AM, wrote: > I had a look into your implementation of zmsg_send() and there indeed is > alogical bug: > The following code assures, that the message gets destroyed allways, even if > an > error occurred in some frame Indeed. This isn't correct. I will fix that. Ho

Re: [zeromq-dev] lost message due to EINTR

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 wrote: > Can you make a minimal reproducible test case? > > On Fri, Jan 9, 2015 at 9:41 AM, wrote: >> another related thing buthers me in this context: >> >>

Re: [zeromq-dev] Should I use socket option ZMQ_TCP_ACCEPT_FILTER in ZeroMQ 4.0?

Bindings should probably just ignore deprecated options unless there's an explicit reason to support them. On Fri, Jan 9, 2015 at 10:31 AM, Arnaud Kapp wrote: > I'd say write that it is deprecated. > One should use the ZAP API as it's more flexible and allows for more > configuration. > > As soo

Re: [zeromq-dev] lost message due to EINTR

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

Re: [zeromq-dev] lost message due to EINTR

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, wrote: > the refer

Re: [zeromq-dev] lost message due to EINTR

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 no

Re: [zeromq-dev] lost message due to EINTR

On Fri, Jan 9, 2015 at 1:25 PM, 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 this, nor would it be a good

Re: [zeromq-dev] lost message due to EINTR

Hi, GDB uses SIGSTOP and SIGCONT to generate traces. Those signals were the reason for the EINTR error in my case. It is a GDB behavior, so inside/outside Eclipse, the result will be the same. Regards. On Fri, Jan 9, 2015 at 9:37 AM, Pieter Hintjens wrote: > On Fri, Jan 9, 2015 at 1:25 PM, w

Re: [zeromq-dev] lost message due to EINTR

Just a guess, are any watchpoints set in the debugging session? On Friday, January 9, 2015, 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 the program, the numbe

Re: [zeromq-dev] lost message due to EINTR

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)

Re: [zeromq-dev] Understanding Broker

I thought that the tidbits that were being received on the end of the broker at the front end and backend (I'm talking about how in the guide it refers to some of what is received as address and empty) were required because of something to do with ZMQ internals-as though the address received, and t

Re: [zeromq-dev] Understanding Broker

Because, I was confused as to how Router sockets could continue an exchange with a single REQ socket in a common context; I thought that they had to obey some kind of semantics similar to REQ/REP-you send one and you recv one... It just remembers who all connects to it? On Fri, Jan 9, 2015 at 11:5

[zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

I would like to propose removing this option before it becomes part of an officially released API, but I would like to reassurance that this is an appropriate course of action before doing so. My reasoning for removing it is as follows - * It is the only option to zmq_getsockopt() that treats opt

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Sounds good. On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers wrote: > I would like to propose removing this option before it becomes part of an > officially released API, but I would like to reassurance that this is an > appropriate course of action before doing so. > > My reasoning for removing i

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Excellent, I submitted issue 1296 to capture it. I will put together the pull req over the weekend. On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens wrote: > Sounds good. > > On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers > wrote: > > I would like

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Great :-) On Fri, Jan 9, 2015 at 6:38 PM, Thomas Rodgers wrote: > Excellent, I submitted issue 1296 to capture it. I will put together the > pull req over the weekend. > > On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens wrote: >> >> Sounds good. >> >> On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodg

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Hello, I agree that this option is weird, and it's behavior not properly defined (the fd_t stuff). However, shouldn't we mark this option as deprecated instead, and remove it in a later version? On Fri, Jan 9, 2015 at 6:43 PM, Pieter Hintjens wrote: > Great :-) > > On Fri, Jan 9, 2015 at 6:38 PM

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

I guess my question is, since 4.1 hasn't been 'released' and is still an rc, can we just avoid the potential downstream heartache all together and remove it? I'm also fine just marking deprecated and reverting my size check change. On Fri, Jan 9, 2015 at 12:02 PM, Arnaud Kapp wrote: > Hello, >

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015: > Hello, > > I agree that this option is weird, and it's behavior not properly > defined (the fd_t stuff). > However, shouldn't we mark this option as deprecated instead, and > remove it in a later version? It wasn't part of an

[zeromq-dev] New clrzmq, Add it to github?

Hello World, I've made a completely new clrzmq. You can see results in clrzmq-test - especially when running ./ZeroMQ.Text.exe --frontend=tcp://192.168.1.10:2772 --backend=tcp://192.168.1.10:2773 PubSubDevice Edward Ulrich on one machine and on another ./ZeroMQ.Test.exe --client=+ --backend=t

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

Thomas Rodgers schreef op de 9e dag van de louwmaand van het jaar 2015: > I guess my question is, since 4.1 hasn't been 'released' and is still an > rc, can we just avoid the potential downstream heartache all together and > remove it? Seems sensible to me. The same goes for the socket options

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

> I'm also fine just marking deprecated and reverting my size check change. No don't do this! Preventing memory corruption can only be a good thing. > It wasn't part of any release (except pre-release). Oh I didn't realize it was that new. Well in that case, if we're going to remove it we might

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

> > > I'm also fine just marking deprecated and reverting my size check change. > > No don't do this! Preventing memory corruption can only be a good thing. I agree, but basically makes it completely unusable in certain use cases (as you so eloquently put it, this option is 'weird'). Anyway, unl

Re: [zeromq-dev] New clrzmq, Add it to github?

Nice. I've added you to the ZeroMQ owners team, so you can rename your repo. Since there's already two older clrzmq bindings, we should think about unique names here. Perhaps rename it to clrzmq3 in the meantime. See https://github.com/zeromq/clrzmq -Pieter On Fri, Jan 9, 2015 at 7:10 PM, Uli R

Re: [zeromq-dev] New clrzmq, Add it to github?

Hello Pieter, I'm going to name it clrzmq4, because of the libzmq version I'm using. How to continue now, do you fork it? - Uli Am 09.01.2015 um 19:25 schrieb Pieter Hintjens: > Nice. I've added you to the ZeroMQ owners team, so you can rename your repo. > > Since there's already two older clrzm

Re: [zeromq-dev] New clrzmq, Add it to github?

The instructions are explained on http://zeromq.org/docs:organization You rename the repository, and from then on you fork back to your own account and work with pull requests. You will want to specify a license (I suggest MPLv2) and your contribution process (C4.1) in your README. Then you will w