#rabbitmq IRC Log


IRC Log for 2011-06-28

Timestamps are in GMT/BST.

[0:09] <antares_> slyphon: hey
[0:11] <antares_> slyphon: well, something is wrong with your connection parameters. Either hostname or port. Authentication issues trigger a different errback.
[1:05] <slyphon> antares_: er, ok, i can try, but all of my other tests pass
[1:06] <slyphon> it's just "the big one" that fails, the main integration test we wrote
[1:06] <slyphon> and it fails in a completely odd way, we establish the connections, we they're up and running, the channels are open, the queues are declared, etc. etc.
[1:07] <slyphon> but i send the first ping (the reactor is *not* blocked) and it just dies
[1:07] <slyphon> i get on_tcp_connection_failure after about 1.5 seconds
[1:24] <antares_> slyphon: are you using master?
[1:24] <slyphon> uhm
[1:24] <slyphon> amqp ?
[1:24] <slyphon> i'm using the prerelease versions
[1:24] <antares_> slyphon: this logic is in amq-client, actually
[1:24] <antares_> ok
[1:25] <slyphon> i'm really baffled by this
[1:25] <slyphon> and the bitch is, it's in my most complicated test, so it's not like i have an easy test-case for you
[1:25] <antares_> I thought that you can try raising something in EventMachineClient#undind
[1:25] <antares_> to see what causes connection to close
[1:25] <antares_> also, wireshark is very helpful
[1:25] <slyphon> yeah, i have a wireshark dump
[1:26] <slyphon> there's an ack from the client, then a 1.8s pause, then a FIN, ACK
[1:26] <antares_> interesting
[1:26] <antares_> EM 0.12.10?
[1:26] * slyphon looks
[1:26] <slyphon> hrm
[1:26] <antares_> what if you try 1.0.beta3? (simply install it, amq-client will use whatever is available)
[1:26] <slyphon> mmkay
[1:27] <antares_> with bundler you can just add gem "eventmachine", "~> 1.0.beta3"
[1:27] <slyphon> yup
[1:27] <antares_> slyphon: have you seen automatic recovery mode news?
[1:27] <slyphon> nope
[1:28] <slyphon> i just wrote this dual-client-managment thing
[1:28] <slyphon> handles 2 connections to 2 different cluster nodes
[1:28] <slyphon> one goes down, fails over to the secondary
[1:28] <antares_> http://groups.google.com/group/ruby-amqp/t/d7b4e784ccf2f2da
[1:28] <antares_> hm, ok
[1:29] <antares_> and how do you reconnect?
[1:29] <antares_> do you open a completely new connection with AMQP.connect?
[1:29] <slyphon> yep
[1:29] <antares_> or do you use AMQP::Session#reconnect?
[1:29] <slyphon> tear down all of my stuff and set it back up
[1:29] <slyphon> AMQP.connect
[1:29] <slyphon> i have to get permission still to open source it
[1:30] <antares_> ok. That means you drag no old EventMachine state with you :/
[1:30] <slyphon> well, that was the idea :)
[1:30] <antares_> slyphon: check out what is going on in master (in the group thread), it is related to recovery
[1:30] * slyphon laughs "Hammock Driven development"
[1:31] <slyphon> gah...
[1:31] <slyphon> one sec
[1:31] <slyphon> antares_: you gonna be around for a little bit?
[1:32] <slyphon> our DVR went bonkers earlier
[1:32] <antares_> slyphon: yes
[1:45] <slyphon> antares_: oh, the other fun thing is that sometimes it just works
[1:56] <antares_> slyphon: hm, so race conditions…
[1:56] <slyphon> antares_: yep
[1:56] <slyphon> i have a success caputre and a fail capture
[1:56] <antares_> slyphon: can you post a sample wireshark dump of a run?
[1:56] <antares_> great
[1:57] <slyphon> sure
[1:58] <slyphon> antares_: should i email it to you or BASE64 encode it and put it in a gist, or...
[1:58] <slyphon> actually
[1:58] <slyphon> i can just attach it to a gist
[1:58] <antares_> slyphon: you can email it to me
[1:58] <slyphon> oh
[1:58] <slyphon> mm'kay
[1:59] <slyphon> antares_: uhm, i don't think i have your email
[2:07] <slyphon> antares_: odd, it looks like when it fails, there are 3 AMQP frames packed into a single packet
[2:07] <antares_> slyphon: there is a known issue with empty messages. It may be related. There is some edge case our framing code does not cover.
[2:08] * slyphon nods
[2:08] <antares_> try using an empty message in the Hello, world example
[2:09] <antares_> I hm, 3 frames into a single packet…
[2:09] <slyphon> hm, thing is the message isn't empty, it's 4 bytes
[2:10] <slyphon> antares_: ok, sent
[2:10] <slyphon> antares_: i'll try the example, though
[2:10] <slyphon> just to see if i'm a lucky winner
[2:14] <slyphon> antares_: is eventmachine 1.0.0.beta3 generally considered stablish?
[2:15] <slyphon> antares_: Handling a connection-level exception: UNEXPECTED_FRAME - expected method frame, got non method frame instead
[2:15] <antares_> yes
[2:15] <slyphon> antares_: ok, i'm totally game for using that
[2:16] <antares_> looking at the failure dump doesn't raise any immediate ideas in my head
[2:16] <slyphon> i relly can't figure out why it would FIN, ACK after 1.8 seconds
[2:16] <slyphon> it's *always* that amount of time, too
[2:16] <slyphon> hrm
[2:16] * slyphon goes looking for 2.0 magic numbers
[2:16] <antares_> slyphon: do you get UNEXPECTED_FRAME with your test or the Hello, world example w/ empty messages?
[2:17] <slyphon> yes
[2:17] <slyphon> antares_: what do i win?!
[2:17] <antares_> from what I see it is 1.5 seconds, but anyway
[2:17] <slyphon> oh
[2:18] <slyphon> oh, yeah, that
[2:18] * slyphon is a litle bleary from the day
[2:18] <slyphon> hrm
[2:18] <antares_> and is there anything in the rabbit log?
[2:19] <slyphon> exception on TCP connection <0.15945.0> from
[2:19] <slyphon> connection_closed_abruptly
[2:19] <slyphon> actually, lemme check something
[2:22] <slyphon> hrm
[2:22] * slyphon adds a raise in unbind
[2:24] <slyphon> antares_: ok, so if i put 'raise "OMGWTFBBQ!!"' as the first line of unbind in AMQ::Client::Async::EventMachineClient nothing happens, i just get a timeout in my sepc
[2:24] <slyphon> spec*
[2:24] <slyphon> i was kind of expecting an awesome traceback
[2:26] <antares_> unbind is delayed until after channel is open
[2:27] <antares_> actually, it should be even after queue is declared
[2:28] <slyphon> well, this stack isn't terribly illuminating
[2:29] <antares_> sorry, what stack?
[2:29] <slyphon> basically printing out caller when unbind is called
[2:29] <slyphon> https://gist.github.com/bfc17221080cc83ec309
[2:30] <slyphon> is there debug logging possible w/ eventmachine?
[2:30] <slyphon> i mean, in the reactor
[2:30] <slyphon> or are they too 31337 for that
[2:30] <antares_> probably not
[2:30] * slyphon nods
[2:30] <antares_> well, the reactor is in C++
[2:31] <slyphon> yeah, and god knows logging would slow that down *terribly*
[2:31] <antares_> what I do typically is I add tracing to #send_frame
[2:31] <slyphon> ah
[2:31] <slyphon> yeah, i tried that before, lemme try again
[2:32] <antares_> frame.decode_payload will even turn it into a Ruby object that is readable
[2:32] <slyphon> antares_: oh, nice
[2:33] <slyphon> undefined method `decode' for AMQ::Protocol::Connection::StartOk:Class
[2:33] <slyphon> er
[2:33] * slyphon tries duck-typing that
[2:34] <antares_> hm, there are probably AMQP methods that decoding isn't implemented for
[2:34] <antares_> in amq/protocol/client.rb that we use
[2:34] <antares_> because they are only sent by the client
[2:34] <slyphon> oh, hrm
[2:34] <slyphon> so is that a bad thing to put in send_frame?
[2:34] <antares_> clients never receive them => no need for decoding
[2:35] <slyphon> what's odd is
[2:35] <slyphon> oh fun
[2:35] <antares_> if you simply put "puts frame.inspect" there, you will be able to see something
[2:35] <slyphon> they still respond_to deocde_payload
[2:35] <slyphon> decode_payload rather
[2:35] <slyphon> ok
[2:36] <slyphon> odd, i thought i set the logger for AMQ::Client
[2:37] <slyphon> i'm getting the STDERR one, hrm
[2:38] <antares_> I am sure logger is something that isn't used anywhere
[2:38] <antares_> mostly because for previous versions logging meant "printing to stdout"
[2:38] <slyphon> it's used in the heartbeater frames :)
[2:39] <slyphon> antares_: yeah, being able to inject a useful logger would be useful
[2:39] <slyphon> antares_: btw
[2:39] <antares_> and I was going to find a sane way to plug external loggers in a way that won't require if/else all over the code
[2:39] <slyphon> antares_: you might like the "Logging" project
[2:39] <slyphon> it's kind of like log4r done by somone who isn't a total idiot
[2:39] <antares_> got a link?
[2:39] <slyphon> sure
[2:40] <slyphon> i really like it, i haven't integrated it yet, but i'm probably going to
[2:40] <slyphon> i was really impressed
[2:41] <slyphon> https://github.com/TwP/logging
[2:41] <slyphon> it seems like it'd be tailor made for a library
[2:42] <slyphon> i use MyTLModule.logger = Logger.new('/dev/null').tap { |l| l.level = Logger::FATAL } in all my libraries
[2:42] <slyphon> but it's a pain in the nuts
[2:42] <slyphon> when i actaully need the output
[2:43] <antares_> if you show a typical "Rails developer" something designed after Log4J they will run away screaming
[2:43] <slyphon> antares_: yeah, so don't
[2:43] <antares_> well, my goal is to let apps use any logger developers want
[2:43] * slyphon nods
[2:44] <antares_> I am sure logging is something we will figure out quickly after we are done with this framing issue + automatic recovery
[2:44] * slyphon nods
[2:45] <slyphon> i usually have something like AMQP.logger= and then a module i mix in everywhere that establishes a class-level and instance level def logger; AMQP.logger; end
[2:45] <slyphon> hrm
[2:45] <slyphon> i feel like htere's a timer going off
[2:45] <antares_> for what?
[2:46] <slyphon> just that it's *always* the same delay
[2:46] <antares_> slyphon: are you testing with evented-spec?
[2:46] <slyphon> yeah
[2:46] <slyphon> lemme up the dealy
[2:46] <antares_> did you set default timeout?
[2:46] <slyphon> timeout
[2:46] <slyphon> yeah
[2:46] <slyphon> 3.0
[2:46] <slyphon> i think
[2:47] <antares_> yes, that's a lot of time
[2:47] <antares_> basically
[2:47] <slyphon> oh, heh, it's 2.0
[2:47] <antares_> evented-spec forcefully shuts down EM reactor
[2:47] <antares_> after each example
[2:47] <antares_> are you on OS X?
[2:47] <slyphon> yessir
[2:48] <antares_> 1.5 seconds may be just TCP timeout OS X uses by default, I am not sure
[2:48] * slyphon nods
[2:48] <slyphon> jeez, this is odd
[2:48] <antares_> but when I test automatic recovery (and crush broker with kill -9), I see that recovery always takes about 4.5 seconds
[2:48] <antares_> I use reconnect(false, 2) and it takes about 3 attempts
[2:49] <slyphon> :/
[2:49] <antares_> my point is that the time period is very stable
[2:49] * slyphon nods
[2:49] <slyphon> i wonder if i should set EM.kqueue = true
[2:49] <antares_> try setting default timeout to 10 seconds and forget about it
[2:49] <slyphon> yeah
[2:49] <antares_> the thing is, nearly every decent spec uses #done explicitly anyway
[2:49] <slyphon> yeah, mine does
[2:49] <antares_> so default timeout is to make sure you tests do not hang forever
[2:50] <slyphon> can i set it to 0 ?
[2:50] <antares_> I am not sure, probably not
[2:50] <slyphon> or rather, use timeout(0) at the top of my tests?
[2:50] <slyphon> bleh
[2:50] * slyphon just sets it really long
[2:50] <antares_> it would make possible for a bogus test to completely hang up the whole process
[2:51] * slyphon nods
[2:51] <slyphon> i find it's useful when i'm refactoring and that causes some kind of quirk
[2:51] <slyphon> wow
[2:51] <slyphon> it seems like it just takes the broker a long time in some cases to return my ping
[2:51] <slyphon> or rather, deliver my message
[2:52] <antares_> so if time period after which connection is terminated is always 1.5 seconds, I think evented-spec shuts things down too early
[2:52] <antares_> slyphon: yes, sometimes I see little slowdowns on localhost, too
[2:52] <antares_> especia
[2:52] <antares_> oops
[2:52] <antares_> TLS example takes 4-5 seconds to connect ;)
[2:52] <slyphon> sheesh
[2:52] <slyphon> yeah, weird
[2:52] <slyphon> looks like it takes 5.82 seconds for this job to complete
[2:52] <slyphon> er
[2:53] <slyphon> spec
[2:53] <antares_> I understand that asymmetric cryptography is slowish but not that slow :)
[2:53] <slyphon> for no real reason
[2:53] <slyphon> hahaha
[2:53] <slyphon> nah, this is no crypto
[2:53] <antares_> right
[2:53] <slyphon> security just makes things hard on everyone
[2:53] <antares_> well, I cannot tell you why it takes 6 seconds
[2:53] <antares_> but at least we found the issue
[2:53] <slyphon> yeah, well, thank you for your patience :D
[2:53] <antares_> I'd choose a test that runs 6 seconds over a test that fails with obscure connection termination any day of the week :)
[2:54] <slyphon> amen to that
[2:54] <slyphon> the weird thing is, like i said before, the reactor isn't blocked
[2:54] <slyphon> i put in a ticker just to make sure
[2:54] <slyphon> and was *really* impressed at how fast it can spit out log lines
[2:55] <antares_> slyphon: do you have management plugin installed?
[2:55] <slyphon> i'm not sure
[2:55] <antares_> check for # of queues, exchanges & bindings you have
[2:55] <antares_> maybe your test suite keeps accumulating them
[2:55] <slyphon> hrm
[2:55] <antares_> lots of bindings may slow things down considerably
[2:55] <antares_> because rabbitmq does a seq scan over bindings list
[2:56] <slyphon> nothing outrageous for any of those
[2:57] <slyphon> hah
[2:57] <antares_> hm
[2:58] <slyphon> antares_: setting EM.kqueue = true seems to make the tests run *much* faster
[2:58] <slyphon> like 0.8s pretty reliably
[2:59] <slyphon> antares_: it seems like em has been stuck at beta3 for a *while*
[2:59] <antares_> so someone invited our old friend select(2) to the party, huh
[2:59] * slyphon laughs
[3:00] <antares_> slyphon: we want to release EM 1.0 fairly soon, but amount of testing it takes is considerable
[3:00] <slyphon> antares_: look, if it was good enough for Theo, Linus, RMS, and ESR, it's good enough for you
[3:00] <antares_> and I don't have a second machine to run Windows tests on right now
[3:00] <slyphon> oh god
[3:01] <slyphon> "windows"
[3:01] <slyphon> i thought they deprecated that
[3:01] <antares_> EM supports Windows (not super-performant but amqp gem works, for example) and JRuby
[3:01] * slyphon nods
[3:01] <antares_> no, in fact, the opposite
[3:01] <antares_> Windows is getting some attention
[3:02] <slyphon> if you give it the attention it craves, you'll just encourage it
[3:02] <slyphon> you need to roll up a newspaper and WHACK it on the nose
[3:02] <antares_> if I had a separate machine to run Windows on, I may even dive into IO completion ports or whatever they have
[3:02] <antares_> but I simply cannot keep more VMs around
[3:02] <slyphon> heh
[3:02] <slyphon> yeah, i hear ya
[3:02] <slyphon> the VM sprawl gets overwhelming
[3:04] <antares_> in my case I simply don't have enough disk space :P
[3:04] <antares_> and have been a lazy ass to pick a slow HDD to offload some crap off my SSD
[3:04] <slyphon> antares_: i made the mistake of cutting an eventmachine binary gem versioned at 0.12.12 for internal use, and have regretted it since
[3:04] <slyphon> oooh
[3:05] <slyphon> "SSD"
[3:05] <antares_> but I think EM deserves some love and I want to improve Windows support. I just want people who are stuck with Windows to have access to at least amqp gem
[3:05] * slyphon nods
[3:05] <antares_> also, node-fucking-js is getting Windows support
[3:06] <slyphon> hahaha
[3:06] <slyphon> node-js is cool, but people are retarded
[3:06] <slyphon> reminds me of rails fanbois
[3:06] <antares_> so eventmachine has to keep up
[3:06] <slyphon> the designer-pants crowd
[3:07] <slyphon> developers who show up to an interview in cowboy boots and Calvin Klein eyewear
[3:07] <antares_> I don't know, I like JavaScript and I understand that not everyone should be good with concurrency, but solving EVERY single problem with event loop is just idiocy
[3:07] * slyphon laughs
[3:07] <antares_> node.js author clearly didn't plan to use node for everything
[3:07] <slyphon> yeah, *he's* not an idiot
[3:07] <slyphon> but it's like twisted
[3:08] <antares_> but now that Joyent marketing department claims it is THE platform of the future for all kinds of apps…
[3:08] <antares_> he probably has no choice
[3:08] <slyphon> you just get totally focused on using it for everything
[3:08] <slyphon> antares_: i still don't really understand what possible advantage there could be in making mkdir asynchronous
[3:08] <antares_> no, I mean, in the JVM community you don't see people using Netty for everything
[3:09] <antares_> even if Netty is totally great
[3:09] * slyphon coughs
[3:09] <antares_> with node.js, you have no choice at all
[3:09] <slyphon> the company i work for has about 250 java devs
[3:09] <antares_> need to spawn a thread in node.js? do it with a C++ extension :P
[3:09] <slyphon> i think about 245 of them couldn't find their asshole with a flashlight and a map
[3:09] <slyphon> ugh
[3:12] <slyphon> antares_: http://chaosinmotion.com/blog/?p=622 this is the company i work for *to a T*
[3:13] <slyphon> Java guys reinventing DNS using properties files
[3:13] <slyphon> you know, shit like that
[3:17] <antares_> slyphon: I personally think Java community needs to drop some bullshit but in general, they got a lot of stuff right
[3:18] <antares_> I have been using Ruby for 5+ years and sometimes I just cry for some stuff I take for granted with JDK
[3:18] <slyphon> antares_: the smart ones get shit right, but there are a *LOT* of completely mediocre java developers
[3:18] <slyphon> antares_: oh, totally
[3:18] <antares_> but that's not a Java specific problem
[3:18] <antares_> most of developers mediocre
[3:18] <slyphon> the JVM is probably the best VM out there
[3:18] <slyphon> antares_: yeeeeeeah, but htere are a *lot* of mediocre Java developers
[3:18] <antares_> or not mediocre but just not really trying to understand how things work
[3:18] <slyphon> Java makes it easy to be mediocre
[3:18] <slyphon> yes
[3:19] <slyphon> *that* is is
[3:19] <slyphon> it*
[3:19] <slyphon> not thinking about "the system"
[3:19] <slyphon> or "architecture"
[3:19] <antares_> slyphon: http://pragprog.com/titles/ahptl/pragmatic-thinking-and-learning
[3:19] <slyphon> just becuase it runs in eclipse, *doesn't* mean it's gonna rock in production
[3:19] <antares_> slyphon: that book explains why :)
[3:19] <slyphon> :)
[3:20] <slyphon> yeah
[3:20] <slyphon> i've always said that IDEs make programming too much like a video game
[3:21] <antares_> about 6 years ago I was a die hard Eclipse fan
[3:21] <antares_> then I discovered Emacs
[3:21] <slyphon> hah
[3:21] <antares_> these days I use Emacs for everything that is not Java or Scala, and very happy with both
[3:21] <slyphon> i only use Emacs for hacking lispy languages
[3:21] <antares_> for Java and Scala I use IDEA
[3:21] <slyphon> otherwise i use vim
[3:21] * slyphon anod
[3:22] <slyphon> s
[3:22] <slyphon> IDEA is nice
[3:22] <slyphon> antares_: my buddy uses RubyMine, he's been very happy with it
[3:24] <antares_> slyphon: I know RubyMine developers ;)
[3:24] <slyphon> oh nice
[3:25] <antares_> ok, looks like I fixed one more bug in master
[3:27] <slyphon> nice
[3:29] <antares_> slyphon: I think we have a few issues left to fix before I am really happy with 0.8
[3:29] <antares_> other than docs
[3:29] <slyphon> oh yeah? so far it's been working pretty well for us
[3:30] <antares_> this empty message framing issue, heartbeat handling and possibly failover
[3:30] <slyphon> heh, man
[3:30] <slyphon> i should give you a copy of this code
[3:30] <antares_> if we solve that, then 1.8.7-p249 support and docs is all left to be done
[3:30] <slyphon> i implemented that on top of 0.8.0.pre*
[3:31] <slyphon> both
[3:31] <antares_> you can just explain what you did to me
[3:31] <slyphon> the heartbeat thing isn't as low-level as you guys are doing it
[3:31] <antares_> especially with heartbeats
[3:31] <slyphon> oh heh
[3:31] <antares_> failover is something that can wait for 0.9
[3:31] <antares_> (at least people haven't been asking for it)
[3:31] <slyphon> heartbeats are simply setting up a queue(''), and publishing to it every 2 sec
[3:32] <slyphon> and using a timer
[3:32] <slyphon> if you miss 3 beats, you call on_tcp_connection_failed
[3:33] <antares_> hm, so you did not use AMQP heartbeats?
[3:33] <slyphon> nope
[3:33] <antares_> I was talking about amqp heartbeats
[3:33] <antares_> by the way, probably not tcp_connection_failed but tcp_connection_loss
[3:34] <slyphon> oh, yeah, that
[3:34] <antares_> tcp_connection_failed is for initial failures
[3:34] <slyphon> oh, hrm
[3:34] * slyphon checks
[3:38] <slyphon> oh, i just hook that
[3:38] <slyphon> wrap it in my own thing
[3:39] <antares_> ok
[3:39] <antares_> what about failover?
[3:39] <slyphon> on_heartbeat_failure
[3:39] <slyphon> ahh
[3:39] <antares_> master has one new method for AMQP::Session
[3:39] <antares_> called #reconnect_to
[3:39] <antares_> it is like #reconnect but you can pass in any host and port
[3:40] <slyphon> oh
[3:40] <slyphon> i have 2 live connections that i'm monitoring
[3:41] <antares_> so you have 2 connections
[3:41] <antares_> and you monitor both
[3:41] <antares_> and say the 1st one fails
[3:41] <antares_> what happens next?
[3:41] <slyphon> i'm looking for the state diagram
[3:43] <slyphon> https://s3.amazonaws.com/slyphon/random/connection_manager_state_diagram.png
[3:43] <slyphon> it goes into "failed_over" state
[3:43] <slyphon> fires the on_failure callbacks
[3:44] <antares_> nice
[3:44] <slyphon> and changes it's "active_connection" to be the other one
[3:44] <antares_> well, if we add THAT much stuff into amqp gem, I think I will shoot myself maintaining it :)
[3:44] <slyphon> the clients know that when on_failure fires, they have to drop everything and wait for on_open
[3:44] <antares_> there is already quite a bit of complexity with this pseudo-sync programming style & automatic recovery
[3:44] <slyphon> hahaha
[3:44] <slyphon> eyah
[3:44] <slyphon> i was going to release this as a separate gem
[3:45] <slyphon> i used the state_machine gem
[3:45] <slyphon> which is kind of confusing in-and-of-itself, but in this case it was really useful
[3:45] <slyphon> plus, it outputs those graphs
[3:48] <antares_> I believe I used it in a few places
[3:48] <antares_> cool
[3:48] <antares_> how many people in your company use amqp gem?
[3:48] <slyphon> uhm
[3:48] <slyphon> 2-3?
[3:48] <slyphon> we're "the ruby guys"
[3:48] <slyphon> off in a corner
[3:49] <slyphon> actually
[3:49] <slyphon> the rest of the company is in SF, we're in NY
[3:49] <slyphon> (we were acquired)
[3:49] <antares_> ah
[3:49] <antares_> I have the opposite situation
[3:50] <antares_> most of people I work with use Ruby and JS (very smart people, but without hardcore CS background)
[3:50] <antares_> and some folks use Scala and Java
[3:50] <slyphon> ah
[3:50] <antares_> I use Ruby but have Java background and really love Scala & Clojure
[3:50] <slyphon> nice
[3:50] <slyphon> yeah clojure is fun
[3:50] <slyphon> i wrote a fairly insane little project in clojure
[3:50] <antares_> sometimes it takes a lot of patience to explain a JS person WTF is CyclicBarrier and why they are reinventing it :)
[3:50] <slyphon> hahahha
[3:51] <antares_> but amqp helps a lot
[3:52] <slyphon> i'm happy that the gem finally has reached a level of maturity where i'm comfortable putting it into production
[3:52] <slyphon> also rabbitmq
[3:52] <slyphon> i have this prejudice against erlang
[3:53] <slyphon> yes, i know it's awesome and everything, but it's weird
[3:53] <antares_> my only problem with erlang is lists + tuples as stack traces
[3:53] <slyphon> ugh
[3:54] <slyphon> their variables are *constants*
[3:54] <slyphon> why not just call them "constants" ffs
[3:54] <antares_> they are actually not constants
[3:54] <antares_> they are bindings :P
[3:54] <slyphon> there's no point in calling an immutable name 'variable'
[3:54] <antares_> they can be assigned, but just once
[3:54] <slyphon> yeah, i know :)
[3:54] <antares_> Scala struggles with the same terminology for vals
[3:55] <slyphon> i understand the appeal of Scala if you're coming from java
[3:55] <antares_> in fact, the whole idea of variable is fucked in CS
[3:55] <antares_> in math you cannot say x = x + 2
[3:55] <slyphon> otherwise, it's a little too Haskelly for me
[3:55] <antares_> it just doesn't make any sense
[3:55] <slyphon> yeah, true
[3:55] <antares_> OCamly ;)
[3:55] <slyphon> but thankfully programming != math
[3:56] <antares_> but many terms programming industry uses are from math :(
[3:56] <slyphon> yeah, i try not to let it bother me though :)
[3:56] <slyphon> i got all the way through 3D linear calculus
[3:56] <slyphon> how, i have no idea
[3:57] <antares_> I have a math degree
[3:57] <slyphon> i have tried since then to stay as far away from math as i can without being a total dumbass
[3:57] <slyphon> hahahahaha
[3:57] <antares_> which means I know relatively little about math
[3:57] <antares_> because I had 13 kinds of it
[3:57] * slyphon tips his hat
[3:57] <slyphon> hah!
[3:57] <antares_> and by about 6th or 7th I was so bored I just stopped attending lectures
[3:57] <antares_> (in Russia you can get by with that)
[3:58] <slyphon> "In Soviet Russia..."
[3:58] <slyphon> sorry, had to be done
[3:58] <antares_> yes, graduation attends you :P
[3:58] <slyphon> :D
[3:58] <slyphon> the best one i think i ever came up with was "In Soviet Russia, movie watches you"
[3:59] <antares_> I think "government elects you" is a good one, too
[3:59] <slyphon> :D
[3:59] <slyphon> i like that
[4:02] <antares_> hehe
[4:02] <antares_> 7 clicks on amqp gem documentation links in 1 hour
[4:02] <antares_> all from Portugal
[4:02] <slyphon> woah, nice
[4:03] <antares_> (typically I have 30-40 per day now, across maybe 6-7 links)
[4:03] <antares_> but sometimes you see a little spike from one particular country
[4:03] <slyphon> i'm hoping to give a talk on what we're doing w/ amqp
[4:03] <slyphon> i have to go through the rigamarole to get the code open-sourced
[4:03] <slyphon> but after that i want to present this
[4:03] <antares_> slyphon: at some conference in NYC?
[4:04] <antares_> I have heard NYC tech scene is finally coming out of age?
[4:04] <slyphon> hah
[4:04] <antares_> well, something has got to replace Lehman some day :D
[4:04] <slyphon> :D
[4:04] <slyphon> yeah, it's pretty hot, they've been working on it for years
[4:05] <slyphon> i've been batting away job offers pretty frequently
[4:05] <antares_> slyphon: one more interesting observation from bit.ly
[4:05] <antares_> a couple of months ago nearly every click was on "getting started" and "how to use with web apps" links
[4:05] <antares_> today most of clicks are on "Documentation guides index"
[4:06] <antares_> looks like people are moving from getting started to actually using it
[4:06] <slyphon> hah!
[4:06] <slyphon> interesting
[4:06] <antares_> (maybe that's also why they ask about error handling & recovery features every day now)
[4:06] <slyphon> yeah, they probably had to talk someone into letting them use it :)
[4:07] <slyphon> one thing that i don't understand (and that brought me to amqp) was that the cloudfoundry guys wrote their own queueing mechanism
[4:07] <slyphon> i was like, "Uh, really?"
[4:07] <slyphon> "you couldn't use one of the 50 other mature ones out there?"
[4:08] <antares_> I think vmware products will move to amqp over time
[4:08] * slyphon nods
[4:08] <slyphon> these guys in particular i think wanted to understand the whole stack from top to bottom
[4:08] <slyphon> which i understand
[4:08] <slyphon> but NIH is a disease
[4:08] <antares_> I guess when they started working on cloud foundry they had to pick something
[4:09] <slyphon> my company suffers from it
[4:09] <slyphon> antares_: their broker is totally in-memory
[4:10] <antares_> cowboys from California
[4:10] <slyphon> yup
[4:10] <antares_> who needs all those disks anyway
[4:10] * slyphon laughs
[4:10] <slyphon> no head, no headache
[4:10] <slyphon> no drives, no failures!
[4:11] <antares_> one task queue that I really like is Gearman
[4:11] <slyphon> oh, heh
[4:11] <slyphon> i read that as "German"
[4:11] <antares_> it has a lot of features amqp has, although it is not a messaging solution per se
[4:11] <slyphon> "I'm sure it's *impeccably* implemented"
[4:12] <slyphon> ohhh
[4:12] <slyphon> this kinda looks like gridengine
[4:13] <antares_> gridengine?
[4:13] <slyphon> yeah, sun had this project
[4:13] <slyphon> god only knows what Oracle did with it
[4:13] <antares_> ah
[4:13] <slyphon> but it was like a remote execution framework, but did all sorts of resource tracking
[4:13] <slyphon> it was a cluster management tool
[4:13] <slyphon> sorta
[4:14] <slyphon> not management, if you had a batch job that needed to run across 1000 nodes
[4:15] <antares_> yes, sounds similar to some gearman features
[5:49] <NoTiTo> morning
[5:50] <antares_> NoTiTo: hi
[5:51] <NoTiTo> antares_ hey dude
[5:51] <NoTiTo> antares_: how are you doing?
[5:53] <antares_> NoTiTo: I am fine. Slowly moving amqp gem towards 0.8.0.RC14 with a bunch of new features.
[12:14] <NoTiTo> re
[16:07] <jgartman> I'm having trouble googling the correct thing - Is there any way to have a rabbit instance create bindings to other instances and exchanges and produce a single consolidated queue? I'm trying to get around having consumers that just shuffle messages into a local exchange from which the 'real' consumption happens.
[16:16] <antares_> jgartman: look into exchange-to-exchange bindings and the shovel plugin
[16:16] <jgartman> antares_: thank you
[18:18] <RickardL> Hi, a quick question - if I wanted to send a single message to any single queue bound to a topic for example topic.agent.*. What would the best setup be?
[18:20] <RickardL> Is it possible to set this up at the RabbitMQ-server, or should I leave this to the agents implementation?
[18:21] <RickardL> The use case would be a MAS, where a agent is issued a job, for example processing some data object stored in a database
[18:31] <antares_> RickardL: if you need to send a message to every queue bound to some exchange, use fanout exchanges
[18:31] <antares_> that's what they are for
[18:31] <antares_> mass broadcasts
[18:32] <antares_> RickardL: it is perfectly fine for an app to use both topic & fanout exchanges side by side
[18:36] <RickardL> Ok, but what if I wanted the message to be sent to just one available queue that was bound to it. Should I send out a message, and pick the one who acked first. Is this an acceptable approach?
[18:39] <antares_> RickardL: if you want to send to just one, use direct exchange, or take a look at random exchange: https://github.com/jbrisbin/random-exchange
[18:40] <RickardL> That was exactly what I wanted, really nice!
[18:45] <RickardL> antares_: Thanks again for giving me heads up, Jons repos of plugins for riak is a gold mine
[18:46] <antares_> Agreed
[18:47] <RickardL> Now I don't have to write my own layer in node.js for storing primtive data with AMQP messages
[19:18] <tronpaul_> hey I have a problem with a client never receiving a response from the server when one is sent
[19:18] <tronpaul_> server code http://pastebin.com/tMT3RM6w http://pastebin.com/rfe0X7Dd
[19:18] <tronpaul_> client code http://pastebin.com/dqZNt3b0
[19:19] <tronpaul_> I just changed from using the tutorial rpc code on the server to writing my own subclass of DefaultConsumer
[19:22] <antares_> tronpaul_: I don't see your Java server setting routing key for the response
[19:25] <tronpaul_> isn't that the getReplyTo() ?
[19:26] <antares_> no
[19:26] <antares_> reply_to is a different message attribute
[19:26] <antares_> it needs to be set, too
[19:27] <antares_> but only routing key is used by the default ("") exchange to figure out what queues get the reply
[19:27] <antares_> sorry, "it can be set, too". Not necessarily needs.
[19:30] <tronpaul_> isn't that replyTo statement in the routingkey param for that method?
[19:30] <tronpaul_> basicPublish(String exchange, String routingKey, BasicProperties props, byte[] body)
[19:31] <antares_> ah, right
[19:31] <antares_> I overlooked that routing key is just a string argument
[19:31] <antares_> I do not use Java client directly very often, sorry
[19:32] <tronpaul_> it's alright, I'm just confused as to why the client doesn't receive the response with that code
[19:32] <antares_> I believe I have seen someone having issue with this tutorial before
[19:32] <antares_> there was some small issue in the Python app code
[19:34] <tronpaul_> that was me
[19:34] <tronpaul_> ;D
[19:35] <tronpaul_> the problem I was having was when multiple clients were sending information to the server the response would be empty
[20:07] <mwieher> hi.. i was hoping someone could point me towards a resource for designing a low-latency, transient messaging system
[20:11] <RickardL> http://scholar.google.se/scholar?q=low-latency%2C+transient+messaging+system&hl=sv&btnG=S%C3%B6k
[20:28] <Frye> Hi again. Got the stuff running on rhel4
[20:28] <Frye> but now I have an issue with creating a cluter
[20:28] <Frye> Does the erlang version need to be the same for each cluster node? I have the same version of the rabbitmq-server
[20:29] <Frye> But I get Mnesia could not connect to some nodes. Firewall is not an issue (doublechecked)
[20:38] <antares_> Frye: I am not sure. Ask on the mailing list?
[20:39] <antares_> Frye: I think by now mnesia doesn't change a lot between Erlang releases, but who knows
[20:46] <Frye> Argh, yeah it is in the documentation. But on the _Very_ end.
[20:46] <Frye> All nodes in a cluster must be running the same versions of Erlang and RabbitMQ
[20:47] <Frye> That should be listed as a prerequisite before the actual configuration part.
[20:47] <Frye> now it's under Upgrading cluster which was not yet relevant for me so I missed it
[21:08] <mwieher> i can't seem to get a setup for rabbit that transfers 10k msgs per second... i'm using Pika, setting durable=false for both the queue_declare and setting delivery_mode=1 ... i've tried no_ack=True and also trying basic_ack() and in both cases the queue fills up far quicker than I can draw from it...
[21:11] <mwieher> of course im kind of noobish and still using blocking connections, which might have worse perforamnce than selectconnections, but the system is pretty straightforwad, data to exchange, to queue, to process
[21:25] <antares_> mwieher: flooding publishers are typically faster than consumers (using the same library)
[21:25] <antares_> mwieher: try multiple consumers, like 5 or 8
[21:26] <antares_> (5 or 8 processes to use multiple cores)
[21:35] <mwieher> yes i was using the approx 2.5 or so cores per consumer
[21:36] <mwieher> it definately helps throughput but not enough
[21:38] <antares_> I haven't heard of 10K/s with Pika
[21:39] <antares_> esp. with blocking mode
[21:39] <mwieher> one of them forums was talking as if it was doable
[21:39] <antares_> 5K/s is about as fast as modern Python and Ruby async clients can go
[21:39] <pulsejc> trying to upgrade from 2.3.1 to 2.5.1. ran out of disk space during the upgrade (there were millions of messages in the queue pre-upgrade). after dealing with the disk issues, I am still unable to start rabbitmq. any ideas?
[21:40] <antares_> pulsejc: rabbitmq's database migration probably did not finish because you ran out of space
[21:40] <gsnedders> antares_: I guess if you have multiple processes reading from the queue you can scale across cores
[21:41] <mwieher> right i'm on a 23 core (per cat /proc/cpuinfo) box
[21:41] <antares_> mwieher: you should not trust forum posts. Only hacker news. Only hacker news crows knows The Truth.
[21:41] <mwieher> so i'm spinning up 12-14 consumers
[21:41] <antares_> gsnedders: certainly, but I still think that 10K is probably a bit more than pure Python client can go. That's still not bad at all in my books.
[21:41] <pulsejc> antares_: any way to have it continue form where it left off?
[21:42] <antares_> pulsejc: well, in theory database rabbitmq uses is transactional so DB upgrades should happen in a transaction
[21:42] <gsnedders> antares_: Yeah, I'm just asking for my own use, mainly.
[21:43] <antares_> pulsejc: but I am not knowledgeable about the internals enough. Ask on the mailing list.
[21:43] <pulsejc> antares_: that was my next stop… thanks
[22:21] <slyphon> antares_: hey, i've hit a snag w/ eventmachine 1.0.0.beta3
[22:21] <slyphon> oh, actually, it's 0.12.10 and 1.0.0.beta.3
[22:30] <antares_> slyphon: what is that?
[22:30] <slyphon> antares_: well
[22:30] <slyphon> i'm more asking for your advice here
[22:30] <slyphon> as this is unrelated to amqp
[22:30] <slyphon> terminate called after throwing an instance of 'std::runtime_error'
[22:30] <slyphon> what(): unable to add new descriptor: Bad file descriptor
[22:31] <slyphon> i only get that with epoll = true
[22:31] <slyphon> i just wanted to know kinda what to do (if anything) about htat
[22:31] <slyphon> to try to get some more information about when that's happening
[22:31] <slyphon> because right now, that just exits the process
[22:32] <slyphon> you ever seen that?
[22:32] <antares_> no
[22:32] <slyphon> oh goodie
[22:32] <slyphon> oke!
[22:32] * slyphon polishes up 'grep'
[22:32] <antares_> try asking on the EM mailing list?
[22:32] <slyphon> sure
[22:32] <antares_> to be honest, EM's C++ core is messy but still easy to follow
[22:32] <antares_> especially parts that delegate to epoll/kqueue
[22:32] <slyphon> yeah, i've read some of the popen code
[22:33] <antares_> ask on the EM, eventmachine maintainer often answers "advanced" questions
[22:33] <antares_> *on the EM mailing list
[22:33] <slyphon> ah, cool
[22:37] <slyphon> antares_: do you happen to know if epoll works on pipes?
[22:37] <slyphon> or is it socket-only
[22:38] <slyphon> oh, blah, it does, nvm
[22:39] <antares_> epoll man page mentions pipes in like the 2nd paragraph ;)
[22:39] <slyphon> yeah, i'm just losing focus :)
[22:39] <slyphon> sorry

These logs were automatically created by MyxoRoboto on irc.freenode.net using the Java IRC LogBot.