Re: [zeromq-dev] Strange problem binding inproc
Thanks. I knew I was doing something stupid. Jacques On 07/11/2014 12:55 PM, Pieter Hintjens wrote: > Zero is not an error. -1 is an error. >= 0 is success. > > In pretty much the entire C API, in libzmq and in CZMQ, zero means > success, though sometimes success is also >0. Errors are always -1. > > On Fri, Jul 11, 2014 at 8:21 PM, jricher wrote: >> I'll admit that I'm just learning the framework, but I'm having a problem >> binding an inproc socket. >> >> The code for a minimal test case is at: http://pastebin.com/CAjThk0i >> >> Essentially, I'm getting a "Resource temporarily Unavailable" error. It only >> happens in C - even though I have czmq and pyzmq compiled against the >> same underlying version of zeromq. I'm at wits end - would someone please >> tell me what stupid thing I'm doing so that I can fix it. >> >> Jacques >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] [ANN] - JZMQ 3.1.0 - A Java ZeroMQ binding
I'd like to announce the immediate availability of org.zeromq/jzmq-3.1.0 on Maven Central. You can view the full changelog here: https://github.com/zeromq/jzmq/blob/master/Changelog.md Warmest regards, Trevor ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Strange problem binding inproc
Zero is not an error. -1 is an error. >= 0 is success. In pretty much the entire C API, in libzmq and in CZMQ, zero means success, though sometimes success is also >0. Errors are always -1. On Fri, Jul 11, 2014 at 8:21 PM, jricher wrote: > > I'll admit that I'm just learning the framework, but I'm having a problem > binding an inproc socket. > > The code for a minimal test case is at: http://pastebin.com/CAjThk0i > > Essentially, I'm getting a "Resource temporarily Unavailable" error. It only > happens in C - even though I have czmq and pyzmq compiled against the > same underlying version of zeromq. I'm at wits end - would someone please > tell me what stupid thing I'm doing so that I can fix it. > > Jacques > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Dissecting Message Queues by Tyler Treat
I tweeted that and got a lot of response. It's a great article. Now, if someone wants to find that SCTP fork of libzmq and backport the pluggable transports, wouldn't that be jolly? Ps. I bet it can't be done. :-/ On Fri, Jul 11, 2014 at 6:47 PM, Steven McCoy wrote: > I don't think I saw this posted yet: noted on highscalability.com today, > > http://www.bravenewgeek.com/dissecting-message-queues/ > > -- > Steve-o > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Strange problem binding inproc
I'll admit that I'm just learning the framework, but I'm having a problem binding an inproc socket. The code for a minimal test case is at: http://pastebin.com/CAjThk0i Essentially, I'm getting a "Resource temporarily Unavailable" error. It only happens in C - even though I have czmq and pyzmq compiled against the same underlying version of zeromq. I'm at wits end - would someone please tell me what stupid thing I'm doing so that I can fix it. Jacques ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Dissecting Message Queues by Tyler Treat
I don't think I saw this posted yet: noted on highscalability.com today, http://www.bravenewgeek.com/dissecting-message-queues/ -- Steve-o ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Extending zmq_msg_t API
I'm on my annual road trip, so it will be few days still before I have time to put the patch together. On Friday, July 11, 2014, Goswin von Brederlow wrote: > On Wed, Jul 09, 2014 at 04:53:16PM -0500, Thomas Rodgers wrote: > > Right. This is my trepidation about surfacing the refcount. The > > "sharedness" is indicated by the flags field on the msg type, and that, > I'm > > reasonably sure, is not altered once it is set. > > At least it can't only become unshared in the background, not suddenly > start being shared. With 2 copies of a message floating around one can > be closed or shared again inbetween the check and the copy. But with > only one copy (the one YOU hold) nobody else can share the message in > the background. Assuming you don't share message pointer between > threads. > > A zmq_msg_get(&msg, ZMQ_SHARED) is easy to add and should be thread > save, erring on sometimes returning true when a message is later not > shared anymore. > > Looking forward to a PULL request for that. > > MfG > Goswin > > > On Wed, Jul 9, 2014 at 4:05 PM, KIU Shueng Chuan > wrote: > > > > > Couldn't the refcount change after you have obtained its value? > > > E.g. > > > Make a copy > > > Send the 1st > > > Read the refcount (2) > > > Background io releases 1st copy > > > On 9 Jul 2014 18:21, "Thomas Rodgers" > wrote: > > > > > >> zmq_msg_get() could be extended to give either the refcount or an > > >> indicator on whether a message was share; based on other refcounted > designs > > >> I'm hesitant to promote surfacing the actual count. Similarly, > > >> zmq_msg_set() could allow 'unsharing' by adding a ZMQ_SHARED property > > >> #define and setting it's value to 0 (no effect on non-shared > messages). > > >> > > >> So the only API surface area change is an additional message property. > > >> This seems the cleanest to me. > > >> > > >> On Wednesday, July 9, 2014, Goswin von Brederlow > > > >> wrote: > > >> > > >>> On Tue, Jul 08, 2014 at 10:42:41AM -0500, Thomas Rodgers wrote: > > >>> > tl;dr; Is there any objection to adding some sort of accessor to > the > > >>> API to > > >>> > determine if a given zmq_msg_t is_shared()? > > >>> > > > >>> > Background/Rationale: > > >>> > > > >>> > Something I encountered while writing a "high level" C++ wrapper > for > > >>> > zmq_msg_t and it's API is the following set of behaviors - > > >>> > > > >>> > zmq_msg_init(&msg_vsm, 20); > > >>> > > > >>> > Results in a type_vsm message, the body of which is held entirely > > >>> within > > >>> > the space allocated to zmq_msg_t > > >>> > > > >>> > zmq_msg_init(&msg_lmsg, 1024); > > >>> > > > >>> > Results in a type_lmsg message, the body is held as a reference to > a > > >>> block > > >>> > of size bytes. > > >>> > > > >>> > memcpy(zmq_msg_data(&msg_vsm), "VSM", 3); > > >>> > memcpy(zmq_msg_data(&msg_lmsg), "LMSG", 4); > > >>> > > > >>> > So far so good. Now copy - > > >>> > > > >>> > zmq_msg_copy(&msg_vsm2, &msg_vsm); > > >>> > zmq_msg_copy(&msg_lmsg2, &msg_lmsg); > > >>> > > > >>> > Now change contents - > > >>> > > > >>> > memcpy(zmq_msg_data(&msg_vsm2), "vsm", 3); > > >>> > memcpy(zmq_msg_data(&msg_lmsg2), "lmsg", 4); > > >>> > > > >>> > assert(memcmp(&msg_vsm, &msg_vsm2, 3) != 0); // ok > > >>> > assert(memcmp(&msg_lmsg, &msg_lmsg2, 4) != 0); // fail > > >>> > > > >>> > This happens by design (lmsg's are refcounted on copy, not deep > > >>> copied). > > >>> > But it results in a situation where a zmq_msg_t is sometimes a > Value > > >>> and > > >>> > sometimes a Reference. This could lead to astonishment for the > unwary. > > >>> > > > >>> > >From the perspective of a wrapper (particularly one that takes a > > >>> strong > > >>> > stand on value semantics and local reasoning), this behavior is > > >>> ungood. So > > >>> > my options are deep copy always or implement copy-on-write. > > >>> > > > >>> > For efficiency I prefer the latter approach in the case of > type_lmsg > > >>> > messages. I have implemented the copy-on-write logic through a > > >>> horrible > > >>> > brittle hack that examines the last byte of zmq_msg_t. I would > prefer > > >>> a > > >>> > less brittle solution. > > >>> > > >>> "lmsg's are refcounted on copy" Can't you access the refcount? > > >>> Or is that the API call you want to add? > > >>> > > >>> Maybe instead of is_shared() an unshare() call would be more usefull, > > >>> which would copy the message payload if it is shared. Or both? > > >>> > > >>> MfG > > >>> Goswin > > >>> ___ > > >>> zeromq-dev mailing list > > >>> zeromq-dev@lists.zeromq.org > > >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > >>> > > >> > > >> ___ > > >> zeromq-dev mailing list > > >> zeromq-dev@lists.zeromq.org > > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > >> > > >> > > > ___ > > > zeromq-dev mailing list > > > zeromq-dev@lists.zeromq.org >
Re: [zeromq-dev] Extending zmq_msg_t API
On Wed, Jul 09, 2014 at 04:53:16PM -0500, Thomas Rodgers wrote: > Right. This is my trepidation about surfacing the refcount. The > "sharedness" is indicated by the flags field on the msg type, and that, I'm > reasonably sure, is not altered once it is set. At least it can't only become unshared in the background, not suddenly start being shared. With 2 copies of a message floating around one can be closed or shared again inbetween the check and the copy. But with only one copy (the one YOU hold) nobody else can share the message in the background. Assuming you don't share message pointer between threads. A zmq_msg_get(&msg, ZMQ_SHARED) is easy to add and should be thread save, erring on sometimes returning true when a message is later not shared anymore. Looking forward to a PULL request for that. MfG Goswin > On Wed, Jul 9, 2014 at 4:05 PM, KIU Shueng Chuan wrote: > > > Couldn't the refcount change after you have obtained its value? > > E.g. > > Make a copy > > Send the 1st > > Read the refcount (2) > > Background io releases 1st copy > > On 9 Jul 2014 18:21, "Thomas Rodgers" wrote: > > > >> zmq_msg_get() could be extended to give either the refcount or an > >> indicator on whether a message was share; based on other refcounted designs > >> I'm hesitant to promote surfacing the actual count. Similarly, > >> zmq_msg_set() could allow 'unsharing' by adding a ZMQ_SHARED property > >> #define and setting it's value to 0 (no effect on non-shared messages). > >> > >> So the only API surface area change is an additional message property. > >> This seems the cleanest to me. > >> > >> On Wednesday, July 9, 2014, Goswin von Brederlow > >> wrote: > >> > >>> On Tue, Jul 08, 2014 at 10:42:41AM -0500, Thomas Rodgers wrote: > >>> > tl;dr; Is there any objection to adding some sort of accessor to the > >>> API to > >>> > determine if a given zmq_msg_t is_shared()? > >>> > > >>> > Background/Rationale: > >>> > > >>> > Something I encountered while writing a "high level" C++ wrapper for > >>> > zmq_msg_t and it's API is the following set of behaviors - > >>> > > >>> > zmq_msg_init(&msg_vsm, 20); > >>> > > >>> > Results in a type_vsm message, the body of which is held entirely > >>> within > >>> > the space allocated to zmq_msg_t > >>> > > >>> > zmq_msg_init(&msg_lmsg, 1024); > >>> > > >>> > Results in a type_lmsg message, the body is held as a reference to a > >>> block > >>> > of size bytes. > >>> > > >>> > memcpy(zmq_msg_data(&msg_vsm), "VSM", 3); > >>> > memcpy(zmq_msg_data(&msg_lmsg), "LMSG", 4); > >>> > > >>> > So far so good. Now copy - > >>> > > >>> > zmq_msg_copy(&msg_vsm2, &msg_vsm); > >>> > zmq_msg_copy(&msg_lmsg2, &msg_lmsg); > >>> > > >>> > Now change contents - > >>> > > >>> > memcpy(zmq_msg_data(&msg_vsm2), "vsm", 3); > >>> > memcpy(zmq_msg_data(&msg_lmsg2), "lmsg", 4); > >>> > > >>> > assert(memcmp(&msg_vsm, &msg_vsm2, 3) != 0); // ok > >>> > assert(memcmp(&msg_lmsg, &msg_lmsg2, 4) != 0); // fail > >>> > > >>> > This happens by design (lmsg's are refcounted on copy, not deep > >>> copied). > >>> > But it results in a situation where a zmq_msg_t is sometimes a Value > >>> and > >>> > sometimes a Reference. This could lead to astonishment for the unwary. > >>> > > >>> > >From the perspective of a wrapper (particularly one that takes a > >>> strong > >>> > stand on value semantics and local reasoning), this behavior is > >>> ungood. So > >>> > my options are deep copy always or implement copy-on-write. > >>> > > >>> > For efficiency I prefer the latter approach in the case of type_lmsg > >>> > messages. I have implemented the copy-on-write logic through a > >>> horrible > >>> > brittle hack that examines the last byte of zmq_msg_t. I would prefer > >>> a > >>> > less brittle solution. > >>> > >>> "lmsg's are refcounted on copy" Can't you access the refcount? > >>> Or is that the API call you want to add? > >>> > >>> Maybe instead of is_shared() an unshare() call would be more usefull, > >>> which would copy the message payload if it is shared. Or both? > >>> > >>> MfG > >>> Goswin > >>> ___ > >>> zeromq-dev mailing list > >>> zeromq-dev@lists.zeromq.org > >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >>> > >> > >> ___ > >> zeromq-dev mailing list > >> zeromq-dev@lists.zeromq.org > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > >> > > ___ > > zeromq-dev mailing list > > zeromq-dev@lists.zeromq.org > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > ___ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Help , why my service cannot receive the data when the client restart?
Hello experts: I made a dealer+router model. The dealer on the client ARM/linux2.6.39, router on server PC/WIN7. My question is: Why can the normal communication of the server and the client, when the client power-off restart, the server does not receive the data sent by the client request. My testing process: 1) the premise: Dealer client to send data, the server can receive normal. 2) when the restart IDENTITYA client, server not to read data. 3) I modify the A client IDENTITY to B, and restart the client, the server and the client can be a normal communication. This process has been in normal operation state of the boot server. 4) I analysis is this: the feeling is when a client server restart, retained the IDENTITYA link state, while the client after the reset, but also in the new context creates a corresponding new IDENTITYA link to connect the server. While the IDENTITYA server that was stored in the last context, that IDENTITYA has been linked to, but do not belong to the same context, so the server router will not receive. But the server only and close the zmq_term socket API (while the other links in the normal operation can not be used) and found no clear IDENTITYA API? Who can give me some directions and suggestions to solve the problem? Thank you very much. -- lgf Email:gaofengli...@126.com ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
