On 06/28/2011 05:57 AM, Artur Brugeman wrote:
It's based on XREP sockets now. I've given quite a lot thinking to it,
and can share my experience.
Please, do so.
Martin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
Trivial patch to make the codebase more comprehensive.
From f8bf3a4cef6b8e1688683ab8c5ed6dd1bc8e3a12 Mon Sep 17 00:00:00 2001
From: Martin Sustrik sust...@250bpm.com
Date: Mon, 27 Jun 2011 18:16:53 +0200
Subject: [PATCH] Rename i_inout to i_engine_sink
Signed-off-by: Martin Sustrik
From 543ad30e7d15a8864df26d6d32e57246ede35ae3 Mon Sep 17 00:00:00 2001
From: Martin Sustrik sust...@250bpm.com
Date: Tue, 28 Jun 2011 10:22:27 +0200
Subject: [PATCH] Packaging for MSVC build fixed
MSVC project files for inproc_lat and inproc_thr were not
packaged during make dist phase.
Andrew,
On June 24, 2011 08:41:13 PM Andrew Hume wrote:
henry,
i'm not sure i followed all your examples, but i detected a general meme
which others have complained of in the past. i admit to being sensitised
to this issue because i have worked in this area for over a decade now.
Hi,
I am using zeromq in a project and I like it. I am using the raw c api, and my
project is very self-contained, so there are a minimum of change management
issues for me. A colleague is in a different situation. He has code that uses
zeromq sprinkled between various python and java
Hi George,
First off, you should all be using the stable 2.1.x packages, unless
you have specific reasons for using 3.0 from github (and you then
expect and understand the reasons for API changes).
Second, the language bindings are starting to hide the API changes (at
least Pyzmq and CZMQ do
I don't know what is happening here, in Debian packaging it is clear there
are no C++ headers but in ArchLinux they are available.
http://packages.debian.org/sid/amd64/clang/filelist
http://www.archlinux.org/packages/extra/x86_64/clang/files/
I can see them in the GCC frontend for LLVM:
On 28 June 2011 12:56, Steven McCoy steven.mc...@miru.hk wrote:
I don't know what is happening here, in Debian packaging it is clear there
are no C++ headers but in ArchLinux they are available.
http://packages.debian.org/sid/amd64/clang/filelist
just to expand a little on what pieter said, take heartbeats.
many people, when they first confront those, they think the problem is easy.
at some level it is, but often people realise that a networking heartbeat does
not imply application health, and so they end up doing an application level
I recently saw a comment from Pieter about phasing out persistent queues.
Assuming I got that right, could someone elaborate a bit, or point me
to a thread?
Garrett
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
Hello.
I have used Apache APR (http://apr.apache.org/) based code for my rpc
application. In my tests I found that connecting to Windows 7 or XP server
performance was much worse than connecting to Mac OSX server.
Finally I found this tech note Slow performance occurs when you copy data to a
Hello. I found interesting discussion on Apache dev list about future
development:
http://www.gossamer-threads.com/lists/apache/dev/399806?page=last
4 projects that maybe could form the baseline for something new.
pocore: For base OS portability and memory pooling system.
I was just about to ask about this very thing: durability and identity
should be two different things, and it seems that at present they are tied
together. I could care less about durability, and agree that it should be
built on top of the core, but I think explicit identity is nice to have.
It's
On Tue, Jun 28, 2011 at 3:54 PM, Mike Owens mikeow...@gmail.com wrote:
So are you saying you are getting rid of durability AND identity, or just
durability?
Martin can answer better than me, my observation is that explicit
identities is useful, whereas durability is not, and as you've said,
On Tue, Jun 28, 2011 at 4:08 PM, Martin Sustrik sust...@250bpm.com wrote:
The problem is that explicit identities are messy.
Due to the fact that you need to reconnect old sessions to new
connections via the identity, and it can cross threads, etc...
Perhaps there's a way to get the same
On 06/28/2011 09:44 PM, malist wrote:
Hello. I found interesting discussion on Apache dev list about future
development:
http://www.gossamer-threads.com/lists/apache/dev/399806?page=last
4 projects that maybe could form the baseline for something new.
pocore: For base OS portability and
It's not that big of a deal to me if explicit identities go as well, esp. if
it makes the core code simpler. As long as it's relatively easy to get the
generated identities, it's easy enough to for me to implement a sort of
internal DNS that can use alternate names which map to the 0MQ IDs.
On
Hi Pieter,
The comment was about phasing out durable sockets. The socket queues
are not really message queues
Heh, I was surprise I had used persistent queues -- that other
messaging scheme is dying a hard death for me.
For durable pubsub, we've got the Clone pattern (see Ch5 of the
Guide).
On 06/28/2011 05:03 PM, George Coles wrote:
The breaking changes to the
api never seem to stop, and changes ripple through the binding projects
as maintainers try to keep things stable or, sometimes, they change
their wrapper apis because they have some insight about how to bridge
the
On Tue, Jun 28, 2011 at 4:17 PM, Mike Owens mikeow...@gmail.com wrote:
It's not that big of a deal to me if explicit identities go as well, esp. if
it makes the core code simpler...
It would be good if anyone that actually uses durable sockets explains
their use cases. The one solid usecase I
On 28 June 2011 15:31, malist i mailing.l...@manageapp.com wrote:
I have used Apache APR (http://apr.apache.org/) based code for my rpc
application. In my tests I found that connecting to Windows 7 or XP server
performance was much worse than connecting to Mac OSX server.
Finally I found
On 06/28/2011 04:50 PM, Henry Baragar wrote:
Does queue management fall into the realm of messaging or job
scheduling? If it falls into the realm of messaging, then shouldn't the
queue be end-to-end? If it falls into the realm of job scheduling, then
should 0mq have any queues at all?
I
On 06/28/2011 11:37 PM, Steven McCoy wrote:
0mq uses 8KB message blocks which means XP would be affected (8KB
default) but Vista and 7 are not (64KB default).
The MSDN article states:
This problem occurs if all the following conditions are true:
* The Windows Sockets program uses
On 28 June 2011 17:47, Martin Sustrik sust...@250bpm.com wrote:
This problem occurs if all the following conditions are true:
* A single send call or WSASend call fills the whole underlying socket
send buffer.
So, the problem would occur only if the default socket buffer would be less
On 06/28/2011 11:49 PM, Steven McCoy wrote:
I read it as less than or equal to, a 8KB send would fill the entire 8KB
send buffer.
Ah. It's 8kB :)
Actually, if it helps to solve the problem, we can decrease the block
size in 0MQ to 4kB. The performance tests we've performed couple of
years
MS I would say the usage of term queue originates from the olden days
MS when 0MQ was still thought to be some kind of equivalent to enterprise
MS queueing products. The queues are more like network buffers today.
Buff Sockets? SoS (Sockets on Steroids)? SSS (Simply Smarter Sockets)?
:)
-- Gregg
26 matches
Mail list logo
