| [Time] Name | Message |
|
[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 cool.io 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 limelight.8thlight.com
|
|
[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 http://codepad.org/cgAvG6XH http://codepad.org/AP3SQiPI
|
|
[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
|
