Thursday October 6, 2011

[Time] NameMessage
[06:53] pieter_hintjens mikko: cancer sucks
[06:59] guido_g true
[06:59] guido_g g' morning all
[07:01] guido_g pieter_hintjens: back in europe?
[11:14] CIA-79 libzmq: 03Martin Sustrik 07master * rd31792e 10/ (3 files in 2 dirs): Default HWMs are set to 1000 ...
[13:36] cjhowe does zeromq need to be running on the client AND the server or can the client interact with say an xmlrpc server?
[13:40] mikko cjhowe: zeromq sockets communicate with zeromq sockets
[13:40] mikko or compatible implementation
[13:58] cjhowe mikko, thanks
[15:25] Steve-o any update on the lmax changes?
[15:32] sustrik Steve-o: francois is going to answer shortly
[15:33] Steve-o most of the disruptor code is framework around the ring buffer
[15:39] Steve-o odd the choice of padding with 64-bit ints instead of 8-bit ints.
[16:23] calvin i'm seeing some issues with pub/sub socket reconnects
[16:24] calvin (in 3.0)
[16:24] calvin i'm interested if this has anything to do with the addition of xpub / xsub
[16:26] cremes what's the issue?
[16:27] cremes or do we have to guess? :)
[16:28] calvin sorry was away for a second
[16:28] calvin i'm basically using a pattern with a server and a client that both have pub/sub sockets
[16:28] calvin if i take down the server and leave the client up
[16:29] calvin it seems like when the server comes back up it can receive messages successfully from the client
[16:29] calvin but the client can no longer receive messages on its sub socket from the server's pub socket
[16:29] calvin so it seems like restarting a sub works, but restarting a pub does not
[16:29] calvin which makes me wonder if it's because the server is not receiving the subscribe msg the client sends
[16:30] cremes so, two processes publish to each other and subscribe to each other, yes?
[16:30] calvin yes
[16:30] cremes but you say one process starts receiving messages again while the other doesn't
[16:30] cremes even though they both have the same config?
[16:31] cremes if true, this could be an issue of which process binds a socket and which one connects to it
[16:31] cremes if you can reproduce reliably then try swapping which process does the bind/connect and see if
[16:31] cremes the problem moves
[16:43] calvin sorry i had to step away for s ec
[16:43] calvin alright i'll try that out
[16:53] grantr cremes, you around?
[16:54] grantr question about stability/maturity of zmqmachine
[16:54] grantr ie is it stable/mature :)
[17:10] cremes grantr_: yes and yes, though with a caveat
[17:10] cremes i am working on a new ffi-rzmq release (which zmqmachine depends on) and i have made *major*
[17:10] cremes changes to its api
[17:10] cremes it's well tested but it is a bit of an upheaval
[17:11] cremes so you know, i use zmqmachine (and ffi-rzmq) in production daily for dozens of projects
[17:11] cremes and it is stable and mostly mature
[17:11] grantr good to know
[17:11] cremes ping me if you have questions
[17:11] grantr i'm looking at starting a zmq project and i'd like to NOT depend on eventmachine
[17:11] grantr ok thanks
[17:11] grantr cremes, whem do you expect the new release?
[17:12] grantr should i wait until that happens?
[17:12] cremes new release should be within the next 10 days; it's 90% of the way there, so i
[17:12] cremes just need to make sure docs & examples are up-to-date, etc
[17:12] grantr ok
[17:13] grantr i noticed there are some FIXME and 'this is ugly' lines in zmqmachine, are those on the roadmap to be fixed? how bad are they really?
[17:13] cremes long term i'd like to replace my use of zmqmachine with a more actor-based approach like celluloid
[17:13] grantr i like celluloid
[17:13] cremes those FIXMEs are all fixed mostly due to changes in ffi-rzmq where the ugliness originated
[17:13] grantr got it
[17:16] grantr cremes, good to know about your interest in celluloid. It seems very promising especially combined with zmq
[17:18] cremes grantr_: yes; ultimately i would like to put zmq underneath celluloid so it can communicate
[17:18] cremes with actors over the network
[17:18] cremes at that point it becomes useful to me :)
[17:25] grantr cremes, i think that makes it something useful versus a toy project
[17:26] cremes i'm just sorry that i mimicked the eventmachine api for zmqmachine; that api sucks
[17:27] grantr i think evented programming would be way more popular in rubyland if something else with a cleaner api had come along first
[17:27] cremes yeah... the gem has a nicer api
[17:27] cremes but ultimately this all needs to be hidden away
[17:27] cremes programmers shouldn't have to worry about sockets are anything
[17:28] cremes for 90% of the cases
[17:28] grantr have you done anything with go? i like the way it handles channels
[17:28] cremes no, no time to explore other languages lately
[17:28] grantr time is always the limiting factor
[17:29] cremes agreed
[17:29] cremes the last few days i've been learning the limelight gui framework for jruby
[17:29] cremes because now i need to deliver a little gui for one of my zmq projects
[17:29] grantr first i've heard of it
[17:29] cremes so an end-user can handle it without touching the cli
[17:29] cremes checkout
[17:30] cremes it's been around for a few years but never got any real traction
[17:30] cremes it's very similar to shoes in terms of concepts
[17:30] grantr i like the idea of shoes, but i've never heard of anyone using ruby for a gui app
[17:31] grantr maybe i just dont run in those circles
[17:31] cremes probably... shoes is a great choice
[17:31] cremes but i couldn't get it working on windows with mri 1.9.2 so i switched to limelight
[17:32] cremes i prefer jruby on windows anyway
[17:33] cremes i think the main reason ruby isn't a popular language for guis is because it's hard to obfuscate
[17:33] cremes the code when you ship it; folks don't always want to give away their code
[17:33] cremes i don't care about that :)
[17:33] grantr makes sense
[17:34] cremes anyway, feel free to use zmqmachine and shoot me questions if you get stuck
[17:34] grantr will do
[17:34] grantr thanks cremes
[17:34] cremes np
[18:09] pieterh guido_g: yeah, for a short while
[18:09] pieterh was in Germany today, am now back in Belgium
[18:10] guido_g ah i see
[18:16] pieterh how's stuff?
[18:16] guido_g good so far
[18:16] pieterh I noticed that while in the USA, 90% of people use Macbooks, here in Europe it's 90% Thinkpads
[18:17] guido_g this will chaneg now... in the usa
[18:17] guido_g *change
[18:19] pieterh Thinkpads will come back into fashion?
[18:19] guido_g the other way round
[18:19] guido_g macs will drop out of fashion soon
[18:20] guido_g remember how it went last time w/ apple w/o jobs
[18:20] pieterh hmm
[18:20] guido_g and this time they can't get him back
[18:21] guido_g it was a one person cult thingy and now it'll back-fire
[18:21] pieterh a large part of it is fashion, for sure
[18:22] guido_g see the reaction on the latest phone
[18:22] pieterh yeah
[18:22] pieterh ok /me has to do some zeromq-dev emails... brb
[18:23] guido_g cu
[19:06] mikko good evening
[19:34] Steve-o I'm thinking the performance with Disruptor is a bit bogus, no numbers for non-blocking operations, it's not overly scalable beyond # cores
[21:47] adymitruk any thoughts or concerns about using zeroMQ from an ASP.NET MVC app?
[21:48] adymitruk I was thinking of starting a socket for each app domain that is spun up
[21:48] adymitruk then having a dictionary of corrolation ids and each request would wait until a response came back
[21:48] adymitruk thoughts? or is everyone asleep? :)
[23:42] bar4ka hey guys could you help me with this zeromq error: Socket operation on non-socket
[23:43] bar4ka code at
[23:43] minrk1 most commonly for trying to do something after a socket has been closed
[23:43] bar4ka i am trying to implement some type of connection pool
[23:44] minrk1 at least in my experience, ENOTSOCK generally means socket has been closed.
[23:44] bar4ka after debugging i got the error after the thread creating at line 36
[23:45] bar4ka i am using inproc
[23:45] bar4ka to load balance
[23:45] bar4ka and a tcp socket for msg output
[23:46] bar4ka the idea is to have a number of connections opened ready for delivery
[23:47] minrk1 Why do you have more than one context?
[23:48] bar4ka i just thought that i need one context for inproc and another for tcp
[23:48] minrk1 no, you can use the same one for everyting
[23:48] bar4ka i will try that
[23:48] minrk1 typically, you just have one context in a given process
[23:49] minrk1 probably not relevant to your error, but a general principal
[23:49] minrk1 What call is raising the error?
[23:52] bar4ka i just tried with same context
[23:52] bar4ka same error
[23:53] minrk1 not surprising
[23:53] bar4ka the error is raised on line 36: threads.create_thread(boost::bind(&Sink::run, *worker));
[23:53] minrk1 what call actually sees the error?
[23:53] minrk1 you can't identify the zmq call?
[23:54] bar4ka the strange think i put a trace stop on run method and it doesnt get there
[23:56] bar4ka the zmq call is either in the run method or at line 48
[23:57] bar4ka but i couldnt see it going there, there is break points