) message to
a worker which will trigger EHOSTUNREACH for disconnected workers, but it
will queue up in busy workers. I wouldn't even consider this as a
workaround...
Any ideas solve this correctly?
Regards,
Gyorgy Szekely
___
zeromq-dev mailing list
zeromq
bocca...@gmail.com>
wrote:
> On Fri, 2017-02-17 at 10:53 +0100, Gyorgy Szekely wrote:
> > Hi,
> > Sorry for spamming the list :( I will rate limit myself.
> >
> > I reviewed the docs for ZMQ_ROUTER_MANDATORY and it's clear now that
> > the
> > router s
ory, that it will report EAGAIN, but
this contradicts with the documentation.
Can you help to clarify?
Regards,
Gyorgy
It
On Thu, Feb 16, 2017 at 12:22 PM, Gyorgy Szekely <hodito...@gmail.com>
wrote:
> Hi,
> Continuing my journey on detecting dead workers I reduced the design t
Hi,
The implemented protocol (ZMQ-RFC 7/MDP) has application level mutual
heartbeating between the broker and the worker. And this works fine: both
parties detect if the other side dies via missing heartbeats. The problem
appears when the worker is assigned a long running job, heartbeating is
um time for a job, after which you consider
> the worker dead. If not dead you can handle the reconnection then.
>
> On Feb 14, 2017 17:33, "Gyorgy Szekely" <hodito...@gmail.com> wrote:
>
>> Hi,
>> The implemented protocol (ZMQ-RFC 7/MDP) has appl
.)
What's your opinion on this?
Regards,
Gyorgy
On Thu, Feb 16, 2017 at 10:44 PM, Gyorgy Szekely <hodito...@gmail.com>
wrote:
> Hi,
> I dug a bit deeper, here are my findings:
> - removing the on/off switching for the ZMQ_ROUTER_MANDATORY flag, and
> enabling it before the
Hi ZeroMQ community,
In our application we use ZeroMQ for communication between backend services
and it works quite well (thanks for the awesome library). Up to now we
relied on the request/reply pattern only (a majordomo derivative protocol),
where a broker distributes tasks among workers.
who load balances for a scaling group.
>
> This all depends on volume and failure scenarios too.
>
> On Tue, Dec 5, 2017 at 5:38 AM Luca Boccassi <luca.bocca...@gmail.com>
> wrote:
>
>> On Tue, 2017-12-05 at 09:03 +0100, Gyorgy Szekely wrote:
>> > Hi ZeroMQ commun
, Dec 7, 2017 at 3:32 PM Gyorgy Szekely <hodito...@gmail.com> wrote:
>
>> Thanks guys for the answers. For some reason I didn't consider push-pull
>> in the first place, but it suits my need quite well. :)
>>
>> My only concern is about recovery from failures. Let's
Hi Simon,
This is great news! We're using cppzmq in a message broker and an
accompanying communication library for 2 years now.
I fully agree with the declared goals. libzmq has a simple and concise API
with object oriented mindset. It works well on its own, but cppzmq makes it
a whole lot
Hi Tomer
As far as I know the message from the publisher will reach the broker.
According to the docs, the PUB socket drops messages in mute-state (HWM
reached), and it's not the case here. The message will be sent as soon as
the connection is established, and the socket termination blocks until
put queue. Is this true?
Regards,
Gyorgy Szekely
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
iovector based functions, but I don't think
it's good idea to start building new code on these... (do they work at all
with threadsafe sockets?)
Any other idea, comments?
Regards,
Gyorgy Szekely
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
ducers...
Is there any better way to do this? I would rather not reinvent the wheel,
TCP already has a sophisticated mechanism for this.
Regards,
Gyorgy Szekely
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev
Thank you guys for the answers!
That's plenty of information to get me going.
Regards,
Gyorgy Szekely
On Thu, May 14, 2020 at 6:13 PM Brett Viren wrote:
> I was going to reply similarly. Once a message is outside a socket,
> it's out of ZeroMQ's hands and the responsi
15 matches
Mail list logo
