Hi Guys,
Took a stab at reworking the monitoring infrastructure to address the
issues noted in this thread thus far :
https://github.com/methodmissing/libzmq/compare/fix-monitor
Thoughts ?
- Lourens
On Fri, Sep 14, 2012 at 3:44 PM, Bjorn Reese wrote:
> On 2012-09-13 01:14, Paul Colomiets wrot
21.09.12, 8:09, Pieter Hintjens wrote:
> Not quite sure what your use case is, could you paste some sample code?
>
> I'd probably _not_ provide zmq_msg_t to higher level APIs at all. It's
> very low level and semantically vague. Is it a frame, a message? You
> can't even process multi-part data if
On Fri, Sep 21, 2012 at 5:25 PM, Chernyshev Vyacheslav wrote:
> What if I want to hide all 3rd-party dependencies from main application?
> I can easily do it for zmq_context and zmq_socket as they are just void
> pointers, but it is just impossible for zmq message. Sample code may be
> something
21.09.12, 19:43, Pieter Hintjens wrote:
> Right... well, make the pull request, if you want to.
Done. Here is a link: https://github.com/zeromq/libzmq/pull/425
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listi
Hi All
I am working on zeromq with pgm as the transport. I have two boxes set up for
multicast. I'm using latest head revision: zeromq-libzmq-7a40df6 and am able to
publish from one box, receive on the other box.
However when I try the other way round I get an error on the subscriber side...
On Fri, Sep 21, 2012 at 6:04 PM, Chernyshev Vyacheslav wrote:
> Done. Here is a link: https://github.com/zeromq/libzmq/pull/425
Thanks! I've merged it.
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/lis
On Fri, Sep 21, 2012 at 5:41 PM, RohanB wrote:
> I am working on zeromq with pgm as the transport. I have two boxes set up for
> multicast. I'm using latest head revision: zeromq-libzmq-7a40df6 and am able
> to
> publish from one box, receive on the other box.
>
> However when I try the other wa
Pieter Hintjens imatix.com> writes:
>
> On Fri, Sep 21, 2012 at 5:41 PM, RohanB cs.uchicago.edu> wrote:
>
> > I am working on zeromq with pgm as the transport. I have two boxes set up
for
> > multicast. I'm using latest head revision: zeromq-libzmq-7a40df6 and am
> > able
to
> > publish fr
On Fri, Sep 21, 2012 at 6:20 PM, RohanB wrote:
> Thanks for your reply but I'm certain there is no 2.X version being used...
> Here's the ldd on the executable showing that I'm using version 3 .so.
OK, could you try to get a minimal reproducible case and create an
issue? We'll fix it asap.
Than
Pieter Hintjens imatix.com> writes:
>
> On Fri, Sep 21, 2012 at 6:20 PM, RohanB cs.uchicago.edu> wrote:
>
> > Thanks for your reply but I'm certain there is no 2.X version being used...
> > Here's the ldd on the executable showing that I'm using version 3 .so.
>
> OK, could you try to get a m
I'm working on a Majordomo implementation in Perl using the ZeroMQ-0.21 wrapper
and have a mystery concerning AnyEvent support with it.
I'm using AE to drive the broker (using AE I/O watchers for incoming traffic on
the worker and client sockets, and setting up AE timers to handle heartbeats
an
On Sep 21, 2012, at 2:30 PM, Robert Olson wrote:
> However, in my client, if I set up AnyEvent to wait for the reply from the
> broker I am never notified. The client works perfectly if I use a synchronous
> receive on the socket.
Interesting: in the async code if I issue a nonblocking recv() be
Hi,
On Fri, Sep 21, 2012 at 9:11 PM, Robert Olson wrote:
> On Sep 21, 2012, at 2:30 PM, Robert Olson wrote:
>> However, in my client, if I set up AnyEvent to wait for the reply from the
>> broker I am never notified. The client works perfectly if I use a
>> synchronous receive on the socket.
>
On Sep 21, 2012, at 5:31 PM, Pedro Melo wrote:
> Hi,
>
> On Fri, Sep 21, 2012 at 9:11 PM, Robert Olson wrote:
>> On Sep 21, 2012, at 2:30 PM, Robert Olson wrote:
>>> However, in my client, if I set up AnyEvent to wait for the reply from the
>>> broker I am never notified. The client works perf
Hey folks,
I brought up this problem a few months back, but had to move onto more
pressing things at the time.
It was mentioned that under the hood, the PUB-SUB system had individual
outgoing queues, each with their own water mark counters. What happens
to a message when all queues are full? I
Another behavior that may be acceptable is blocking the sender if all outgoing
queues are full. I believe the only reason it doesn't block today is because
you wouldn't want one slow subscriber causing all other subscribers to stop
receiving messages.
But there may be apps that rely on writes t
On Wednesday 19, Christian Martinez wrote:
> Maybe I'm missing something here, but are people asserting here that one
> can't do a request reply MEP with various RPC technologies and exceed 1000
> 1KB messages a second?
With only 1 client and 1 concurrent request, then yes. The msg/sec throughput
As far as I know, it doesn't block. I also think that we should make
sure that slow subscribers not cause trouble for others. If we notify
when all queues are full, then the application code would be bound by
the fastest subscriber, not the slowest. In my example code I put a
sleep(), but it co
On Friday 21, Robert G. Jakabosky wrote:
>
> With only 1 client and 1 concurrent request, then yes. The msg/sec
> throughput will be limited by latency in this case. Both client & server
> will be maxing out their CPUs, each will be sitting idle most of the time
correction: ... will *not* be ma
I should also be specific and point out that in my case it's fine that
some subscribers don't receive everything.
When I say the data is thrown out, not a single subscriber ever receives
it. It's also problematic because my application code has no idea that
the secret ZeroMQ internals are still
Hi,
When does a write to ROUTER block? Is it if the identified connection has a
full queue? Does this mean it would be possible to write to the socket in non-
blocking mode with one connection id and get EAGAIN, but then write to the
same socket using a different connection id and succeed, even
Right. I see this really as a flow control problem. Here's another angle to
look at it: what if your pub socket has no subscribers? In that case you
probably wouldn't want to be writing to the socket at max speed either. Maybe
that's an edge case not worth covering, but I wonder if it helps you
Hi, I'm the maintainer of perl ZMQ modules.
I'm away fron my computer atm, so can only guess, but does it work if you
put a
AnyEvent::Util::fh_nonblocking($fd)
before creating the IO watcher?
and yes, for new code you should be using ZMQ::LibMQ2.
2012年9月22日土曜日 Robert Olson ol...@mcs.anl.gov:
>
Completely agree here Justin. It would probably be best to work like
normalish sockets (where there's one sender, one receiver) where if it's
set to blocking, it would block when all queues are full, but if
non-blocking it would return false on send and set errno to EAGAIN when
all queues are f
On Sat, Sep 22, 2012 at 2:23 AM, Justin Karneges wrote:
> When does a write to ROUTER block? Is it if the identified connection has a
> full queue?
ROUTER sockets *drop* messages when the HWM is reached.
> Also, if the identified connection does not exist, I assume the socket drops
> the messag
On Sat, Sep 22, 2012 at 12:57 AM, Edwin Amsler
wrote:
> It was mentioned that under the hood, the PUB-SUB system had individual
> outgoing queues, each with their own water mark counters. What happens
> to a message when all queues are full?
This is such an unlikely case... almost contrived. The
26 matches
Mail list logo
