Your example works fine for me if you change the tcp PUB endpoint
transport to inproc.
I'm not sure what's going on, but the guide mentions only sharing
contexts between threads with inproc transports. I think bind is
synchronous but connect isn't, so perhaps your threads are
synchronizing faster
Hello,
I would like to use ZMQ for some kind of resource publishing support (or
some kind of zero configuration). I thought about a local multicast or
UDP solution.
The services should just send periodically their server infos into the
multicast network (which could be a push) and the clients
Hello All,
After a long time i have a question and it seems to be the simple one.
I am using following code to receive something using PyZMQ:
import zmq
zmqContext = zmq.Context()
recevSock = zmqContext.socket(zmq.SUB)
recevSock.connect('address')
recevSock.setsockopts(zmq.SUBSCRIBE.' ')
Hello Ronald.
This works for me :)
recevSock.recv(flags=zmq.NOBLOCK)
This will rase and exception you will have to handle it :)
so
try:
recevSock.recv(flags=zmq.NOBLOCK)
except zmq.core.error.ZMQError,e:
if str(Resource temporarily unavailable) in e:
# Socket not ready
return None
else:
Hello Antonio,
thanks a lot for quickest reply :-)
I got your way of using NOBLOCK, but can you brief me more about how i can use
zmq.poll here using the POLLIN and POLLOUT events.
Regards
Ronald
Date: Tue, 3 Apr 2012 09:27:24 +
From: eagle.anto...@gmail.com
To:
You can find here a couple of examples :
https://github.com/zeromq/pyzmq/blob/master/examples/poll/pubsub.py
https://github.com/zeromq/pyzmq/tree/master/examples/poll
And the API
http://zeromq.github.com/pyzmq/api/generated/zmq.core.poll.html
Just take into consideration that if you want to
I got your way of using NOBLOCK, but can you brief me more about how i can
use zmq.poll here using the POLLIN and POLLOUT events.
Here's an (edited) highlight from our codebase:
control_socket = self.context.socket(zmq.SUB)
control_socket.setsockopt(zmq.SUBSCRIBE, '')
The guides you provided suggests me to fork against zeromq/libzmq.
But the code in ' libzmq' somewhat changed from 'zeromq2-1' which I currently
use.
How these changes will be backported to 2.1 code? (of course if they fully
backward compatible)
Or I should provide patches against zmq2.1?
P.S.
On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier
pelletier.mic...@gmail.com wrote:
Your example works fine for me if you change the tcp PUB endpoint
transport to inproc.
This means that it doesn't work, does it? I mean, my program
establishes an unequivocal temporal sequence, that somehow is
On Tue, Apr 3, 2012 at 11:55 AM, Sergey Hripchenko
shripche...@intermedia.net wrote:
The guides you provided suggests me to fork against zeromq/libzmq.
But the code in ' libzmq' somewhat changed from 'zeromq2-1' which I currently
use.
How these changes will be backported to 2.1 code? (of
I back ported the fix in https://github.com/zeromq/zeromq2-1/pull/45
The issue is logged in https://zeromq.jira.com/browse/LIBZMQ-349
Joshua
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Very nice work. I've backported it to 2.1, it'll go in the next release.
Small point for improvement, please write issues as problems rather
than solutions, so e.g. Send/receive timeouts missing, makes REQ
sockets less useful.
-Pieter
On Tue, Apr 3, 2012 at 1:20 PM, Joshua Foster
PUSH/PULL is not multicast, if I get your meaning correctly. If you
connect PUSH/PULL N-to-N then only one consumer will get any given
message. I think what you want is PUB/SUB, in which all consumers get
all messages.
Almost everything is possible with zeromq. :) Did you read the guide?
On Tue, Apr 3, 2012 at 4:16 AM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier
pelletier.mic...@gmail.com wrote:
Your example works fine for me if you change the tcp PUB endpoint
transport to inproc.
This means that it doesn't work, does
On Apr 3, 2012, at 7:30 AM, Pieter Hintjens wrote:
Very nice work. I've backported it to 2.1, it'll go in the next release.
Small point for improvement, please write issues as problems rather
than solutions, so e.g. Send/receive timeouts missing, makes REQ
sockets less useful.
-Pieter
On Tue, Apr 3, 2012 at 3:34 PM, Michel Pelletier
pelletier.mic...@gmail.com wrote:
On Tue, Apr 3, 2012 at 4:16 AM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Tue, Apr 3, 2012 at 7:36 AM, Michel Pelletier
pelletier.mic...@gmail.com wrote:
Your example works fine for me if you change
Ah I understand,
all service offeres are PUB candidates and all my clients are SUB
candidates and this works over Multicast - ok. I'll try an implementation.
I've implemented only the first examples for my VASmalltalk bindings so
far, but now I've a need for a specific practical problem ...
On Tue, Apr 3, 2012 at 3:38 PM, Chuck Remes li...@chuckremes.com wrote:
If we are following the rules of semantic versioning, this new feature should
cause a 2.2.0 release. New features that do not break backward compatibility
cause a minor version increase.
You are right that this goes
On Apr 3, 2012, at 10:13 AM, Pieter Hintjens wrote:
On Tue, Apr 3, 2012 at 3:38 PM, Chuck Remes li...@chuckremes.com wrote:
If we are following the rules of semantic versioning, this new feature
should cause a 2.2.0 release. New features that do not break backward
compatibility cause a
On Tue, Apr 3, 2012 at 5:25 PM, Chuck Remes li...@chuckremes.com wrote:
So, in my opinion, there is no reason to go off our own and develop a new
policy for version numbering. The semantic versioning policy is pretty well
understood and is widely accepted. Plus, even if it isn't perfect, it
So to collect options:
* Start on a 2.2 release which has space for backwards-compatible
improvements to 2.1
* Change the release policy to separate ABI versioning from product versioning
* Freeze all improvements to 2.x and allow these only in 3.1
Votes and opinions welcome.
-Pieter
I've verified that using tcp req/rep synchronization works with my
example. I agree that inproc sync makes no point if sockets are to
talk across processes. But the example is about synchronization, it's
just a toy to understand what can I build on.
So, you say there is no guarantee that
under testing at 1/5 full load, my system stats includes this table for a hot
hour:
Summary: total ave rate
inbound 33.24M 170.5GB 9.233K/s 47.37MB/s
outbound 106.0M 6.401GB 29.45K/s 1.778MB/s
internal 3.321G 555.2GB 922.6K/s 154.2MB/s
for your
Thank you!
--CM
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Andrew Hume
Sent: Tuesday, April 03, 2012 10:28 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] Some real perfomance numbers from real workloads
under testing at 1/5
On Apr 3, 2012, at 11:49 AM, Pieter Hintjens wrote:
On Tue, Apr 3, 2012 at 5:25 PM, Chuck Remes li...@chuckremes.com wrote:
So, in my opinion, there is no reason to go off our own and develop a new
policy for version numbering. The semantic versioning policy is pretty well
understood and
On Tue, Apr 3, 2012 at 7:21 PM, Chuck Remes li...@chuckremes.com wrote:
Sure, they want fixes in 2.1 because 3.1 sounds like a big leap. There
actually is quite a bit of new and different code in the 3.1 branch, so I
can sympathize. What I *do not understand* is this insistence that fixes
and
+1 on 2.2 with space for backwards compatible enhancements. Ideally everything
added would be backported from master.
0 to ABI/product versioning split
-1 to no improvements in 2.x. IMO that should happen when 3.x hits stable, and
2.x should be moved to bugfix only for a period and then
+1 on 2.2. keep the concept that 2.x is a feature bump and 2.x.x is a patch.
It doesn't have to correlate to the size of the release.
-1 to no improvements to 2.x. I don't think it should be a policy. If people
want to maintain older releases, thats up to them. I would hope that as
things
I agree with all previous posters, +1 on 2.2. Semver is easy to
understand. You could refactor the code as much as you want but if it
doesn't change the ABI then it is should only be 2.x.x release.
On 4 April 2012 08:21, Joshua Foster jhaw...@gmail.com wrote:
+1 on 2.2. keep the concept that 2.x
29 matches
Mail list logo
