Re: [zeromq-dev] Universal Fast Sockets and ZeroMQ
>From What I can tell it is preloaded so which intercepts socket calls and if the calls are destined to go over loopback they use their own protocol and ipc mechanism. http://grokbase.com/t/zeromq/zeromq-dev/13apd39pg8/jeromq-zeromq-transparent-acceleration-with-fast-sockets On 2 Jun 2014 20:31, "Jonathan Jekeli" wrote: > Earlier this year, I saw some posts from someone regarding Universal Fast > Sockets, saying that they greatly decreased the latency of zeromq ( > http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025452.html). > After doing some research, tracked it back to TorusWare, a Spanish company > that advertised a gain of 2400% ( > http://torusware.com/increase-zeromq-performance-by-up-to-2400/). > However, I couldn't find any numbers outside of what they themselves > advertised, and no real documentation. I was just wondering if anyone out > there had tried the Universal Fast Sockets or had any experience or insight > into them? > > Thanks, > > Jon > > ___ > 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] PUB/SUB unreliabiliity
Hi Brian I noticed your comment on another thread about this and I think you got it a bit wrong: > The high water mark is a hard limit on the maximum number of outstanding messages ØMQ shall queue in memory for any single peer that the specified *socket* is communicating with.* A value of zero means no limit.* and from your link: > Since v3.x, ØMQ forces default limits on its internal buffers (the so-called high-water mark or HWM), so publisher crashes are rarer *unless you deliberately set the HWM to infinite.* Nothing I read indicates anything other than the fact that no messages post connections being made should be dropped. Thanks G On 13 June 2014 23:17, Brian Knox wrote: > "From what i've read, PUB SUB should be reliable when the _HWM are set to > zero (don't drop). By reliable I mean no messages should fail to be > delivered to an already connected consumer." > > > Your understanding of pub-sub behavior and how it interacts with the HWM > is incorrect. Please see: http://zguide.zeromq.org/php:chapter5 > > Brian > > > > > On Fri, Jun 13, 2014 at 2:33 PM, Gerry Steele > wrote: > >> I've read everything I can find including the Printed book, but I am at a >> loss as to the definitive definition as to how PUB/SUB should behave in zmq. >> >> A production system I'm using is experiencing message loss between >> several nodes using PUB/SUB. >> >> From what i've read, PUB SUB should be reliable when the _HWM are set to >> zero (don't drop). By reliable I mean no messages should fail to be >> delivered to an already connected consumer. >> >> I implemented some utilities to reproduce the message loss in my system : >> >> zmq_sub: https://gist.github.com/easytiger/992b3a29eb5c8545d289 >> zmq_pub: https://gist.github.com/easytiger/e382502badab49856357 >> >> >> zmq_pub takes a number of events to send and the logging frequency and >> zmq_sub only takes the logging frequency. zmq prints out the number of msgs >> received vs the packet contents containing the integer packet count from >> the publisher. >> >> It can be seen when sending events in a tight loop that messages simply >> go missing mid way through (loss is not at beginning or end ruling out slow >> connectors etc) >> >> In a small loop it usually works ok: >> >> $ ./zmq_pub 2000 1000 >> sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1000 with rc=58 >> sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 with rc=58 >> >> $ ./zmq_sub 1 >> >> RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1 >> RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2 >> RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #3 >> RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #4 >> [...] >> RECV:2000|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 >> >> You can see every message was sent as the counts align. >> >> However increase the message counts and messages start going missing >> >> $ ./zmq_pub 20 10 >> >> sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #10 with >> rc=60 >> sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #20 with >> rc=60 >> >> ./zmq_sub 1 >> RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #11000 >> RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #21000 >> RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #31610 >> RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #42000 >> RECV:5|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #52524 >> RECV:6|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #64654 >> RECV:7|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #77298 >> RECV:8|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #90117 >> RECV:9|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #102864 >> RECV:10|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #115846 >> RECV:11|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #129135 >> RECV:12|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #141606 >> RECV:13|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #154179 >> RECV:14|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #166627 >> RECV:15|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #179166 >> RECV:16|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #192247 >> >> >> Is this expected behaviour? With PUSH/PULL I get no loss at all with >> similar utilities. >> >> If I put more work between sends (e.g. cout each time) and the full >> message the results are better. >> >> zmq_push: https://gist.github.com/easytiger/2c4f806594ccfbc74f54 >> zmq_pull: https://gist.github.com/easytiger/268a630fd22f959fde93 >> >> Is there an issue/bug in my implementation that would cause this? >> >> Using zeromq 4.0.3 >> >> Many Thanks >> Gerry >> >> >> >> >> >> -- >> Gerry Steele >> >> >> ___ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.o
Re: [zeromq-dev] PUB/SUB unreliabiliity
"From what i've read, PUB SUB should be reliable when the _HWM are set to zero (don't drop). By reliable I mean no messages should fail to be delivered to an already connected consumer." Your understanding of pub-sub behavior and how it interacts with the HWM is incorrect. Please see: http://zguide.zeromq.org/php:chapter5 Brian On Fri, Jun 13, 2014 at 2:33 PM, Gerry Steele wrote: > I've read everything I can find including the Printed book, but I am at a > loss as to the definitive definition as to how PUB/SUB should behave in zmq. > > A production system I'm using is experiencing message loss between several > nodes using PUB/SUB. > > From what i've read, PUB SUB should be reliable when the _HWM are set to > zero (don't drop). By reliable I mean no messages should fail to be > delivered to an already connected consumer. > > I implemented some utilities to reproduce the message loss in my system : > > zmq_sub: https://gist.github.com/easytiger/992b3a29eb5c8545d289 > zmq_pub: https://gist.github.com/easytiger/e382502badab49856357 > > > zmq_pub takes a number of events to send and the logging frequency and > zmq_sub only takes the logging frequency. zmq prints out the number of msgs > received vs the packet contents containing the integer packet count from > the publisher. > > It can be seen when sending events in a tight loop that messages simply go > missing mid way through (loss is not at beginning or end ruling out slow > connectors etc) > > In a small loop it usually works ok: > > $ ./zmq_pub 2000 1000 > sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1000 with rc=58 > sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 with rc=58 > > $ ./zmq_sub 1 > > RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1 > RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2 > RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #3 > RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #4 > [...] > RECV:2000|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 > > You can see every message was sent as the counts align. > > However increase the message counts and messages start going missing > > $ ./zmq_pub 20 10 > > sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #10 with > rc=60 > sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #20 with > rc=60 > > ./zmq_sub 1 > RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #11000 > RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #21000 > RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #31610 > RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #42000 > RECV:5|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #52524 > RECV:6|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #64654 > RECV:7|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #77298 > RECV:8|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #90117 > RECV:9|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #102864 > RECV:10|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #115846 > RECV:11|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #129135 > RECV:12|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #141606 > RECV:13|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #154179 > RECV:14|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #166627 > RECV:15|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #179166 > RECV:16|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #192247 > > > Is this expected behaviour? With PUSH/PULL I get no loss at all with > similar utilities. > > If I put more work between sends (e.g. cout each time) and the full > message the results are better. > > zmq_push: https://gist.github.com/easytiger/2c4f806594ccfbc74f54 > zmq_pull: https://gist.github.com/easytiger/268a630fd22f959fde93 > > Is there an issue/bug in my implementation that would cause this? > > Using zeromq 4.0.3 > > Many Thanks > Gerry > > > > > > -- > Gerry Steele > > > ___ > 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] PUB/SUB unreliabiliity
I've read everything I can find including the Printed book, but I am at a loss as to the definitive definition as to how PUB/SUB should behave in zmq. A production system I'm using is experiencing message loss between several nodes using PUB/SUB. >From what i've read, PUB SUB should be reliable when the _HWM are set to zero (don't drop). By reliable I mean no messages should fail to be delivered to an already connected consumer. I implemented some utilities to reproduce the message loss in my system : zmq_sub: https://gist.github.com/easytiger/992b3a29eb5c8545d289 zmq_pub: https://gist.github.com/easytiger/e382502badab49856357 zmq_pub takes a number of events to send and the logging frequency and zmq_sub only takes the logging frequency. zmq prints out the number of msgs received vs the packet contents containing the integer packet count from the publisher. It can be seen when sending events in a tight loop that messages simply go missing mid way through (loss is not at beginning or end ruling out slow connectors etc) In a small loop it usually works ok: $ ./zmq_pub 2000 1000 sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1000 with rc=58 sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 with rc=58 $ ./zmq_sub 1 RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #1 RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2 RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #3 RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #4 [...] RECV:2000|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #2000 You can see every message was sent as the counts align. However increase the message counts and messages start going missing $ ./zmq_pub 20 10 sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #10 with rc=60 sent MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #20 with rc=60 ./zmq_sub 1 RECV:1|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #11000 RECV:2|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #21000 RECV:3|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #31610 RECV:4|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #42000 RECV:5|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #52524 RECV:6|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #64654 RECV:7|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #77298 RECV:8|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #90117 RECV:9|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #102864 RECV:10|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #115846 RECV:11|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #129135 RECV:12|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #141606 RECV:13|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #154179 RECV:14|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #166627 RECV:15|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #179166 RECV:16|MESSAGE PAYLOAD OF A NONTRIVAL SIZE KIND OF AND SUCH #192247 Is this expected behaviour? With PUSH/PULL I get no loss at all with similar utilities. If I put more work between sends (e.g. cout each time) and the full message the results are better. zmq_push: https://gist.github.com/easytiger/2c4f806594ccfbc74f54 zmq_pull: https://gist.github.com/easytiger/268a630fd22f959fde93 Is there an issue/bug in my implementation that would cause this? Using zeromq 4.0.3 Many Thanks Gerry -- Gerry Steele ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] zsock test hangs in pyczmq
On Fri, Jun 13, 2014 at 11:08 AM, Pieter Hintjens wrote:
> On Fri, Jun 13, 2014 at 7:55 PM, Michel Pelletier
> wrote:
>
> > Some gdb adventures shows I was calling zsock_new with filename and
> line_nbr
> > args defaulting to NULL and 0 out of sheer laziness.
>
> That should actually work... it's usually what you'd do in release
> mode with all socket tracking switched off.
>
Yeah that's what I was thinking when I wrote it. Python can't know how
czmq was compiled with ZSOCK_NOCHECK unless I expose it and that sounded
ugly to me, so instead I have:
@cdef('zsock_t * zsock_new_ (int type, const char *filename, size_t
line_nbr);')
def new(type, filename=None, line_nbr=None):
if filename is None:
frame = inspect.stack()[1][0]
info = inspect.getframeinfo(frame)
filename = info.filename
line_nbr = info.lineno
return ffi.gc(C.zsock_new_(type, filename, line_nbr), destroy)
Which sidesteps the issue by calling zsock_new_ directly with file and line
information from the frame's caller. I don't think __FILE__ and __LINE__
would be useful to a pyczmq user, as it would end up referencing a
generated C file internal to CFFI.
-Michel
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] zsock test hangs in pyczmq
On Fri, Jun 13, 2014 at 7:55 PM, Michel Pelletier wrote: > Some gdb adventures shows I was calling zsock_new with filename and line_nbr > args defaulting to NULL and 0 out of sheer laziness. That should actually work... it's usually what you'd do in release mode with all socket tracking switched off. > Should have this all wrapped up today! I like the zactor/zsock/zsys theme, > very simple to use. Yes, it's fun, isn't it :-) -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] zsock test hangs in pyczmq
Some gdb adventures shows I was calling zsock_new with filename and line_nbr args defaulting to NULL and 0 out of sheer laziness. When I set them (to anything) the program exits normally. I can easily get the file and line nbr of the Python caller so I'll just shove those in there. Should have this all wrapped up today! I like the zactor/zsock/zsys theme, very simple to use. -Michel ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Seg fault in
Hi, I've cross compiled the 4.0.4 sources of zeromq for Microblaze using both --with-poller=select and leaving the default setting (which is epoll) and in both libraries I get a seg fault when tyring to bind to an IPC socket. The linux version is 3.14. Here is the code I'm trying to run: context = zmq_ctx_new (); publisher = zmq_socket (context, ZMQ_PUB); rc = zmq_bind (publisher, "ipc://xpwrd.ipc"); assert (rc == 0); Here's the stack for the select version Thread [3] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 6 0x90078eb0 5 zmq::select_t::loop() select.cpp:197 0x48053a58 4 zmq::select_t::worker_routine() select.cpp:211 0x48053bc0 3 thread_routine() thread.cpp:81 0x480660cc 2 start_thread() pthread_create.c:314 0x48095180 1 clone() clone.S:65 0x483784ec The offending line is void zmq::select_t::loop () if (FD_ISSET (fds [i].fd, &readfds)) fds [i].events->in_event (); } I've tried stepping and it looks like in_event is not a function and it jumps to an out of range address. Any help is greatly appreciated. -Martin. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ?????? some questions of zeromq
Actually this problem is reffered in the Guide,I do not if you see the Chapter 2 of Guide Synchronized publisher in C.The author explained why you may lose message.Hope this can be helpful. John -- -- ??: "zhanglei-ds4??..??)";; : 2014??6??12??(??) 11:37 ??: "zeromq-dev"; : [zeromq-dev] some questions of zeromq Dear Mr, I come from china. and we have used the latest zeromq(4.0.4) in our project . but there are some questions coming . that is : a lot of messages lose in PUB-SUB . so I have to use older version zeromq(2.2.0) ,and I set ZMQ_HWM and ZMQ_SWAP , the message is no longer lost in PUB_SUB. I have two question: 1. since the version 3.2.0 , zeromq can not set ZMQ_SWAP ,why are you cancle ZMQ_SAWP ? 2. if I use latest zeromq , how to avoid lose message in PUB-SUB ? I set ZMQ_HWM in PUB-SUB , but message still lose , how to do? thanks.___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] some questions of zeromq
Hi Zhanglei, I have the same question with you. I'm using 3.2.3. PUB ZMQ_SNDHWM doesn't work. I debuged this issue with gdb, and found that ZeroMQ disregards "zmq_setsockopt(publisher, ZMQ_SNDHWM, &sndhwm, sizeof(int));". zmq::pipe_t::hwm is still 1000. - Zhichang 2014-06-12 11:37 GMT+08:00 zhanglei-ds4（张雷.信息技术中心.搜索组) < zhanglei-...@yolo24.com>: > > Dear Mr, > I come from china. and we have used the latest zeromq(4.0.4) in our > project . but there are some questions coming . that is : >a lot of messages lose in PUB-SUB . so I have to use older version > zeromq(2.2.0) ,and I set ZMQ_HWM and ZMQ_SWAP , the message is no longer > lost in PUB_SUB. > I have two question: > 1. since the version 3.2.0 , zeromq can not set ZMQ_SWAP ,why are you > cancle ZMQ_SAWP ? > 2. if I use latest zeromq , how to avoid lose message in PUB-SUB ? I set > ZMQ_HWM in PUB-SUB , but message still lose , how to do? > > thanks. > -- > > ___ > 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] zsock test hangs in pyczmq
It sounds like there's another socket being created somewhere, outside of CZMQ's control, and this is causing the termination to block. Or, something weird with threads. Can you try adding tracing to each socket creation and destruction, in zsys (zmq_socket/zmq_destroy)? On Fri, Jun 13, 2014 at 4:41 AM, Michel Pelletier wrote: > I'm working on adding zsock and zactor support to pyczmq, and I have most of > the work done, but my test for zsock is hanging. The test runs and works, > zsock_destroy is called correctly (not that it would matter the default > linger is 0) but the process never exits. gdb says it hanging on poll in > zsys's s_terminate_process: > > #0 0x778e2f7d in poll () at ../sysdeps/unix/syscall-template.S:81 > #1 0x75361caa in poll (__timeout=-1, __nfds=1, > __fds=0x7fffdd10) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 > #2 zmq::signaler_t::wait (this=this@entry=0x9e7dc8, > timeout_=timeout_@entry=-1) at signaler.cpp:158 > #3 0x75350177 in zmq::mailbox_t::recv (this=this@entry=0x9e7d68, > cmd_=cmd_@entry=0x7fffdd70, timeout_=timeout_@entry=-1) at > mailbox.cpp:72 > #4 0x7533fc0c in zmq::ctx_t::terminate (this=0x9e7cd0) at > ctx.cpp:141 > #5 0x75378921 in zmq_ctx_term (ctx_=) at zmq.cpp:157 > #6 0x75816891 in s_terminate_process () at zsys.c:273 > #7 0x77831071 in __run_exit_handlers (status=0, > listp=0x77bb66a8 <__exit_funcs>, > run_list_atexit=run_list_atexit@entry=true) at exit.c:77 > #8 0x778310f5 in __GI_exit (status=) at exit.c:99 > #9 0x77816dec in __libc_start_main (main=0x46a2a1 , argc=2, > ubp_av=0x7fffdf18, init=, fini=, > rtld_fini=, stack_end=0x7fffdf08) at libc-start.c:294 > #10 0x005735fe in _start () > > A little more digging looks like libzmq is waiting for a message from a > 'reaper' thread that never arrives, context termination waits for this > message with a timeout of -1 so it never exits. > > Anyone have any thoughts on this? I don't know much about the > reaper/shutdown side of things. > > -Michel > > > ___ > 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] some questions of zeromq
Dear Mr, I come from china. and we have used the latest zeromq(4.0.4) in our project . but there are some questions coming . that is : a lot of messages lose in PUB-SUB . so I have to use older version zeromq(2.2.0) ,and I set ZMQ_HWM and ZMQ_SWAP , the message is no longer lost in PUB_SUB. I have two question: 1. since the version 3.2.0 , zeromq can not set ZMQ_SWAP ,why are you cancle ZMQ_SAWP ? 2. if I use latest zeromq , how to avoid lose message in PUB-SUB ? I set ZMQ_HWM in PUB-SUB , but message still lose , how to do? thanks. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] make 4.0 the default docs (was: Lazy pirate alternative implementation)
Good idea. I've changed the api.zeromq.org site to show 4.0.x as the
default page.
On Fri, Jun 13, 2014 at 8:28 AM, Thomas Klausner wrote:
> Hi!
>
> On Thu, Jun 12, 2014 at 11:33:48PM +0200, Pieter Hintjens wrote:
>
>> you use libzmq/4.x you can use ZMQ_REQ_RELAXED: and that makes Lazy
>> Pirate obsolete.
>
> Oh, wow, I didn't realize there is ZMQ_REQ_RELAXED. I guess I did not
> realize this because most of the time I need to figure out something
> zeromq-related, I click on the "The ZeroMQ Reference Manual" link in
> http://zeromq.org/intro:read-the-manual
> which leads to http://api.zeromq.org/, which defaults to ØMQ/3.2.5 API
> Reference. Of course I'm too lazy to have ever read the submenu pointing
> to v4.0 stable docs.
>
> So: Could you maybe change the default docs to 4.0 stable? It's been
> released for quite some time now, and pointing people (or at least me)
> to the most current docs would probably be a good idea.
>
> Greetings,
> domm
>
> --
> #!/usr/bin/perl http://domm.plix.at
> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
> ___
> 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
