"They send billions of messages a day through 0mq."...
http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-12-tweets-p.html
and they're running alpha build in production o_O
Dhammika
___
zeromq-dev mailing list
z
Hi Chuck,
On Wed, Nov 16, 2011 at 7:11 AM, Chuck Remes wrote:
> On Nov 16, 2011, at 1:19 AM, Martin Sustrik wrote:
>
>> Hi Chuck,
>>
>>> The UUID would uniquely identify each client.
>>
>> Give some thought to what do you want to uniquely identify. Is it any client
>> ever? If so, UUID is proba
You can also try chrome native client API
https://code.google.com/chrome/nativeclient/docs/technical_overview.html
They recently released the SDK, so may not be very stable on all platforms.
Dhammika
On Tue, Sep 20, 2011 at 9:42 PM, Noospheer Team wrote:
>> No there's not. However, there's a
On Fri, Jun 24, 2011 at 1:33 AM, Martin Sustrik wrote:
> On 06/24/2011 10:29 AM, Dhammika Pathirana wrote:
>
>> This is similar to pf_ring on linux, but more usable from user space.
>> http://info.iet.unipi.it/~luigi/netmap
>>
>> Apparently they are baking a lin
Hi Martin,
On Wed, Jun 22, 2011 at 2:12 PM, Martin Sustrik wrote:
> On 06/22/2011 11:07 PM, Steven McCoy wrote:
>> Following on from within a VM, here is native Windows results.
>
> Pretty bad.
>
> Nobody ever done much optimisation on Win platform :|
>
> Btw, I recall there's the poll function i
Hi,
This is similar to pf_ring on linux, but more usable from user space.
http://info.iet.unipi.it/~luigi/netmap
Apparently they are baking a linux port, should be interesting...
Dhammika
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://
Hi Sean,
> 2.) Could a system which utilizes zeromq as its core messaging component
> also utilize a distributed non-relational data store like Apache Cassandra
> to persist the information coming across the wire and so make the system
> more durable? And, if we did, would this totally bork the
Hi Seb,
Apparently backtype is using zmq in their stream processing,
http://tech.backtype.com/preview-of-storm-the-hadoop-of-realtime-proce
Would be great if we can get some info on their experience.
Dhammika
On Sat, May 28, 2011 at 12:51 PM, Sebastien Pahl wrote:
> I just created the page:
On Fri, May 20, 2011 at 4:40 PM, Pieter Hintjens wrote:
> On Fri, May 20, 2011 at 8:10 PM, Jon Gifford wrote:
>
>> plenty of places nearby: 83 Proof, Louies, Kate O'Briens, The Irish Bank,
>> Harringtons, Tadich, Salt House, Rickhouse, ...
>
> I've tentatively put up 7pm on June 1st on the wiki.
Hi Pieter,
On Wed, Apr 20, 2011 at 7:05 AM, Pieter Hintjens wrote:
> On Wed, Apr 20, 2011 at 12:51 PM, Pieter Hintjens wrote:
>
>> I've just pushed a new stable release of 0MQ, v2.1.5. This is a small
>> update mostly focussed on packaging issues. There are no bug fixes in
>> this release, so if
Hi PJ,
On Sun, Mar 6, 2011 at 10:34 PM, PJ Durai wrote:
> Greetings,
>
> I am having some issues in building my application in Suse 11.3 instalation.
>
> Zero MQ library itself has no problems building.
>
> But when I build my application, I end up with the following error
>
> /home/pi/dev/lib/li
On Fri, Feb 25, 2011 at 10:54 AM, Martin Sustrik wrote:
> On 02/25/2011 07:50 PM, Martin Sustrik wrote:
>
>> Thougts anyone?
>
> As for the schedule, I would propose Tuesday, March 8th, after the
> working hours. If there's an interest in technical session we could
> schedule that say from 6pm to
On Tue, Feb 15, 2011 at 11:39 PM, Martin Sustrik wrote:
> On 02/16/2011 07:01 AM, Dhammika Pathirana wrote:
>
>> We have to either block on send() or return EAGAIN, but these are not
>> trivial changes :-(
>
> There's no easy solution. Blocking leads to deadlocks.
On Wed, Feb 16, 2011 at 12:44 AM, Pieter Hintjens wrote:
> On Wed, Feb 16, 2011 at 7:32 AM, Dhammika Pathirana
> wrote:
>
>>> 1. Stop using topic branches for new development, use the master for this
>> But we need a more robust testing framework.
>
> (a) if new
Hi Pieter,
>
> Proposals:
>
> 1. Stop using topic branches for new development, use the master for this
But we need a more robust testing framework.
> 2. Rename the maintenance branch to match the actual version it covers (2.0.x)
> 3. Start a new maintenance branch for 2.1.x so that patches can
Hi Andrew,
On Mon, Feb 14, 2011 at 6:29 PM, Andrew Cholakian wrote:
> It looks like what's happening is the following sequence inside of ZeroMQ
> 1. zmq tries to recvfrom FD 22, on FD in an internal zmq socketpair, and
> gets some data.
> 2. Periodic attempts after that (always in groups of 3 rec
On Tue, Feb 15, 2011 at 6:30 PM, Chuck Remes wrote:
>
> On Feb 15, 2011, at 7:54 PM, Chuck Remes wrote:
>
>>
>> On Feb 15, 2011, at 7:41 PM, Dhammika Pathirana wrote:
>>
>>>> Assertion failed: new_sndbuf > old_sndbuf (mailbox.cpp:183)
>>>>
Hi Chuck,
On Tue, Feb 15, 2011 at 4:52 PM, Chuck Remes wrote:
>
> On Feb 15, 2011, at 6:00 PM, Chuck Remes wrote:
>
>> Due to some ongoing issues with 0mq on OSX, I switched over to using my
>> linux box as the main dev and test server.
>>
>> I am running a very recent master from the last day o
On Mon, Jan 31, 2011 at 1:33 AM, Pavel Gushcha wrote:
>> > I'm not very involved into zmq2 internals, but as i understood, socket
>> > buffer must have bigger size, that message_t class. And message_t has
>> > relatively small size than my net.core.wmem_default = 126976. May be
>> > zmq::mailbox_t
Hi Pavel,
On Sun, Jan 30, 2011 at 6:35 AM, Pavel Gushcha wrote:
> Hi, All!
>
> It seems, that I have the same problem as Zoufal Andreas:
> http://lists.zeromq.org/pipermail/zeromq-dev/2011-January/008914.html
> From some timepoint 2 applications from my system start to crash
> regularly with asse
Hi Douglas,
On Thu, Jan 20, 2011 at 7:23 AM, Douglas Creager wrote:
> I like the tcmalloc suggestion, it sounds like an easier way around the
> problem. That wouldn't require any changes at all to zeromq, right? I'd
> only do the -ltcmalloc when linking the final application, and not with any
Hi Martin,
On Wed, Jan 19, 2011 at 6:22 AM, Martin Sustrik wrote:
> Dhammika,
>
>> + // Check if we had an error in previous attempt.
>> + if (unlikely (!(static_cast (this)->next)))
>> + return (size_t) -1;
>> +
>
> I think this won't work. The next step of
Patch to handle nmap version probes.
Signed-off-by: Dhammika Pathirana
---
src/decoder.hpp|4
src/zmq_engine.cpp |2 +-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/decoder.hpp b/src/decoder.hpp
index 9da6f72..80987a8 100644
--- a/src/decoder.hpp
+++ b
Hi Thijs,
On Tue, Jan 18, 2011 at 1:41 AM, Thijs Terlouw wrote:
>> From: Dhammika Pathirana
>> Subject: Re: [zeromq-dev] nmap patch for github issues 147+149
>>
>> Do you have a coredump?
>> Could you post a backtrace, run "thread apply all bt" in gdb.
&g
Hi Thijs,
On Mon, Jan 17, 2011 at 4:51 AM, Thijs Terlouw wrote:
>> From: Pieter Hintjens
>> This is really great, thanks! Could you [...] resubmit the patch as a
>> signed-off patch following those instructions?
>
> in the first attempt i didn't use the correct style guidelines, so I
> updated t
Hi Martin,
On Tue, Jan 4, 2011 at 1:53 AM, Martin Sustrik wrote:
> Hi Dhammika,
>
>> It's actually in zmq.
>> Terminated pipe writer gets a "activate" command. But load balancer
>> doesn't decrement active pipe count in terminate() call.
>>
>> 55 void zmq::lb_t::terminate ()
>> 56 {
>> 57
Hi Martin,
On Sun, Jan 2, 2011 at 11:56 PM, Martin Sustrik wrote:
> On 01/02/2011 06:35 AM, Dhammika Pathirana wrote:
>
>> There's a off by one indexing error in load balancer.
>
> This in in the test program, not 0MQ itself, right?
>
It's actually in zmq
gt; to further debug this?
>
There's a off by one indexing error in load balancer.
Shutdown code is bit gnarly. I've attached a patch below, but haven't tested it.
Subject: [PATCH] Fix pipe writer termination
Signed-off-by: Dhammika Pathirana
---
src/pipe.cpp |5 +++--
1
On Sat, Dec 18, 2010 at 12:30 AM, Martin Sustrik wrote:
> Dhammika,
>
1) Using one zmq context, I bind four separate zmq sockets (in java) to
the same ipc port; e.g. "ipc://tmp/test"
>>>
>>> Hm, you should be able to bind at most one socket to a particular
>>> endpoint. Are you sure all
Martin,
On Fri, Dec 17, 2010 at 3:31 AM, Martin Sustrik wrote:
> Hi,
>
>> 1) Using one zmq context, I bind four separate zmq sockets (in java) to
>> the same ipc port; e.g. "ipc://tmp/test"
>
> Hm, you should be able to bind at most one socket to a particular
> endpoint. Are you sure all the four
Praveen,
On Tue, Dec 14, 2010 at 1:06 PM, Praveen Baratam
wrote:
> Dhammika,
> Any progress with this issue?
I was trying to recreate this, but no luck :-(
https://gist.github.com/743150/2e72d18c7f2c1274a21c7fd06f1aafc47ec9764e
Are you using language bindings?
Dhammika
Hi Praveen,
On Tue, Dec 14, 2010 at 1:06 PM, Praveen Baratam
wrote:
> Dhammika,
> Any progress with this issue?
Sorry for the delay, I'll take a look.
XREQ/XREP are widely used, we haven't had any other issues reported on
socket shutdown.
On duplicate identities, I don't think we'll support it.
>From b6571910583e4d9dad094d6ec9fe5d430fe7db4c Mon Sep 17 00:00:00 2001
From: Dhammika Pathirana
Date: Sun, 12 Dec 2010 22:56:28 -0800
Subject: [PATCH 2/2] add basic uri validations
Signed-off-by: Dhammika Pathirana
---
src/socket_base.cpp |
>From 8dd8d580beb9fd84aec99aeb08ead34e3206a080 Mon Sep 17 00:00:00 2001
From: Dhammika Pathirana
Date: Sun, 12 Dec 2010 22:55:55 -0800
Subject: [PATCH 1/2] fix overwriting errno on bind failure
Signed-off-by: Dhammika Pathirana
---
src/tcp_listener.cpp |7 +--
src/tcp_listener.
Hi Martin,
On Sun, Dec 12, 2010 at 3:08 AM, Martin Sustrik wrote:
> Hi Dhammika,
>
> I've checked this patch. See my comments inlines.
>
> Sorry for the delay :( I still have your shutdown patch in the review queue.
> I've checked it once and it seemed to be OK, but the shutdown code is so
> comp
Hi Mahadevan,
On Wed, Dec 8, 2010 at 2:14 AM, Mahadevan R wrote:
> Hi guys,
> I'm getting a strange segfault with the following stack:
> #0 0x7f623e64edd0 in _int_malloc () from /lib/libc.so.6
> #1 0x7f623e650ad8 in malloc () from /lib/libc.so.6
> #2 0x7f623c375d4f in zmq::create_p
9 ::unlink (addr_);
220
>From 79b05df46e454106fa63fbda435e8ca396a09063 Mon Sep 17 00:00:00 2001
From: Dhammika Pathirana
Date: Thu, 9 Dec 2010 22:35:40 -0800
Subject: [PATCH] fix unix domain socket addrlen
Signed-off-by: Dhammika Pathirana
---
src/ip.cpp |2 +-
s
Hi Martin,
On Mon, Dec 6, 2010 at 4:38 AM, Martin Sustrik wrote:
> Hi Dhammika,
>
Patch attached.
>>>
>>> I've checked the patch. Shouldn't the 'dispatch' be called when the
>>> engine
>>> is actually being moved to another thread (inside finalise_initialisation
>>> function) rather than in
On Fri, Dec 3, 2010 at 2:02 AM, Martin Sustrik wrote:
> Hi Dhammika,
>
>> Patch attached.
>
> I've checked the patch. Shouldn't the 'dispatch' be called when the engine
> is actually being moved to another thread (inside finalise_initialisation
> function) rather than in 'read' function?
>
New p
Hi Martin,
On Tue, Nov 23, 2010 at 5:49 AM, Martin Sustrik wrote:
> Dhammika,
>
>> I donno, may be we should simplify this.
>> Why don't we add a refcount?
>
> As a quick workaround -- yes. Do you have a patch for that kind of solution?
>
> However, thinking about it conceptually, the problem is
On Thu, Dec 2, 2010 at 1:22 AM, Praveen Baratam
wrote:
> Dear Dhammika and Chuck,
> I am trying to use an XREP socket as a PUB socket with publisher side
> filtering. In our case we dont need multiple subscriptions from a single
> sub-socket, so we are trying to use XREQ sockets as sinks and XREP
Hi Praveen,
On Wed, Dec 1, 2010 at 2:19 PM, Praveen Baratam
wrote:
> Dear Chuck,
> Thanks for the quick reply.
> Well if ever an Identity is reused, I guess the earlier socket connected
> with that identity will be orphaned and all the messages will be routed to
> the new socket with that ID. Eff
On Tue, Nov 23, 2010 at 5:49 AM, Martin Sustrik wrote:
> Dhammika,
>
>> I donno, may be we should simplify this.
>> Why don't we add a refcount?
>
> As a quick workaround -- yes. Do you have a patch for that kind of solution?
>
> However, thinking about it conceptually, the problem is more generic
http://www.igvita.com/2010/11/17/routing-with-ruby-zeromq-device
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Hi Martin,
On Mon, Nov 22, 2010 at 6:42 AM, Martin Sustrik wrote:
> Dhammika,
>
>> 1. When finalise function finds out that the initiation is over, it
>> sends command to itself, saying "unplug the engine and send it to
>> another thread".
>>
>> 2. The rest of the out_event executes.
>>
>> 3. The
On Sun, Nov 21, 2010 at 7:32 AM, Martin Sustrik wrote:
> On 11/21/2010 03:56 PM, Dhammika Pathirana wrote:
>
>> if (!plugged) is dereferencing this->plugged, but we've deleted this
>> object (engine).
>> So it's going to access deleted memory.
>
> Rig
On Fri, Nov 19, 2010 at 9:21 AM, Martin Sustrik wrote:
> On 11/19/2010 05:48 PM, Dhammika Pathirana wrote:
>
>> -1 for auto buffer resizing.
>> This is bound to go gaga anytime, and possibly has a remote trigger.
>>
>> Different option is to send cmd_t struct poi
Hi Martin,
On Sun, Nov 21, 2010 at 3:04 AM, Martin Sustrik wrote:
> Dhammika,
>
>> engine:out_event() is triggering finalise_initialization(), there we
>> pass it to the
>> other thread and receiving thread deletes engine.
>> But in out_event() first thread again dereferences same engine object
>
On Fri, Nov 19, 2010 at 8:53 AM, Martin Sustrik wrote:
> On 11/19/2010 05:33 PM, Dhammika Pathirana wrote:
>
>> I think it's unplugged and passed to another thread, and second thread
>> is deleting it.
>> We do have two instances where we delete engines in process_at
On Tue, Nov 16, 2010 at 5:43 AM, Martin Lucina wrote:
> sust...@250bpm.com said:
>> On 11/12/2010 11:34 AM, Christian Gudrian wrote:
>> > Hello, again!
>> >
>> > test_shutdown_stress proves stressing under Windows, too:
>> >
>> > The send call at mailbox.cpp:76 might return SOCKET_ERROR with
>> >
On Fri, Nov 19, 2010 at 4:28 AM, Martin Sustrik wrote:
> On 11/19/2010 01:08 PM, Martin Sustrik wrote:
>>
>> Hi Dhammika,
>>
>> I am trying to make sense from this, but I still don't see how it can
>> happen. Can you possibly run the same test with printing "unplugged" in
>> zmq_engine_t::unplug a
Hi Олег,
On Wed, Nov 17, 2010 at 2:35 AM, Олег Севостьянов wrote:
>> Maybe is not a bug, but I have got strange error while debuging with MSVC
>> 2005.
>>
>> I have test client application (http://pastebin.com/emer9049) and test
>> server application (http://pastebin.com/YTW732Xb). I run both un
Hi Martin,
On Sat, Nov 13, 2010 at 5:47 PM, Dhammika Pathirana wrote:
> Hi Martin,
>
> On Sat, Nov 13, 2010 at 2:18 AM, Martin Sustrik wrote:
>> On 11/13/2010 11:13 AM, Dhammika Pathirana wrote:
>>
>>> In finalize_initialization(), we detach the engine and
Hi Martin,
On Sat, Nov 13, 2010 at 2:18 AM, Martin Sustrik wrote:
> On 11/13/2010 11:13 AM, Dhammika Pathirana wrote:
>
>> In finalize_initialization(), we detach the engine and pass it over to
>> app thread.
>
> Actually, it's passed to another I/O thread rather
On Fri, Nov 12, 2010 at 11:10 PM, Martin Sustrik wrote:
> Hi Dhammika,
>>
>> 0 zmq::signaler_t::send()
>> 1 zmq::ctx_t::send_command()
>> 2 zmq::object_t::send_command()
>> 3 zmq::object_t::send_term_req()
>> 4 zmq::own_t::terminate()
>> 5 zmq::zmq_init_t::finalise_initialisation() !-- s
On Tue, Nov 9, 2010 at 4:26 PM, Chris Yourch wrote:
> Back in December 2009 there was some discussion of adding UDT as a
> transport. Has anyone actually started this?
>
>
UDT is in a different domain, is there lot of interest in udp
transports ie. udt, utp etc.
New udp extensions recvmmsg, udpl
On Mon, Nov 8, 2010 at 3:01 AM, Martin Lucina wrote:
> dhamm...@gmail.com said:
>> On Wed, Nov 3, 2010 at 1:12 PM, Christian Gudrian
>> wrote:
>> >
>> > Am 03.11.2010 um 16:04 schrieb Dhammika Pathirana:
>> >
>> >> ok, can you post ma
Hi,
On Mon, Nov 8, 2010 at 4:39 AM, Martin Lucina wrote:
> Chuck,
>
> can you try the preliminary patch below against master and let me know if
> it fixes your problem?
>
> Martin, please review. The code is getting decidedly ugly, so much for
> trying to emulate atomic message queueing over a S
On Mon, Nov 8, 2010 at 12:13 AM, Martin Sustrik wrote:
> Hi Dhammika,
>>
>> zmq_init_t::finalise_initialization() sends attach command to the session.
>> But session::process_attach() can delete this engine, while it's still
>> in use in io_thread out_event() callback.
>>
>>
>
> Can you elaborate
On Wed, Nov 3, 2010 at 1:12 PM, Christian Gudrian wrote:
>
> Am 03.11.2010 um 16:04 schrieb Dhammika Pathirana:
>
>> ok, can you post mac crash log?
>
> Attached is a crash log for the "Invalid argument error". Thanks for having a
> look.
>
> Christian
&
Hi Min,
On Tue, Nov 2, 2010 at 2:40 PM, MinRK wrote:
>
>
> On Tue, Nov 2, 2010 at 13:57, Burak Arslan
> wrote:
>>
>> On 11/02/10 21:27, MinRK wrote:
>> > Is there a better model for hiding message data using an unmodified
>> > current release version of zeromq, which means that zmq_send and
>>
On Wed, Nov 3, 2010 at 12:49 AM, Christian Gudrian
wrote:
> Am 03.11.2010 07:05, schrieb Dhammika Pathirana:
>
>> size=-2 doesn't look right,
>
> Actually it's 444 -- I've used %d instead of %u.
>
> > could you post a test to recreate this
>
> Un
Hi Christian,
On Mon, Nov 1, 2010 at 1:37 PM, Christian Gudrian wrote:
>
> Am 01.11.2010 um 21:30 schrieb Christian Gudrian:
>
> Backtrace in case the assertion fails:
>
> Sorry. I posted the backtrace of the main thread. This is the one of the
> thread with the failed assertion:
> #4 0x0001
Hi Pieter,
On Thu, Oct 28, 2010 at 9:18 AM, Pieter Hintjens wrote:
> On Sat, Oct 23, 2010 at 7:18 PM, Martin Sustrik wrote:
>
>> So let's do the zeromq.com->zeromq.org and zeromq.org->zeromq.org/community
>> transition today and solve the remaining problems in step-by-step fashion.
>
> OK, so th
Hi Andrew,
On Tue, Oct 26, 2010 at 7:06 AM, Andrew Hume wrote:
> i am getting sporadic core dumps with my zmq programs.
> no pattern detectable yet, except that whenever it happens,
> the immediate cause is a zero zmq_msg_t. e.g.
> (gdb) bt
> #0 zmq_msg_close(._0 *) (msg_=0x7fff1e481d10) at zmq
Hi Martin,
On Tue, Oct 26, 2010 at 7:04 AM, Martin Sustrik wrote:
> Dhammika,
>
>> Patches for issue #30
>
> Applied.
>
>
You missed this,
>From 2f1de7f95aeae3b40fc1c851f052c7c0c0b9dee7 Mon Sep 17 00:00:00 2001
From: dhammika
Date: Mon, 25 Oct 2010 23:12:56 -0700
Subject: [PATCH 2/2] fix typo
Hi,
Patches for issue #30
>From f77b8e1ed020786c36216c819fb38d78d5a57d46 Mon Sep 17 00:00:00 2001
From: dhammika
Date: Mon, 25 Oct 2010 22:19:43 -0700
Subject: [PATCH] drop connection requests with duplicate peer identity
Signed-off-by: dhammika
---
src/session.cpp |9 +++--
src/zm
Patch to handle decoding errors.
>From 0a179e4c16e390e091629ab83f08b813ae5ad4ed Mon Sep 17 00:00:00 2001
From: dhammika
Date: Wed, 20 Oct 2010 19:27:00 -0700
Subject: [PATCH] handle decoding malformed messages
Signed-off-by: dhammika
---
src/decoder.cpp| 26 --
s
Hi Mato,
>
> +int zmq::zmq_connecter_t::get_reconnect_period ()
> +{
> +#if defined ZMQ_HAVE_WINDOWS
> + return (reconnect_period + (((int)GetCurrentProcessId () * 13)
> + % reconnect_period));
> +#else
> + return (reconnect_period + (((int)getpid () * 13) % reconnect_period));
> +#en
Hi,
On Mon, Sep 27, 2010 at 5:14 AM, Martin Sustrik wrote:
> Dhammika,
>
> Good work!
>
> Can you submit this patch under MIT/X11 so that I can apply it?
>
Patch attached, submitting under MIT/X11 license.
Dhammika
From 46f0018eee7e5cb792faed4ab9157fe03a7c7316 Mon Sep 17 00:00:00 2001
From: d
Hi Thijs,
On Mon, Sep 20, 2010 at 9:08 PM, Thijs Terlouw wrote:
> From: Dhammika Pathirana
>
>> Calling pipe->read(msg) on a drained pipe returns a bad msg.
>> Following patch is against master, and is released under mit/x11 license.
>
> thanks! I have also applied th
Hi Jon,
On Mon, Sep 20, 2010 at 11:27 AM, Jon Dyte wrote:
> Dhammika Pathirana wrote:
>>
>>
>> Calling pipe->read(msg) on a drained pipe returns a bad msg.
>> Following patch is against master, and is released under mit/x11 license.
>>
>>
>
> T
On Thu, Sep 16, 2010 at 2:54 AM, Ilja Golshtein wrote:
> Hello!
>
> I've logged issue http://github.com/zeromq/zeromq2/issues/issue/79
>
> Basically server application crashes if number of incoming TCP (under zmq
> control) connections are terminated. Looks like it does not matter what
> server
Hi,
diff --git a/src/ctx.cpp b/src/ctx.cpp
index 2660e1f..267f7d0 100644
--- a/src/ctx.cpp
+++ b/src/ctx.cpp
@@ -64,7 +64,8 @@ zmq::ctx_t::ctx_t (uint32_t io_threads_) :
}
// In the unused part of the slot array, create a list of empty slots.
-for (uint32_t i = slot_count - 1; i >=
ber of threads were started.
>
>
I'm running your sample code with g++ 4.4.
But I don't see a crash or a corruption :-(
>
>
> The initial issue http://github.com/zeromq/zeromq2/issues#issue/64
> is very important for me and I do appreciate any assistance.
>
> Thank
Hi Ilja,
Works ok with master branch, but there's a bug in initializing
zmq::context_t with 0 io threads.
I've attached following patch,
diff --git a/src/ctx.cpp b/src/ctx.cpp
index 65c5316..ec8a045 100644
--- a/src/ctx.cpp
+++ b/src/ctx.cpp
@@ -64,7 +64,7 @@ zmq::ctx_t::ctx_t (uint32_t io_thread
> -Pieter
>
> On Fri, Aug 27, 2010 at 10:22 AM, Dhammika Pathirana
> wrote:
>> Hi,
>>
>> On receiving a new message, decoder inits a msg with size (*tmpbuf - 1).
>> But a sender can craft a message such that *tmpbuf is 0 (ie.
>> zmq::message_t msg((
Hi,
On receiving a new message, decoder inits a msg with size (*tmpbuf - 1).
But a sender can craft a message such that *tmpbuf is 0 (ie.
zmq::message_t msg((size_t)-1)).
This creates a remote memory corruption in the receiver.
Patch is a temporary fix, we need a better way to handle malformed me
Hi,
> -ssize_t nbytes = send (w, &cmd_, sizeof (command_t), 0);
> +ssize_t nbytes;
> +do {
> +::send (w, &cmd_, sizeof (command_t), 0);
> +} while (nbytes == -1 && errno == EINTR);
small typo, nbytes uninitialized.
___
zero
Hi,
Number of TCP receiver improvements in latest kernel,
http://lwn.net/Articles/362339
http://lwn.net/Articles/382428
Concept is similar to Receive Side Scaling in high-end NICs, but this
is done in software without any driver modifications. Impressive
benchmarks.
Dhammika
__
Hi,
http://nova.openstack.org
http://nova.openstack.org/architecture.html#components
It's using AMQP for backend messaging, time to get zmq in the cloud.
Dhammika
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/
Hi,
Anyone following linux PF_RING developments?
It's a new packet capturing API for Gbit wire speeds, a very different
approach from current PF_PACKET based filtering.
http://www.ntop.org/PF_RING.html
http://luca.ntop.org/Ring.pdf
http://luca.ntop.org/Blooms.pdf
Dhammika
__
On 7/22/10, Serge Aleynikov wrote:
> My work was based on foking Dhammika's initial implementation. I made
> many enhancements, added documentation, autotools-based config,
> cross-compilation for MacOS, but the two repos were not merged, so my
> repository can be thought of a successor, and i
>
> I know about this and have reported the issue to the bug tracker.
>
> There is a problem at least on Linux when the host only has a loopback
> address configured, getaddrinfo() will not resolve anything. AFAICT this is
> due to the AI_ADDRCONFIG flag being used when resolving names/addresses
On 7/7/10, Martin Lucina wrote:
>
> On 7/7/2010, "Dhammika Pathirana" wrote:
>
> >But how is this different from network or remote host queuing/dropping
> >messages?
> >Sending queued messages doesn't really guarantee delivery of messages.
>
>
> I don't have the code handy right now, look for the call to
> pthread_sigmask(). The signal mask is cleared for all 0MQ I/O threads,
> so they will not get any signals (excepting SIGSEGV, etc.)
>
> Hence the SIGPIPE issue should be moot, unless on some broken OS a
> SIGPIPE correctly ignore
But how is this different from network or remote host queuing/dropping
messages?
Sending queued messages doesn't really guarantee delivery of messages.
This gets even worse as TCP sends RST (ECONNRESET) on receiving data
to a closed socket. In http world they work around this by sender
doing a hal
On 7/6/10, Martin Lucina wrote:
> dhamm...@gmail.com said:
> > Patch to handle SIGPIPE in send().
> > SIGPIPE behavior is not consistent even across *ix platforms. Linux
> > has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
> > SIG_IGN, but it's more of an application setti
phone.
>
>
> On Jul 6, 2010 8:01 AM, "Dhammika Pathirana" wrote:
>
> Patch to handle SIGPIPE in send().
> SIGPIPE behavior is not consistent even across *ix platforms. Linux
> has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
> SIG_IGN
Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent even across *ix platforms. Linux
has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
SIG_IGN, but it's more of an application setting. We should document
this.
diff --git a/src/tcp_connecter.cpp b/src/tcp_connec
Hi Pieter,
Can we add a link to rfc.zeromq.org? Even ~search~ can't find it.
On 5/28/10, Pieter Hintjens wrote:
> Hi folks,
>
> Here's a draft of a new homepage for the site, aiming to make better
> use of the space:
> http://www.zeromq.org/sandbox:start
>
> Feedback welcome, especially ab
Hi Serge,
Awesome, let's publish this in the web page.
On 5/25/10, Serge Aleynikov wrote:
> Here's the latest version of Erlang 0MQ bindings which is a fork of
> Dhammika's work.
>
> http://github.com/saleyn/erlzmq
>
> "make docs" generates documentation in HTML format, which is mostly taken
Hi Martin,
Linux and few other packet filters use LC-trie for address lookup,
http://www.csc.kth.se/~snilsson/public/papers/router2/text.pdf
http://www.csc.kth.se/~snilsson/public/papers/trash/trash.pdf
On 5/18/10, Martin Sustrik wrote:
> Hi Bhavin,
>
> I'm reading through the documents...
>
Hi Pieter,
Thanks for posting this in the wiki, but it's not quite ready yet.
Is it ok to discuss erlang related stuff (not necessarily on zmq) on this list?
Dhammika
On 5/15/10, Pieter Hintjens wrote:
> Jon,
>
> Thanks for that, I'd forgotten Dhammika's email. I've added a page
> for his
anges in a branch, so that you can merge them (though I won't
> likely be able to work on this for another couple of weeks).
>
> Serge
>
>
> On 5/12/2010 4:32 AM, Dhammika Pathirana wrote:
>
> > Hi Serge,
> >
> > I'm working on an erlang driver, i
Hi Serge,
I'm working on an erlang driver, if you're interested check it out.
http://github.com/dhammika/erlzmq
This is experimental/half-baked code, but most of the basic
functionality is there.
Dhammika
On 5/11/10, Serge Aleynikov wrote:
> Hi,
>
> The current design of zmq_poll(3) call a
On 4/15/10, Martin Lucina wrote:
> All,
>
> with the introduction of more send/recv flags (ZMQ_SNDMORE), socket options
> (ZMQ_RCVMORE) and the experimental device api (ZMQ_STREAMER et al) the ZMQ_
> namespace for constants is starting to look rather ad-hoc and crowded.
>
> There are two main
How do we use this in other frameworks?
ie. Glib::MainLoop(), QT::QEventDispatcher
On 4/14/10, Martin Sustrik wrote:
> Ok,
>
> Here's a first sketch:
>
> // Account for both 0MQ sockets and file descriptors.
> union zmq_poll_item_t
> {
> void *socket;
> int fd;
> };
>
> // Cons
Hi Martin,
But it's too confusing, why don't we do this in zmq_poll()?
zmq::socket_t* sock1;
items[ 0 ].socket = (void *)(*sock1); /* correct */
items[ 0 ].socket = (void *)sock1; /* error */
On 3/29/10, Martin Sustrik wrote:
> Dhammika,
>
>
> > Think we're casting zmq::sock
Hi,
Think we're casting zmq::socket_t to zmq::socket_base_t in zmq_poll().
Patch attached.
On 3/25/10, Martin Sustrik wrote:
> Nelson, Brian,
>
> You've both reported an error where polling in I/O thread crashed.
>
> Thanks for the backtraces. I've spent some time staring at the code but
>
1 - 100 of 104 matches
Mail list logo