Folks,
I'm considering changing the Identities of my sockets instead of
closing and re-opening them after a REQ/REP protocol failure (where
I've received an extra reply via an XREP/XREQ forwarder discussed in
the timeout thread).
The documentation says:
If the socket has no identity, each
Hi all,
I've written an introduction to ZeroMQ for my blog, you can find it here:
http://nichol.as/zeromq-an-introduction
I would like to thank Martin and Chuck for proofreading it.
Cheers,
Nicholas Piël
___
zeromq-dev mailing list
On Wed, Jun 23, 2010 at 10:54 AM, Nicholas Piël nicho...@nichol.as wrote:
I've written an introduction to ZeroMQ for my blog, you can find it here:
http://nichol.as/zeromq-an-introduction
I would like to thank Martin and Chuck for proofreading it.
Pretty neat!
I have some inevitable
On Wed, Jun 23, 2010 at 11:32 AM, Nicholas Piël nicho...@nichol.as wrote:
Thanks Pieter! I have applied your suggestions.
over-engineered definitely works better. :-) Another tiny typo in
the first paragraph, your good to go - you're good to go.
Let the tweets begin!
-Pieter
Hi Matt,
I'm considering changing the Identities of my sockets instead of
closing and re-opening them after a REQ/REP protocol failure (where
I've received an extra reply via an XREP/XREQ forwarder discussed in
the timeout thread).
The identity is applied to particular bind or connect.
Hello
I am new to 0MQ so please excuse me if this topic was already covered
somewhere. We are trying to understand how current design of 0MQ (version 2 I
believe - development branch) is handling faults (or scaling) of device nodes
(like streamer or forwarder). In other words we are trying to
Hi Michael,
I am new to 0MQ so please excuse me if this topic was already covered
somewhere. We are trying to understand how current design of 0MQ
(version 2 I believe – development branch) is handling faults (or
scaling) of device nodes (like streamer or forwarder). In other words we
Hi Martin
I think I understand your suggestion, however setting p2p connections strikes
me as a bit un-elegant since configuration of such pipeline (or rather
processing node in the pipeline) may quickly become a nightmare :) Are you
planning some location or directory services for version 2?
On Tue, Jun 22, 2010 at 3:00 PM, Martin Sustrik sust...@250bpm.com wrote:
I think we are missing this kind of discussion of pipeline paradigm in
the documentation.
Once I wrote this article:
http://www.zeromq.org/tutorials:butterfly
However is misses the overall introduction (and the code
On Fri, Jun 18, 2010 at 1:37 PM, Peter Alexander vel.ac...@gmail.com
wrote:
John I agree, and along the same accord I'd like to mention J. Paul
Morrison [1] and Flow Based Programming [2].
Thanks for the pointer to FBP, it's an interesting read.
-Pieter
Let me add a pointer to an
If I take the Java bindings, and run the latency or throughput test, things
work fine. But if I jack the iterations up by an order of magnitude, I get the
following error:
Exception in thread main java.lang.Exception: 156384765 - 0x9523dfd - Context
was terminated at
Hi Stuart,
If I take the Java bindings, and run the latency or throughput test,
things work fine. But if I jack the iterations up by an order of
magnitude, I get the following error:
Exception in thread main java.lang.Exception: 156384765 - 0x9523dfd
- Context was terminated at
I've written an introduction to ZeroMQ for my blog, you can find it here:
http://nichol.as/zeromq-an-introduction
I would like to thank Martin and Chuck for proofreading it.
Cheers,
Nicholas Piël
Nicholas, this is an excellent article. Thanks a lot!
One gripe (disguised as a
Hi Nicholas,
On Wed, Jun 23, 2010 at 4:54 AM, Nicholas Piël nicho...@nichol.as wrote:
Hi all,
I've written an introduction to ZeroMQ for my blog, you can find it here:
http://nichol.as/zeromq-an-introduction
I also want to congratulate you on a great introductory article. Very
concise..
I think you are on the right track. Looking at the native jzmq code,
it appears that transiently using a Context object to construct
Sockets would allow the JVM to finalize the Context object while the
application still has a live reference to the Socket object(s).
Something like this:
If the context represents any real resources on the native side, I would
recommend going in the opposite direction:
(1) Clients should create and hold the context, and explicitly close it when
they are done.
(2) Ditto for sockets (except that creation is via the context).
(3) Neither Context
P.S. Stuart, is your work in this space related to Clojure?
Not specifically. We have client projects that live on the JVM and would
benefit from something simpler and lighter-weight than e.g. ActiveMQ. Of course
I will probably code it in Clojure. ;-)
On Wed, Jun 23, 2010 at 7:23 PM, Stuart Halloway s...@thinkrelevance.com
wrote:
If the context represents any real resources on the native side, I would
recommend going in the opposite direction:
(1) Clients should create and hold the context, and explicitly close it when
they are done.
18 matches
Mail list logo
