Re: [zeromq-dev] topic discovery using broker

discovery myself, and I will certainly check it out if I get to that point. For now, I’m holding out hope for an “off the shelf” solution. Regards, Bill > On Aug 2, 2017, at 12:06 PM, Justin Azoff <justin.az...@gmail.com> wrote: > > On Wed, Aug 2, 2017 at 9:25 AM, Bill Torpey <wa

Re: [zeromq-dev] topic discovery using broker

Thanks Luca. As mentioned in my reply to Justin, I’m kind of hoping for an “off the shelf” solution that is already integrated with 0mq pub/sub mechanism. And, while zgossip looks like something I could build on, it doesn’t quite solve the whole problem (*I think*). Will definitely look

[zeromq-dev] topic discovery using broker

The problem of topic discovery keeps coming up, and one of the first approaches recommended is to use a broker. That makes sense from the point of view of simplicity, but it has several disadvantages in the areas of scalability and availabilty. An obvious (?) solution would be to use a “topic

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

Hi Luca: Just a gentle reminder to add an issue so this can be tracked (or let me know if you’d prefer that I do that). Thanks! Bill > On Sep 2, 2017, at 1:21 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Sat, 2017-09-02 at 12:02 -0400, Bill Torpey wrote: >&g

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

h 0MQ’s view (not to mention a bunch of additional work on the protocol layer, but more about synchronization). Thanks for listening ... Bill > On Sep 17, 2017, at 6:39 AM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Sat, 2017-09-16 at 14:34 -0400, Bill Torpey wro

[zeromq-dev] client/server sockets -- stability

expectation around when these socket types will be declared “stable”? Can anyone shed any light on the process needed to move these to stable status, and/or what the timeframe might be? Many thanks in advance for any help! Regards, Bill Torpey

Re: [zeromq-dev] client/server sockets -- stability

; stable status, and/or what the timeframe might be? >> >> Many thanks in advance for any help! >> >> Regards, >> >> Bill Torpey > > Documentation is missing, and also there was still recently some > brainstorming on how to do something

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

Hi Luca: Sorry for not geting back sooner, but thanks again for listening, and the PR looks good to me! Best Regards, Bill Torpey > On Sep 19, 2017, at 9:13 AM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Sun, 2017-09-17 at 12:29 -0400, Bill Torpey wrote: >>

Re: [zeromq-dev] thread safety using inproc sockets for inter-thread communication

, 1);// see https://github.com/zeromq/libzmq/issues/2267 zmq_send(temp, msg, msgSize, 0); zmq_disconnect(temp, ZMQ_CONTROL_ENDPOINT); zmq_close(temp); > On Sep 26, 2017, at 5:22 PM, Bill Torpey <wallstp...@gmail.com> wrote: > > Hi All: > > I don’t see thi

[zeromq-dev] thread safety using inproc sockets for inter-thread communication

emp); This *seems* to work, but I’m concerned that maybe I’m just getting "lucky”? It does *not* appear to work with ZMQ_PAIR sockets, for whatever reason, although I’ve seen that approach recommended in a few places. Thanks in advance for any assistance! Regards, Bil

Re: [zeromq-dev] thread safety using inproc sockets for inter-thread communication

tions would be much appreciated! And, let me know if this would be better discussed in GitHub issues. Thanks in advance. Bill Torpey ZeroMQ built from source (d17581929cceceda02b4eb8abb054f996865c7a6) using gcc 4.8.2 on CentOS 6 Below is the stack trace from the hung process. The deadlock ap

[zeromq-dev] ZMQ reconnect/ephemeral ports

I'm curious about how ZMQ handles re-connection. I understand that re-connection is supposed to happen "automagically" under the covers, but that poses an interesting question. To make a long story short, the application I'm working on uses pub/sub sockets over TCP. and works like follows:

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

017, at 5:30 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Fri, 2017-09-01 at 16:59 -0400, Bill Torpey wrote: >> I'm curious about how ZMQ handles re-connection. I understand that >> re-connection is supposed to happen "automagically" under the covers, >

Re: [zeromq-dev] ZMQ reconnect/ephemeral ports

vior, that would be helpful. Failing that, I guess I’ll need to test this in the debugger — any hints on how best to do this would also be much appreciated. Regards, Bill > On Sep 1, 2017, at 6:19 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > > On Fri, 2017-09-01 at

Re: [zeromq-dev] Sharing socket safely between threads

If you’re thinking of using inproc sockets for inter-thread signaling, you may find this helpful: https://github.com/WallStProg/zmqtests/tree/master/threads I put this together to illustrate the problems discussed here:

Re: [zeromq-dev] FBZMQ

Never mind FBZMQ, I’d love to know who is using ZeroMQ, in any way, shape or form, and what for! > On May 9, 2018, at 3:58 PM, E.W.Z. wrote: > > Moreover, do we KNOW they are using it, or it just some engineering POC for > fun? > > Sent from Mail

Re: [zeromq-dev] Sharing socket safely between threads

1. FWIW, my personal experience has been that it is safe to share a ZMQ_PUB socket between threads if protected with a mutex. Basically the sequence is lock/send/unlock. The alternative is to have an internal zmq_proxy with inproc on one side and something like TCP on the other side, which is

Re: [zeromq-dev] Sharing socket safely between threads

st using a mutex to share sockets between threads, except in the case of a ZMQ_PUB socket I mentioned earlier. > > > > > > On Sat, May 12, 2018 at 4:08 PM, Bill Torpey <wallstp...@gmail.com > <mailto:wallstp...@gmail.com>> wrote: > 1. FWIW, my personal e

Re: [zeromq-dev] question re: connect/handshake

’t know that that behavior is documented anywhere. > > Justin > > On Sat, Jun 2, 2018, at 11:49 AM, Bill Torpey wrote: >> Hello all: >> >> I have a question that I’m hoping someone with more experience than I >> can help answer, which is whether the order

[zeromq-dev] question re: connect/handshake

be certain. Or am I stuck with having to use zmq_socket_monitor to capture the events and provide synchronization around them? (Which I would prefer to avoid if possible -- that can be messy and error-prone). Any tips, suggestions much appreciated! Regards, B

Re: [zeromq-dev] Client/Server Socket Prospects?

I’m interested in that as well — when I asked this question last year I got the following reply from Luca: https://lists.zeromq.org/pipermail/zeromq-dev/2017-October/031960.html . My take on it is that client/server will

Re: [zeromq-dev] zmq architecture/protocol planning

Hi James: I’m doing something similar on the service discovery end, but it’s a work in progress, so take this with the appropriate amount of salt ;-) It seems a good idea to minimize state as much as possible, especially distributed state, so I have so far avoided the central “registrar”,

Re: [zeromq-dev] Server Socket Initiate Communication

Let me see if I can explain this from the perspective of pub/sub messaging, as that is what I am familiar with. With pub/sub messaging “clients” subscribe to topics and “servers” publish messages on those topics. (The use of “client” and “server” here is somewhat arbitrary, but I believe it’s

Re: [zeromq-dev] are zmq::atomic_ptr_t<> Helgrind warnings known?

I’m using clang’s Thread Sanitizer for a similar purpose, and just happened to notice that the TSAN docs use ZeroMQ as one of the example suppressions: https://github.com/google/sanitizers/wiki/ThreadSanitizerSuppressions

Re: [zeromq-dev] are zmq::atomic_ptr_t<> Helgrind warnings known?

> > 2018-02-24 16:44 GMT+01:00 Francesco <francesco.monto...@gmail.com > <mailto:francesco.monto...@gmail.com>>: > Hi Bill, > indeed I've found ThreadSanitizer to be more effective i.e., it contains much > less false positives compared to Helgrind... still I'm gett

Re: [zeromq-dev] are zmq::atomic_ptr_t<> Helgrind warnings known?

Hi Franceso: A few more points below … Good luck, and please post back if you find out anything interesting! Regards, Bill > On Feb 25, 2018, at 4:54 AM, Francesco <francesco.monto...@gmail.com> wrote: > > Hi Bill, > thanks for your answer. > > > > 2018-02-

Re: [zeromq-dev] Check availability of messages with timeout

Kevin: I struggled with some of these issues for a while, and documented them here: https://github.com/zeromq/libzmq/issues/2759. There’s an accompanying repo with sample code here: https://github.com/WallStProg/zmqtests/tree/master/threads. The short version is that there are some pretty

Re: [zeromq-dev] commercial support for ZeroMQ

Yup — thanks! I’ve already heard from Karol and Michal and we’re in touch off the list. > On Jun 21, 2018, at 7:28 AM, Doron Somech wrote: > > Look at Karol message at the list from yesterday. > > karol.hrdina AT gmail.com <http://gmail.com/> > > On Wed, Ju

[zeromq-dev] commercial support for ZeroMQ

Some of you may recognize my email from some emails to the list, GitHub issues and pull requests. I'm leading a project to implement a middleware solution based on ZeroMQ at my employer: a large-ish (~1,000 employees) global provider of software and services to the financial community. I'm

[zeromq-dev] triggering process_commands on inactive sockets

I’m posting this here since not everyone on the list will necessarily see the Github issue, and I’m interested in getting as much feedback as possible. The issue in question ( https://github.com/zeromq/libzmq/issues/3186 ) has to do with finding a good way to trigger process_commands on

Re: [zeromq-dev] triggering process_commands on inactive sockets

simply to return from the zmq_poll and then call it again, as is typical usage). Any thoughts from the community on this? Is it a good idea? Is it even possible? Thanks in advance for any comments. > On Aug 23, 2018, at 4:33 PM, Bill Torpey wrote: > > Thanks, James! > >

Re: [zeromq-dev] triggering process_commands on inactive sockets

ork on the users side. > > On Thu, Aug 23, 2018 at 3:29 PM Bill Torpey <mailto:wallstp...@gmail.com>> wrote: > I’m posting this here since not everyone on the list will necessarily see the > Github issue, and I’m interested in getting as much feedback as possible. > >

Re: [zeromq-dev] triggering process_commands on inactive sockets

> On Aug 24, 2018, at 5:02 AM, Luca Boccassi wrote: > > This is a very old issue that has its roots in some of the commands > needing to be processed in the application thread. The solution is to > refactor and move them to the I/O thread instead. > > But it's of course much easier said than

Re: [zeromq-dev] triggering process_commands on inactive sockets

> On Aug 24, 2018, at 4:59 AM, Luca Boccassi wrote: > > There's already event monitoring for that Yes, and I’m already using event monitoring, but with some nervousness — because of the serious consequences if something goes wrong with event monitoring (i.e., the process freezes solid, and

Re: [zeromq-dev] topics on SUB PUB pattern

It’s not removed on the receiver side, which is a Good Thing, since it’s common for the receiver to need to know the topic of a received message. (A single receiver can subscribe to >1 topic). > On Aug 20, 2018, at 11:08 AM, Michael Hansen wrote: > > When doing sub/pub pattern, why does

Re: [zeromq-dev] User-space polling of ZMQ sockets

So, are there any benchmark tests that can be used to quantify the overhead of zmq_poll? It seems like this question keeps coming up, and it would certainly be nice to have some real numbers (and the code used to generate them). Having said that, there are several mechanisms that zmq_poll can

Re: [zeromq-dev] User-space polling of ZMQ sockets

Well, a little googling found this, which is a pretty good writeup: https://jvns.ca/blog/2017/06/03/async-io-on-linux--select--poll--and-epoll/ > On Apr 11, 2018, at 2:42 PM, Bill Torpey <wallstp...@gmail.com> wrote: > > So, are there any benchmark tests that can be u

Re: [zeromq-dev] Enable/Disable monitoring with zmq_socket_monitor()

Hi Martin: This is just a guess, but it’s an educated guess. The doc for zmq_socket_monitor says: > Each call to this method creates a ZMQ_PAIR socket and binds that to the > specified inproc:// endpoint. The newly-created socket doesn’t have any connections until you connect to it.

Re: [zeromq-dev] Revisited: Example for building against ZMQ with CMake + UDP Multicast Support

help: >>> >>> g++ Discovery.cpp -lzmq -DZMQ_BUILD_DRAFT_API=1 -DENABLE_DRAFTS=On -o test >>> >>> I also checked my installed libraries with "nm -gC >> zmq_msgs_group": >>> >>> /usr/lib/x86_64-linux-gnu/libzmq.a -> match >

Re: [zeromq-dev] Revisited: Example for building against ZMQ with CMake + UDP Multicast Support

se system is missing a dependency, everything that is > needed is shipped in the same repository where the library can be > found, and kept up to date. > Please do not recommend to avoid repositories - it's the preferred form > of distribution for Linux users. > > On Wed, 2018-09-26

Re: [zeromq-dev] Revisited: Example for building against ZMQ with CMake + UDP Multicast Support

Hi Stephan: The RADIO/DISH sockets are considered DRAFT, which is probably why you’re getting these errors. There are a couple of possibilities: - You may be linking against a version of libzmq that doesn’t include the draft APIs. In order to build with draft support, the build needs to

Re: [zeromq-dev] Revisited: Example for building against ZMQ with CMake + UDP Multicast Support

c library stuff, but my build chain is > linking agains "/usr/lib/x86_64-linux-gnu/libzmq.so". Is that the problem? > How do I force it on command line to link against the static version. > > Kind Regards > > Stephan > > On 26.09.2018 16:08, Bill Torpey wrote

Re: [zeromq-dev] Revisited: Example for building against ZMQ with CMake + UDP Multicast Support

spent by maintainers. > When talking about the average case, knowledge about adding third party > repositories to a distro install is much more common than building from > scratch N elements of a stack. > > On Wed, 2018-09-26 at 11:58 -0400, Bill Torpey wrote: >> Hi Luca: >>

Re: [zeromq-dev] [C/Linux/ZMQ_PAIR/Unidirectional-flow] - can I send messages to connect socket from multiple threads with mutex protection?

Hi Anand: Please see comments below. Good luck with your project! Bill > On Dec 30, 2018, at 10:45 PM, anand n wrote: > > Team, > > I am building a multi threaded application in linux with C as the programming > language and use ZMQ_PAIR sockets for inter-thread communication (zmq version

Re: [zeromq-dev] Question about zmq_socket_monitor()

In my experience, ZMQ_PAIR sockets exhibit some problems that I previously documented here: https://github.com/zeromq/libzmq/issues/2759, specifically around disconnecting and reconnecting. In particular, see this reply from Simon:

Re: [zeromq-dev] Get a list of all topics

Hi Carol: ZeroMQ actually doesn’t have the concept of “topics”, at least in the way that term is used with other middlewares. ZeroMQ does filtering on the prefix of a message, which is a bit of a different animal. You can use that to create a topic-based addressing scheme similar to other

Re: [zeromq-dev] performance issue in zmq_proxy_steerable()

HI Claudio: You might want to try a later version — there was a performance regression on certain platforms that is documented here: https://github.com/zeromq/libzmq/issues/3373 and was resolved by a commit by Doron (5ecf8f9) subsequent to

Re: [zeromq-dev] How to distinguish peers using socket_monitor

g mechanism “on top of” ZeroMQ, possibly using application-level heartbeats, timeouts, etc. This can get quite messy, but as far as I know is the only way. Hope this helps. Bill Torpey > On Jun 3, 2019, at 5:41 AM, Milosz Malczak wrote: > > I am creating a distributed system with

Re: [zeromq-dev] New ZeroMQ website and help needed

Definitely looks nice! (if a little light on content at the moment ;-) FWIW, I’ve been putting together a list of resources for a project I’m working on, some of which are a bit hard to find, Here’s what I have so far (markdown format): ## ZeroMQ Description | Location

Re: [zeromq-dev] Is inproc PUB SUB subject to the slow joiner problem?

the subscribe before the connect and see if that helps. I’ll see if I can find an “official” reference to this. Regards, Bill > On May 10, 2019, at 5:19 PM, Bill Torpey wrote: > > Hi Chris: > >> The difference seems to be that if the PUB socket sends a message prior to >> an

Re: [zeromq-dev] Is inproc PUB SUB subject to the slow joiner problem?

> subscription has been processed. But if I have misunderstood anything, please > let me know :) > > -Chris > > On Fri, May 10, 2019 at 2:05 PM Bill Torpey <mailto:wallstp...@gmail.com>> wrote: > Hi Chris: > > With inproc transports the connect call is synchrono

Re: [zeromq-dev] Is inproc PUB SUB subject to the slow joiner problem?

Hi Chris: With inproc transports the connect call is synchronous, as opposed to with other protocols (like TCP) where the connect is asynchronous. This was part of a discussion with Simon at https://github.com/zeromq/libzmq/issues/2759#issuecomment-389185969

Re: [zeromq-dev] Is inproc PUB SUB subject to the slow joiner problem?

ion). > > So I think I have my answer: subscriptions are not synchronous for inproc, I > just maybe hit on a situation initially where it looked like they were. > > -Chris > > > > > > On Fri., 10 May 2019, 18:36 Bill Torpey, <mailto:wallstp...@gmail.com&

Re: [zeromq-dev] max PUB/SUB topics

I would be curious what errno was returned with the failing subscribe call. If EAGAIN, that would at least provide a clue to what was happening. If not, then this should perhaps be raised as an issue so it will get fixed. > On May 15, 2019, at 1:03 PM, Brian T. Carcich wrote: > > On Wed,

Re: [zeromq-dev] Mixing threaded tbb::flow::graph and ZeroMQ

HI Brett: Here are a few thoughts that may help: - I don’t know CZMQ at all, so comments reflect “pure” 0mq. - In practice, it’s possible to share PUB sockets using mutexes if you’re careful. - It is not possible to share SUB sockets, period. It may appear to work, but at some point you will

Re: [zeromq-dev] Mixing threaded tbb::flow::graph and ZeroMQ

e signficant limitations in any case. Why not use one of the thread-safe sockets? > On Dec 13, 2019, at 12:38 PM, Brett Viren wrote: > > Bill Torpey writes: > >> - In practice, it’s possible to share PUB sockets using mutexes if you’re >> careful. > > How a

Re: [zeromq-dev] fd leak with dealer to dealer with tcp as transport

Hi Siva: Bear in mind that zmq_disconnect is asynchronous (not well-documented IMO, but e.g., see https://github.com/zeromq/libzmq/issues/2759#issuecomment-389057453 ). zmq_connect is also asynchronous in most cases (except

Re: [zeromq-dev] Formally modelling the publish-subscribe pattern

considered TLA+ and if so what prompted you to choose PROMELA? Good luck with your thesis, and I’d very much like to review it when you’ve got something suitable. Regards, Bill Torpey > On Oct 15, 2020, at 5:23 AM, John Lång wrote: > > Hello, > > (Hopefully this mes

Re: [zeromq-dev] Single Point of Failure & Recovery

A big question is what the “workers” do? - It sounds like you want to process “transactions” — i.e., the workers need to be able to reliably update some shared state. Is that true? - If so, which of the ACID properties do you care about? - Are your transactions “idempotent” — i.e., does it not

Re: [zeromq-dev] ZMQ - Send std::shared_ptr via inproc pub-sub?

Serguei: Your original question implies (but does not state explicitly) that you want to use 0mq to send shared_ptr’s to other threads in the same process.If that is the case you need to be cognizant of (https://en.cppreference.com/w/cpp/memory/shared_ptr

Re: [zeromq-dev] Recommendations for deployment architectre

Hi newbie! We’ve done much of what you are proposing — unfortunately the “heavy lifting” (acks, timeouts, etc.) is proprietary, but we have recently made some of our code open-source: https://github.com/nyfix/OZ . It may give you some ideas, even if it ends up not

Re: [zeromq-dev] Bitcoin still using ZMQ?

Hi Benjamin: I don’t know about Bitcoin, but you may be interested to know that my company has gone public with our open-source middleware implementation using ZeroMQ called OZ, which can be found here: https://github.com/nyfix/OZ. OZ has been used to power the NYFIX Marketplace, which is the

Re: [zeromq-dev] Bitcoin still using ZMQ?

-Kevin > > -Original Message----- > From: zeromq-dev On Behalf Of Bill > Torpey > Sent: Wednesday, November 25, 2020 9:14 AM > To: zoo...@gmail.com; ZeroMQ development list > Subject: Re: [zeromq-dev] Bitcoin still using ZMQ? > > Hi Benjamin: > > I don’t kn

Re: [zeromq-dev] Bitcoin still using ZMQ?

Just committed a couple of minor changes to support ubuntu - check it out: https://github.com/nyfix/OZ/commit/f06031b1420046e1c188ec9b0d787f82b43b7506 (Note: using 20.04) > On Nov 25, 2020, at 11:44 AM, Bill Torpey wrote: > > Hi Kevin: > > Right now we have only tested on

Re: [zeromq-dev] Bitcoin still using ZMQ?

Thanks, Dave. Yeah, that’s as far as I got before deciding to shave that yak another day. FWIW, the OpenMAMA build docs also mention this: https://openmama.finos.org/openmama_build_instructions.html > On Nov 25, 2020, at 6:07 PM, Dave Walker wrote: > > On Wed, 25 Nov 2020 at 22

Re: [zeromq-dev] Using DRAFT methods of zeromq's build libraries

May not be relevant to czmq, but vanilla libzmq has a hack in its CMakeLists.txt (checks for .git directory and enables draft if found): if(EXISTS "${CMAKE_SOURCE_DIR}/.git") message(STATUS "Build and install draft classes and methods") option(ENABLE_DRAFTS "Build and install draft classes

Re: [zeromq-dev] Design for a Pub/Sub system

> In any case, one question of mine has remained unanswered so far: > How does one realize horizontal scaling? So far everyone seems to assume a > single machine/node. > > Regardless of the socket type used, I will run into some limit at some point. > Then I need to add nodes to the cluster.

Re: [zeromq-dev] Design for a Pub/Sub system

Hi Yanone: My take is that the main question you need to answer is network architecture. With PUB/SUB over TCP (http://api.zeromq.org/master:zmq-tcp) you may run into resource scalability issues — e.g., number of sockets, etc. with the number of subscribers you expect. (Bear in mind that

Re: [zeromq-dev] Memory footprint of process bound to PUB socket increases as subscribers connect

Hi Harry: Not sure if this is relevant, but we had a similar-sounding problem — check out https://github.com/zeromq/libzmq/issues/3186 and see if it might be helpful. Regards, Bill > On Nov 4, 2020, at 2:54 AM, Harry Mander via zeromq-dev >

Re: [zeromq-dev] Memory footprint of process bound to PUB socket increases as subscribers connect

ckopt`, or > calling `zmq_poll` on the PUB socket immediately after a message is sent > still doesn't fix the issue even after SUB sockets are closed. I will keep > digging... > > On Thu, 5 Nov 2020 at 02:56, Bill Torpey <mailto:wallstp...@gmail.com>> wrote: > Hi Harr

Re: [zeromq-dev] FD resource leak when opening and closing an inproc socket

the GitHub issues instead of email. At least in my experience, that tends to get more visibility, and is also easier to refer back to than emails. > > Best regards, > > Itay Chamiel, OrCam > > > On Mon, Jan 4, 2021 at 6:07 PM Bill Torpey <mailto:wallstp...@

Re: [zeromq-dev] Dafka towers

Hi All: On a related note, we use a similar approach to discovery in OZ (https://github.com/nyfix/OZ/blob/master/doc/Naming-Service.md ), with some differences: + OZ also uses UUIDs to identify nodes ~ In OZ, the “towers” are

Re: [zeromq-dev] FD resource leak when opening and closing an inproc socket

Hi Itay: Take a look at https://github.com/zeromq/libzmq/issues/3186 — it may be relevant to the behavior you’re seeing. The short version is that process_commands needs to get a chance to run on the socket to clean up resources. If that isn’t

Re: [zeromq-dev] zeromq protocol_error handling

Sorry — meant to get back to you sooner, but it’s been a crazy week. You don’t say what version you’re running, but there have been some changes in that area not that long ago — check these out and see if they help: https://github.com/zeromq/libzmq/pull/3831

Re: [zeromq-dev] zeromq protocol_error handling

CESS_ERRNO (zmq_connect (sub, end)); > > msleep(100); > > send_string_expect_success (pub, "Hello", 0); > > msleep(100); > > recv_string_expect_success (sub, "Hello", 0); > > msleep(100); > > test_context_socket_cl

Re: [zeromq-dev] zeromq protocol_error handling

l check/reply to rest of points later ( im in the pub ) but that is the > point. The protocol_error stops everything so no more reconnect from the pub > socket. Its effectively a zombie as it's terminated but still the endpoint is > registered on the socket. > > Cheers > > James > >

Re: [zeromq-dev] zeromq protocol_error handling

er OSS projects, ZeroMQ is a side gig for them, so bear that in mind. Regards, Bill > > > > > On Fri, 21 May 2021, 21:16 Bill Torpey, <mailto:wallstp...@gmail.com>> wrote: > Hey James: > > Going back over your original scenario: > >>

Re: [zeromq-dev] Formally modelling the publish-subscribe pattern

Hi John: My two cents, based on empirical observation, rather than inspection of the code... > • Message contents are never altered. Correct. > • Messages between two processes are not duplicated in transit. That would depend on the underlying transport — e.g., with TCP this is correct > •

Re: [zeromq-dev] libev and ZMQ

Hi Arun: This thread may be helpful: https://lists.zeromq.org/mailman/private/zeromq-dev/2014-July/026350.html It appears from the thread that it’s not a good idea to rely on the events being level-triggered, and that

Re: [zeromq-dev] Memory accumulation of Python-based PUB/SUB

Hi Jan: First step I would think would be to determine if the memory usage is coming from the python code or from libzmq itself. Are you able to do that? Regards, Bill > On Oct 20, 2021, at 5:46 AM, Yanone wrote: > > Hi everyone, > > I’m implementing a long-running PUB/SUB server using

Re: [zeromq-dev] Modelling ZeroMQ formally

that the startup sequence was sufficient to guarantee that we could never miss a connection message, but intuitively it seems that the heartbeats are probably unnecessary. I’d certainly be interested in working with you to try to come up with a formal proof, either way. Best Regards, Bill Torpey > On

Re: [zeromq-dev] ZMQ performance diff b/w RHEL7 and RHEL8

> >>lsb_release -a >> >> LSB Version::core-4.1-amd64:core-4.1-noarch >> >> Distributor ID: RedHatEnterprise >> >> Description:Red Hat Enterprise Linux release 8.5 (Ootpa) >> >> Release:8.5 >> >&

Re: [zeromq-dev] ZMQ performance diff b/w RHEL7 and RHEL8

Hi Jasper: I’d be VERY interested in knowing what version of RH7 you’re running: uname -a lsb_release -a I’m seeing weird network performance on CentOS 7, as of kernel version 1062 (part of 7.7) —earlier kernel version 957 (part of 7.6) is fine. Curious if that’s related to what you are

Re: [zeromq-dev] Unreasonable behavior of a socket when connection can't be established. How to enable the blocking mode on a socket?

Hi Yuri: There are a couple ways to deal with the situation(s) you describe, which can be used together. 1. You can set options on the socket to change ZMQ’s default reconnection algorithm: ZMQ_RECONNECT_STOP_CONN_REFUSED ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED

Re: [zeromq-dev] Unreasonable behavior of a socket when connection can't be established. How to enable the blocking mode on a socket?

> On 9/28/22 07:20, Bill Torpey wrote: >> >> 1. You can set options on the socket to change ZMQ’s default reconnection >> algorithm: >> >> ZMQ_RECONNECT_STOP_CONN_REFUSED >> ZMQ_RECONNECT_STOP_HANDSHAKE_FAILED >> ZMQ_RECONNECT_STOP_AFTER_DISCONNECT

Re: [zeromq-dev] ZMQ SUB and PUB questions

Hi Joris: This is an ancient bug/feature in ZeroMQ, and some earlier discussions can be found [here](https://github.com/zeromq/libzmq/issues/2267). There are a couple of things going on here that contribute to the problem: - Connections in ZeroMQ are done asynchronously — when you call

Re: [zeromq-dev] Adding new zmq_getsockopt() to retrieve number of subscriptions from XPUB socket

added/removed also on the socket monitor... but that's a lot of more > detailed information... I think the basic use case is just to get the > whole number of subscriptions (for debugging you often know how many > subscriptions were sent and it's useful to check if any subscription > has

Re: [zeromq-dev] Adding new zmq_getsockopt() to retrieve number of subscriptions from XPUB socket

The problem with all the socket monitor stuff is that it’s async — that makes it dangerous to act on. It’s great for monitoring/debugging -- for real-time control not so much. Arnaud’s PR sounds useful — more visibility can only be a good thing. Bill > On Nov 15, 2022, at 10:43 AM, Arnaud

Re: [zeromq-dev] Adding new zmq_getsockopt() to retrieve number of subscriptions from XPUB socket

an > existing PR to add more visibility (I'd love that)? Or you're > referring to the proposal I did in my first mail? > > thanks, > Francesco > > Il giorno mar 15 nov 2022 alle ore 22:58 Bill Torpey > ha scritto: >> >> The problem with all the socket monitor s

Re: [zeromq-dev] Time-reordering queue

sites.net/pubs/time-clocks.pdf>. Hope this helps. Bill Torpey > On Nov 9, 2022, at 5:19 PM, Francesco wrote: > > Hi all, > > I have written two applications using ZMQ PUB-SUB pattern (over TCP > transport). > The subscriber application has its SUB socket connected

Re: [zeromq-dev] PUB/SUB missed initial message even using monitor events (possibly just #2267, but not sure)

cts have done that, two examples being Zyre and OZ (https://github.com/nyfix/OZ <https://github.com/nyfix/OZ>), which I created. You may be able to use one of these "out-of-the-box”, or get some ideas on problems they’ve had to solve. Hope this helps. Bill Torpey > On Feb 4,

Re: [zeromq-dev] PUB/SUB missed initial message even using monitor events (possibly just #2267, but not sure)

Hey Jason: Btw, I’m assuming connection-oriented (e.g., TCP) transport here. Semantics could be very different w/other mechanisms. > On Feb 6, 2023, at 8:10 PM, Jason Heeris wrote: > > Because my pub sockets always bind, and my sub sockets always > connect. Then everything should be fine

Re: [zeromq-dev] PUB/SUB missed initial message even using monitor events (possibly just #2267, but not sure)

> On Feb 7, 2023, at 8:54 PM, Jason Heeris wrote: > > On Wed, 8 Feb 2023 at 05:41, Bill Torpey wrote: >> Btw, I’m assuming connection-oriented (e.g., TCP) transport here. Semantics >> could be very different w/other mechanisms. > > No, IPC (ie. Unix sockets i

Re: [zeromq-dev] [zeromq-announce] When is new version of libzmq getting released?

Hi All: FWIW, in my shop procedures to release code into prod are very strict, and versioning is a key part of that. A single release consists of a dozen or so component packages — some of these are open-source project hosted by others (e.g., https://github.com/zeromq/libzmq