Hello,
Is there a policy to drop an oldest packet first (with the high-watermark
option)? In particular, it is oftentimes desired, only to save the most
recent message received.
--
Daniel Krikun
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
h
I don’t think so, but I do arguing for that option too.
Specially for PUB->bind() and multiple SUB->connect() scenarios.
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Daniel Krikun
Sent: Thursday, April 12, 2012 11:25 AM
To: zeromq-dev@lists.z
It's an old discussion; dropping the oldest message for PUB-SUB would
be more logical than dropping the newest, but it was always considered
too hard to do. If you want to try it, and send a patch, people would
appreciate that IMO.
-Pieter
On Thu, Apr 12, 2012 at 9:42 AM, Sergey Hripchenko
wrote
I am new to ZeroMQ, I have following codes:
Dealer is following:
public class rrbroker {
public static void main (String[] args) {
// Prepare our context and sockets
Context context = ZMQ.context(1);
Socket backend = context.socket(ZMQ.DEALER);
backe
On Thu, Apr 12, 2012 at 9:11 AM, Pieter Hintjens wrote:
> It's an old discussion; dropping the oldest message for PUB-SUB would
> be more logical than dropping the newest, but it was always considered
> too hard to do. If you want to try it, and send a patch, people would
> appreciate that IMO.
>
On Thu, Apr 12, 2012 at 12:32 PM, Ian Barber wrote:
> It is worth noting that the oldest in many cases will be in the buffers of
> the transport, so you will in reality be dropping the oldest-in-zmq-space.
> There's a high chance of receiving some old messages on the other end.
> Still, might be
Daiweixing,
- Use a valid IP address in your URL
- Call bind only on the server side.
- Use the connect method on the client to "connect" to the bound server
- Use ZMQ.REQ in the server instead of ZMQ.DEALER.
- Your server is not actually sending anything.
Move the for l
I would recommend reading the guide. You will want to start out just using
PUSH/PULL, REQ/REP, and PUB/SUB for learning ZeroMQ. Dealer and Router sockets
are a little more advanced (and have their place). It looks like you have the
back half to a work queue (rrbroker is the work distributer and
On 10 April 2012 11:46, Jeff Vienneau wrote:
> Our setup is two Windows XP SP3 systems with just an ethernet
> cable between them (cat 5e, Intel gigabit NICs). Between the two systems, I
> am able to achieve ~70MB/s (using TCP with pcattcp).
>
>
Play around with netperf and iperf and similar mess
folks,
what is the current understanding on memory usage with zmq?
(i care most about 2.1.x or 2.2.x.)
what i recall is that there is a modest problem with fragmentation
and an issue with memory leaks with pub/sub. do i recall correctly?
and what have people done about th
Implement ZMQ_TCP_ACCEPT_FILTER setsockopt() for listening TCP sockets.
Assign arbitrary number of filters that will be applied for each new TCP
transport
connection on a listening socket.
If no filters applied, then TCP transport allows connections from any ip.
If at least one filter is applied
I will try that, however, I don't have the option of changing my 0mq
message sizes. Doesn't ZMQ use 8k transfer segments regardless of message
size?
On Thu, Apr 12, 2012 at 10:07 AM, Steven McCoy wrote:
> On 10 April 2012 11:46, Jeff Vienneau wrote:
>
>> Our setup is two Windows XP SP3 systems
Well, I don't think drop-oldest must be for PUB-SUB pattern only. Though
it's a common use-case, but I think it should better fit somewhere around
hwm socket option for all kind or sockets capable of receiving messages.
On Thu, Apr 12, 2012 at 1:46 PM, Pieter Hintjens wrote:
> On Thu, Apr 12, 20
Hello Friends.
I have hitting a wall since i updated to the latest of ZMQ and PyZmq
Assertion failed: ok (mailbox.cpp:84)
I have tried everything i can remember , probably this is a problem in Zmq
and not PyZmq but i wanted to get the opinion of a more experience member
of the community first.
Now that Salt is getting deployed in ever larger environments we are
running into what appears to be a ZeroMQ bug:
https://github.com/saltstack/salt/issues/891
The zeromq assertion we are seeing is this:
Assertion failed: new_sndbuf > old_sndbuf (mailbox.cpp:183)
I think it is associated with th
On Apr 12, 2012, at 10:45 AM, Antonio Teixeira wrote:
> Hello Friends.
>
> I have hitting a wall since i updated to the latest of ZMQ and PyZmq
>
> Assertion failed: ok (mailbox.cpp:84)
>
> I have tried everything i can remember , probably this is a problem in Zmq
> and not PyZmq but i wanted
Checked :)
Fork = New Process
And there are no shared contexts / sockets or anything.
2012/4/12 Chuck Remes
>
> On Apr 12, 2012, at 10:45 AM, Antonio Teixeira wrote:
>
> > Hello Friends.
> >
> > I have hitting a wall since i updated to the latest of ZMQ and PyZmq
> >
> > Assertion failed: ok
On Thu, Apr 12, 2012 at 4:42 PM, Sergey Hripchenko
wrote:
> Implement ZMQ_TCP_ACCEPT_FILTER setsockopt() for listening TCP sockets.
Merged, nice work. :)
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/l
One more thing using zmq green :D
2012/4/12 Antonio Teixeira
> Checked :)
>
> Fork = New Process
> And there are no shared contexts / sockets or anything.
>
>
>
>
> 2012/4/12 Chuck Remes
>
>>
>> On Apr 12, 2012, at 10:45 AM, Antonio Teixeira wrote:
>>
>> > Hello Friends.
>> >
>> > I have hitti
Can you provide us with a small reproducible example? Also what
version of zmq/pyzmq/gevent are you using?
-Michel
On Thu, Apr 12, 2012 at 9:44 AM, Antonio Teixeira
wrote:
> One more thing using zmq green :D
>
>
> 2012/4/12 Antonio Teixeira
>>
>> Checked :)
>>
>> Fork = New Process
>> And the
Andrew,
Neither of these issues are familiar to me. There's one issue for
memory leaks in XSUB/XPUB which is waiting for a kind person to turn
into a pull request: https://zeromq.jira.com/browse/LIBZMQ-300
-Pieter
On Thu, Apr 12, 2012 at 3:34 PM, Andrew Hume wrote:
> folks,
>
> what is the curr
I had this exact same problem with 2.11. Turned out to be because a single
socket was inadvertently
being shared across multiple threads.
--Corey
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Ant
Thomas
I believe if you upgrade to a later version of zeromq this assertion
will disappear.
This assertion used to appear because a pipe used for command
structures between threads filled up and in that case it's buffer is
attempted to be resized which proved flaky.
In later versions of a sing
Hi, we're discussing some things about a distributed protocol in the
ripple forum and I proposed to use ZeroMQ to build a prototype server.
We want the p2p protocol to be transport independent but we're going
to probably just use TCP as a start.
I posted here before to ask about the possibilities o
ZeroMQ already supports multiple transports. How "would sticking to TCP"
somehow better enable distribution?
Does the OP see some inherent value in inventing your own framing?
--CM
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org]
This is an interesting commit.
Brian
On Thu, Apr 12, 2012 at 12:43 PM, Pieter Hintjens wrote:
> On Thu, Apr 12, 2012 at 4:42 PM, Sergey Hripchenko
> wrote:
>
> > Implement ZMQ_TCP_ACCEPT_FILTER setsockopt() for listening TCP sockets.
>
> Merged, nice work. :)
>
> -Pieter
>
Is this patch a candidate for backporting to 2.x?
On Fri, Apr 13, 2012 at 2:43 AM, Pieter Hintjens wrote:
> On Thu, Apr 12, 2012 at 4:42 PM, Sergey Hripchenko
> wrote:
>
> > Implement ZMQ_TCP_ACCEPT_FILTER setsockopt() for listening TCP sockets.
>
> Merged, nice work. :)
>
> -Pieter
> _
2012/4/12 Jorge Timón :
> Hi, we're discussing some things about a distributed protocol in the
> ripple forum and I proposed to use ZeroMQ to build a prototype server.
> We want the p2p protocol to be transport independent but we're going
> to probably just use TCP as a start.
> I posted here befor
Presumably due to this fix, the current zeromq-2.2.0 tarball reports
version 2.2.1 in zmq.h. I don't know which part is wrong, but the
disagreement should probably be resolved.
-MinRK
On Tue, Apr 10, 2012 at 12:19, Pieter Hintjens wrote:
> NP, thanks for hunting down the problem.
>
> On Tue, A
Thanks Jon, I will keep looking then and recommend the latest version
On Thu, Apr 12, 2012 at 12:37 PM, Jon Dyte wrote:
> Thomas
>
> I believe if you upgrade to a later version of zeromq this assertion
> will disappear.
> This assertion used to appear because a pipe used for command
> structures
30 matches
Mail list logo
