Re: [zeromq-dev] UDP Multicast - Problem with large message sizes?
Found this one: https://github.com/zeromq/libzmq/issues/2009 Is it still not fixed? According to github it needs stacktraces. Should I post mine there? On 09.09.19 21:09, Stephan Opfer wrote: Hi all, when I try to send large messages (~65kB) via UDP Multicast (per draft API, RADIO/DISH), I instantly get Bad file descriptor (src/epoll.cpp:113) #0 0x7faad868ee90 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #1 0x7faad868e870 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #2 0x7faad86d72f0 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #3 0x7faad86d8740 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #4 0x7faad86d73d0 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #5 0x7faad8692370 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #6 0x7faad868e120 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #7 0x7faad86d3440 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #8 0x7faad75b46db in /lib/x86_64-linux-gnu/libpthread.so.0 (start_thread+0xdb) #9 0x7faad699e8c8 in /lib/x86_64-linux-gnu/libc.so.6 (clone+0x3f) Is it known, that the draft API has Problems with large message sizes? What does the assertion in line epoll.cpp:113 actually check and what could be the reason to make it fail? Do you need a MWE in order to investigate it? I probably can create a simple main, that reproduces this error. Last remark (not 100% sure about this): If I reduce the message size to ~2kB, it takes several of these message (~254) to get this error, but the number of messages seems to be always the same. Greetings Stephan -- Distributed Systems Research Group Stephan Opfer T. +49 561 804-6283 F. +49 561 804-6277 Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] UDP Multicast - Problem with large message sizes?
Hi all, when I try to send large messages (~65kB) via UDP Multicast (per draft API, RADIO/DISH), I instantly get Bad file descriptor (src/epoll.cpp:113) #0 0x7faad868ee90 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #1 0x7faad868e870 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #2 0x7faad86d72f0 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #3 0x7faad86d8740 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #4 0x7faad86d73d0 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #5 0x7faad8692370 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #6 0x7faad868e120 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #7 0x7faad86d3440 in /usr/lib/x86_64-linux-gnu/libzmq.so.5 (?+0x0) #8 0x7faad75b46db in /lib/x86_64-linux-gnu/libpthread.so.0 (start_thread+0xdb) #9 0x7faad699e8c8 in /lib/x86_64-linux-gnu/libc.so.6 (clone+0x3f) Is it known, that the draft API has Problems with large message sizes? What does the assertion in line epoll.cpp:113 actually check and what could be the reason to make it fail? Do you need a MWE in order to investigate it? I probably can create a simple main, that reproduces this error. Last remark (not 100% sure about this): If I reduce the message size to ~2kB, it takes several of these message (~254) to get this error, but the number of messages seems to be always the same. Greetings Stephan -- Distributed Systems Research Group Stephan Opfer T. +49 561 804-6283 F. +49 561 804-6277 Univ. Kassel, FB 16, Wilhelmshöher Allee 73, D-34121 Kassel WWW: http://www.uni-kassel.de/go/vs_stephan-opfer/ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Zyre evasive events discussion
Hi, Arnaud Loonstra writes: > The other way to analyse the problem is to check how EVASIVE is used at > the moment... and maybe if it used at all. My experience is that since > its introduction in a stable version, not once was is useful in > real-world cases for me.` Initially I thought EVASIVE was some magic way to determine that the overall application was "misbehaving" (hung/looping). After the obvious realization that the Zyre node has no general way to determine what is going on in other threads it was not clear what the point of EVASIVE was. I hadn't thought about having a peer follow up with a PING but that also only tests that the Zyre actor is alive. I still hope to find some kind of dead-man switch and would like it to be done through Zyre since it's ENTER/EXIT are so related. Ideally, we might add a new API message, eg "ALIVE", which only serves to reset the evasive timeout. My application could do some Zyre chatting just for the side-effect of refreshing the evasive timeout. But, I don't have any need for the resulting chat messages. Maybe I can have the Zyre node WHISPER to itself? -Brett. signature.asc Description: PGP signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Zyre evasive events discussion
Hey all, For people into Zyre there's a PR request about the evasive event. I think it needs more eyes and minds. I haven't used zyre in a while so I'm not too much into it. Anybody any feedback? See: https://github.com/zeromq/zyre/pull/643 `As a developer I would expect zyre to maintain its p2p network brilliantly and inform me if something is (or may be) wrong. Honestly, the current EVASIVE event just telling me that a manual ping was necessary because a peer is quiet does not seem as useful as the other events which are all perfectly relevant. I intend to use zyre in gossip mode later on (which will require some fixing to catch agents exiting without the beacons) and this discussion about an agent being there or not will become critical. The other way to analyse the problem is to check how EVASIVE is used at the moment... and maybe if it used at all. My experience is that since its introduction in a stable version, not once was is useful in real-world cases for me.` I know we always merge pull requests and resolve in time but still I'm not sure this is needed? Rg, Arnaud ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
