make check-TESTS
make[2]: Entering directory
'/home/alian/Desktop/Projects/hts/CodeBlocks/zeromq-4.1.5'
make[3]: Entering directory
'/home/alian/Desktop/Projects/hts/CodeBlocks/zeromq-4.1.5'
PASS: test_system
PASS: test_pair_inproc
PASS: test_pair_tcp
PASS: test_reqrep_inproc
PASS: test_reqrep_tcp
Hello,
Are you doing extensive error checking with ZMQ? If you are flooding the
network, some of your ZMQ clients may be timing out on either end and the
sockets maybe simply closed before they have a chance to send/recv anything?
Mark
On Tue, Jul 7, 2015 at 8:36 AM, Thomas Rodgers
wrote:
> Is
Hello,
I have compiled and used ZMQ on AIX6.1 64 bit OS if that helps. The
difficulty may be in setting up the build system, after that it builds
without issues. If you let us know what you are having trouble with someone
may be able to help you.
M.
On Mon, Sep 1, 2014 at 9:03 PM, Ranjeet Kumar
causes the client bind to
> > fail. I'm investigating...
> >
> > On Sat, Aug 30, 2014 at 3:43 AM, A. Mark wrote:
> >>
> >>
> >> commit 194be05556f819513a6ace77ad386b9eb3ba1942
> >> Merge: 4767fa6 1919f43
> >> Author: Pieter Hintjens
commit 194be05556f819513a6ace77ad386b9eb3ba1942
Merge: 4767fa6 1919f43
Author: Pieter Hintjens
Date: Fri Jul 4 08:48:37 2014 +0200
Merge pull request #20 from xpahos/master
Fixed segfault in curve_selftest function curve_server
-
htly better, though I can't imagine there's a great
> > deal in it.
> >
> >
> > On Tue, Sep 3, 2013 at 2:41 AM, A. Mark wrote:
> >>
> >>
> >> I hope I'm not asking a redundant question and I haven't the time to
> look
> >>
I hope I'm not asking a redundant question and I haven't the time to look
at the ZMQ source code at the moment. What is the underlying search method
for routing messages internally within ZMQ_ROUTER? Assuming it's a perfect
hash - or at least it's some kind of hashing algo based on identity, I
assu
Hi!
Could you provide the command line you used for local_thr/remote_thr? Also
the screen shot of task manager network and CPU would be useful during
bechmarks? I have ran several high perf benchmarks for ZMQ and maybe able
to help you.
Regards, Attila Mark
On Wed, Jul 3, 2013 at 8:46 AM, Stephe
On that subject are there straightforward ways to tweak inproc latency in
the ZMQ configuration, besides msg and socket options?
On Thu, Apr 18, 2013 at 8:46 AM, Martin Hurton wrote:
> You have some control over memory allocation when transporting message
> using ypipes.
> See message_pipe_gran
Hello Davide,
I'm not certain about the implementation of the inproc in ZMQ but I'm
pretty certain it is using pipes. I'm interested in working on this issue
since I've an MPMC queue implemented using ZMQ inproc and ZMQ_ROUTER and
latency is critical of course. If we can improve latency in this a
Hi Lee,
The PUB socket is neutral towards SUBscribers that's why it's a publisher.
Depending on what you are trying to achieve with your mesh you may need to
use different socket pair if you need such "filtering". Did you try
XPUB/XSUB?
On Sun, Apr 14, 2013 at 10:47 PM, Lee Sylvester wrote:
>
Can you supply the entire code? Your dealer and router are running in
separate threads right?
On Fri, Apr 12, 2013 at 7:19 PM, crocket wrote:
> There is "Double Read(String name)" method, and it takes 50~60ms to call
> Read() 1000 times.
>
> I made two message queues that are basically a wrappe
It is difficult to help without understanding more detail about your
application, in general yes you can send/recv in any order on router/dealer.
On Tue, Apr 9, 2013 at 3:38 PM, Rahul & Piyali Ray <8429oakm...@gmail.com>wrote:
> Hi Gurus,
> I have implemented a dealer (server) and router ( a
PM, Garrett Smith wrote:
>
>> On Mon, Apr 8, 2013 at 11:52 AM, A. Mark wrote:
>> > Yes I agree, I've not had a single deadlock in a classic sense since
>> using
>> > message queues. But this statement is like saying I've hand not a car
>> > acc
An example of the code segment in question would be helpful.
On Mon, Apr 8, 2013 at 10:06 AM, West Madison <8429oakm...@gmail.com> wrote:
> Hi,
> I am stuck at a simple problem of printing a multi part string message
> in C++. Nothing seems to work the way I wrote. I see the correct length o
Yes I agree, I've not had a single deadlock in a classic sense since using
message queues. But this statement is like saying I've hand not a car
accident since I've been riding a bike. You can still lock up your code but
it will not be a classic deadlock. I guess you could incorrectly code
somethi
s)? That is what I would prefer to
> do- however I dont know if its possible.
>
> Yours sincerely,
> Arvind,
> Creatrix IT Soft.
>
> *From:* A. Mark
> *Sent:* Friday, April 5, 2013 12:19 AM
> *To:* ZeroMQ development list
> *Subject:* Re: [zeromq-dev] Which language bi
ZMQ's memory utilization while messaging will - among other things - depend
on the zmq socket options and how you implement messaging. It sounds like
you are going to be exchanging small messages and not transferring very
large chunks, you should be able to reduce memory usage of zmq. My first
gues
I think in general you have the most control over your memory allocation
using C.
On Wed, Apr 3, 2013 at 2:11 PM, Arvind Creatrix IT Soft <
arv...@creatrixitsoft.com> wrote:
>
> Hi
>
> I wish to create a simple process that basically measures the CPU/RAM
> utilisated by a running process on that
e me online links.
>
> Thanks
>
> -Asif
>
>
> On Tue, Apr 2, 2013 at 7:35 PM, A. Mark wrote:
>
>> Yes you can certainly use multiple threads besides zmq's own threads.
>> There are many examples of this in the zmq guide.
>>
>>
>> On Tue, Apr
Yes you can certainly use multiple threads besides zmq's own threads. There
are many examples of this in the zmq guide.
On Tue, Apr 2, 2013 at 2:38 AM, A L wrote:
> Hi Eric,
>
> Thanks for replying.
>
> I also want to know if, in addition to using my own thread, I can use
> multiple threads to
I see, so since it's unrestricted it's fine with ROUTER to ROUTER, but with
REQ-ROUTER is not going to work.
On Tue, Mar 26, 2013 at 2:55 PM, Anoop Karollil wrote:
> Pieter Hintjens wrote:
>
>> On Tue, Mar 26, 2013 at 10:09 PM, Anoop Karollil
>> wrote:
>>
>>
>> And
>>> yes, like you said, the s
Hi Anoop!
As I understand ZMQ_ROUTER sockets are like ZMQ_REP socket in that they
must receive a msg first. You cannot send a msg off the ZMQ_ROUTER socket
without it already had received a
msg first. In your example you send to the broker first. Also in your loop
there should be REQ-REP pattern e
I can think of making this easier if the ZMQ identites could be
renegotiated, that way portion of the ID could be reserved for negotiation
and then used as references. Don't know if this fits well with ZMQ's
internals though.
-Mark
On Thu, Mar 14, 2013 at 9:10 AM, A. Mark wrot
Hi Alexandre,
Not certain what you mean by authentication but I have been thinking of
this ZMQ area just recently. What I did and I'm not sure that it is
relevant to your case is to have a ZMQ_ROUTER to ZMQ_ROUTER broker as the
server frontend+backend. I authenticate via the identity first which h
ligent Transport Layer.
>
>
> --
> Jean-François SMIGIELSKI
> +33 (0) 625 135 563
>
>
> 2013/3/8 A. Mark
>
>
>> Hi!
>>
>> In your code the argv[1] "link" must be independently "PUSHED/PULLED" for
>> this example to give reliable
Hi!
In your code the argv[1] "link" must be independently "PUSHED/PULLED" for
this example to give reliable results. Not sure what you do in the
push()/pull() calls but in general your workers and the "collector" are
separate processes. Here you are assuming that the first for loop will not
block
Thanks Pieter, I've missed the contributing page...I will submit a pull
request shortly.
Mark
On Mon, Feb 25, 2013 at 6:15 AM, Pieter Hintjens wrote:
> On Mon, Feb 25, 2013 at 2:39 PM, A. Mark wrote:
>
> > I've done some extensive benchmarks using local_thr and remote a
Would you share the basic hardware and setup of the 10GE you are testing on?
On Mon, Feb 25, 2013 at 5:41 AM, A. Mark wrote:
>
> Meant to write:
>
> should be at least:
>
> throughput = (unsigned long)((double) message_count / (double) elapsed *
> (double)( 1024*1024));
&
Meant to write:
should be at least:
throughput = (unsigned long)((double) message_count / (double) elapsed *
(double)( 1024*1024));
On Mon, Feb 25, 2013 at 5:39 AM, A. Mark wrote:
> Hi,
>
> I've done some extensive benchmarks using local_thr and remote and tcp in
> the last
Hi,
I've done some extensive benchmarks using local_thr and remote and tcp in
the last couple of months and found some odd things. This line is slightly
wrong for the throughput calculation ( apart from the overflow):
throughput = (unsigned long)((double) message_count / (double) elapsed *
10
would be a single broker controlling the ring buffer state to
which clients connect to, request buffers and submit finished buffers. I
think a REQ-DEALER-ROUTER-REP chain should be able to handle this. I will
have to add a controller somehow too.
On Thu, Jan 17, 2013 at 9:39 AM, A. Mark wrote
I mean slower thread
switching), if it also less "wasteful" for unnecessary wake-ups. I'm only
learning ZMQ and no very little about FF.
Interesting article, I wish I could use it...
On Thu, Jan 17, 2013 at 6:04 AM, Steven McCoy wrote:
> On 17 January 2013 01:35, A. Mark wro
Hello,
I'm needing to implement some low level MPMC queues. I've been rolling my
own using pthreads, and so far I've been pulling my hair out in the process
also... My code is strictly C at this point and I'd like to keep it that
way. I've looked into FF (FastFlow) and find it's rather technical f
Thanks Charles,
Not sure how to open an issue...by the way it looks like if I remove the
zmq_msg_close it works OK.
On Fri, Jan 11, 2013 at 9:43 AM, Charles Remes wrote:
>
> On Jan 11, 2013, at 11:32 AM, "A. Mark" wrote:
>
> > The segfault occurs in the first iteratio
Hello,
I'm seeing the following core dump issue with large malloc() buffers
size>1MB when used with zmq_data_init:
Program terminated with signal 11, Segmentation fault.
#0 __memcpy_ssse3_back () at
../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:98
98../sysdeps/x86_64/multiarch/memcpy-sss
me context in all threads and if
> so, maybe you need to increase the threads that the omq uses inside it.
> http://api.zeromq.org/3-2:zmq-ctx-set
>
>
>
> 2013/1/9 A. Mark
>
>> OK, so I went back and I fixed a couple of issues and reattached the two
>> modifi
ing to the results it doesn't happen.
On Mon, Jan 7, 2013 at 7:16 PM, A. Mark wrote:
> Hello,
>
> I'm very interested in porting my current transfer engine to 0MQ. The
> current engine is written in pure BSD sockets and has certain limitations
> that would be easily overcome
Hello,
I'm very interested in porting my current transfer engine to 0MQ. The
current engine is written in pure BSD sockets and has certain limitations
that would be easily overcome by QMQ's intelligent and versatile design.
However my main concern is performance on very long messages in access of
;
> On Friday, 4 January 2013 at 19:37, A. Mark wrote:
>
> > Hello, this was result of a "make check" on this system:
> >
> > Linux machine 2.6.18-308.16.1.el5 #1 SMP Tue Oct 2 22:01:43 EDT 2012
> x86_64 x86_64 x86_64 GNU/Linux
> >
> > CentOS release
Hello, this was result of a "make check" on this system:
Linux machine 2.6.18-308.16.1.el5 #1 SMP Tue Oct 2 22:01:43 EDT 2012 x86_64
x86_64 x86_64 GNU/Linux
CentOS release 5.8 (Final)
0MQ v3.2.2
$ ./configure --prefix=/home/alian/Desktop/Temp/local
checking for a BSD-compatible install... /usr/
41 matches
Mail list logo
