00:13:46  * mikealquit (Quit: Leaving.)
00:15:14  * mikealjoined
00:16:17  <mjr_>I wonder if we are backing up behind http client requests.
00:16:20  <mjr_>Speaking of mikeal.
00:16:46  <mjr_>Is there an easy way to see how many client requests are waiting for a socket?
00:20:08  * mikealquit (Client Quit)
00:22:19  * isaacs_changed nick to isaacs
00:22:49  * piscisaureus_quit (Ping timeout: 240 seconds)
00:32:22  * sh1mmerjoined
01:34:48  * brsonquit (Ping timeout: 268 seconds)
01:57:15  * mikealjoined
01:57:47  <mikeal>mjr_: http.globalAgent.sockets, i think
01:58:06  <mjr_>lemme check
01:58:20  <mjr_>I've been rolling back to node 0.4, same app code, and the leak doesn't happen
02:00:34  <mjr_>prod-nr125.voxer.com> Object.keys(require("http").globalAgent.sockets).length
02:00:35  <mjr_>291
02:01:03  <mikeal>umm
02:01:11  <mikeal>that's the number of remote hosts
02:01:14  <mikeal>not the number of pending
02:01:16  <mikeal>hold on
02:01:19  <mjr_>hmm, globalAgent.maxSockets is 5
02:01:39  <mjr_>But we should be making our own agents
02:02:30  <mikeal>if you are sending your own agent then you'll need to check on your own agent
02:02:45  <mikeal>but looks like somewhere you aren't if the default agent has a ton
02:02:45  <mikeal>aslo
02:02:56  <mikeal>https://github.com/joyent/node/blob/master/lib/http.js#L925
02:03:05  <mikeal>globalAgent.requests[host+
02:03:09  <mikeal>":"+port]
02:03:20  <mikeal>.length
02:03:25  <mikeal>for the number of pending for that host
02:05:52  * mikealquit (Quit: Leaving.)
02:48:19  * isaacsquit (Quit: isaacs)
03:08:06  * benviejoined
04:14:29  * paddybyersjoined
04:22:33  * paddybyersquit (Quit: paddybyers)
05:00:30  * isaacsjoined
05:01:37  <ryah>Ad
05:21:55  * bnoordhuisjoined
05:59:09  <CIA-111>libuv: Ben Noordhuis v0.6 * r34e95d1 / src/unix/core.c :
05:59:09  <CIA-111>libuv: unix: make it safe to delete the default loop
05:59:09  <CIA-111>libuv: Fixes a potential free() of non-malloc'ed memory. - http://git.io/a9ZZwA
06:25:47  * mikealjoined
06:30:41  * mikealquit (Client Quit)
06:33:07  * mralephjoined
06:47:04  * mikealjoined
06:47:42  * mikealquit (Client Quit)
07:13:19  * mralephquit (Quit: Leaving.)
07:15:54  * sh1mmerquit (Quit: sh1mmer)
07:16:10  <CIA-111>node: Ben Noordhuis v0.6 * ra0fdd5f / (deps/uv/src/unix/core.c deps/uv/src/unix/error.c): uv: upgrade to 34e95d1 - http://git.io/KFodyg
07:16:11  <CIA-111>node: Ben Noordhuis v0.6 * raeb124f / test/simple/test-fs-long-path.js : test: create test file in temp dir - http://git.io/EpxMYw
07:28:39  * sh1mmerjoined
07:43:00  <CIA-111>node: Ben Noordhuis v0.6 * rfdf180f / src/node.cc : cli: fix output of --help - http://git.io/wdkwvA
07:49:02  * mralephjoined
07:51:47  * sh1mmerquit (Quit: sh1mmer)
07:57:04  * mikealjoined
08:12:21  * mikealquit (Quit: Leaving.)
08:16:14  * mralephquit (Quit: Leaving.)
08:22:10  * einarosjoined
08:25:15  * kuebkjoined
08:33:32  * mikealjoined
08:43:21  * mjr_quit (Quit: mjr_)
08:46:21  * mikealquit (Quit: Leaving.)
08:56:10  * mikealjoined
09:14:12  * piscisaureus_joined
10:56:45  * piscisaureus__joined
11:02:56  <piscisaureus__>bnoordhuis: are you trying to figure out matt's leak issue?
11:07:53  * isaacsquit (Quit: isaacs)
11:17:55  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
11:22:50  * piscisaureus__joined
12:38:40  <indutny>heya, anyone around?
12:43:45  <mmalecki>indutny: define: anyone
13:21:49  <indutny>mmalecki: https://spdy2.indutny.com/
13:22:06  <indutny>actually, I'm still looking for isaacs
13:24:56  <mmalecki>indutny: nice! it uses native zlib?
13:25:15  <indutny>mmalecki: yes
13:25:26  <indutny>mmalecki: it has no dependencies now :)
13:25:33  <indutny>free as bird
13:26:46  <mmalecki>indutny: that's awesome :)! any benchmarks?
13:29:04  <indutny>mmalecki: not really, hard to benchmark
13:29:18  <indutny>mmalecki: I should write fast client first :)
13:31:14  <indutny>mmalecki: I'm going to write websocket chat on SPDY :)
13:31:18  <indutny>as simple as possible
13:33:37  <mmalecki>woot! btw, would it work on nodejitsu?
13:34:50  <mmalecki>hah! my onAny implementation has no performance impact!
13:37:00  <mmalecki>well, actually, my benchmark was a fail
13:45:56  <indutny>mmalecki: :)
13:46:08  <indutny>mmalecki: it won't work on nodejitsu
13:46:16  <indutny>mmalecki: because it's using NPN
13:47:12  <mmalecki>ah, right
13:48:32  <mmalecki>optimizing is hard. I gained 600 ms by replacing forEach with for
13:49:16  <indutny>wow, really?
13:49:19  <indutny>what node version?
13:49:27  <indutny>how many items in array?
13:49:41  <mmalecki>v0.7.0-pre, one item
13:52:14  <mmalecki>with 6 items it's just 400 ms
13:52:53  <piscisaureus__>600ms for iterating over 1 item?
13:53:01  <piscisaureus__>:'(
13:53:09  <einaros>that makes a lot of no sense =O
13:53:26  <mmalecki>I mean, 1024*1024 iterations
13:53:31  <mmalecki>over 1 element
13:53:37  <piscisaureus__>aah
13:53:42  <mmalecki>yeah XD
13:53:45  <einaros>:p
13:54:28  <einaros>does whatever-the-loop-contains have weird side effects?
13:55:28  <mmalecki>that's too much cs for me ;)
13:55:31  <einaros>not that I know what exactly v8 does when optimizing forEaches, but ideally it should inline all the calls
13:55:45  <mmalecki>it just calls a function
13:56:02  <mmalecki>applies to it, actually
13:56:16  <einaros>and the body of the for does the same?
13:56:34  <mmalecki>yeah
13:56:49  <mmalecki>let me gist it
13:57:14  <mmalecki>einaros: https://gist.github.com/1433657
13:57:37  <mmalecki>einaros: line 59
14:06:35  <einaros>sneaky
14:06:53  <einaros>https://gist.github.com/9be3d411baa7e8443254
14:10:51  <mmalecki>yeah
14:10:58  <mmalecki>1768 vs 50 ms
14:11:20  <mmalecki>indutny: you may want to look at ^
14:12:02  <einaros>~10% increase for global iterator, I didn't expect that
14:12:17  <bnoordhuis>piscisaureus_: yes-ish
14:12:37  <mmalecki>btw, why don't we have onAny yet?
14:13:20  <bnoordhuis>the stars aren't right yet
14:13:28  <mmalecki>my implementation needs some work but I think I'll be able to make it fast
14:13:44  <mmalecki>bnoordhuis: uhm, right
14:13:54  <mmalecki>bnoordhuis: you shouldn't drink when coding, ya know?
14:14:05  <bnoordhuis>actually, i'm drinking tea
14:14:09  <bnoordhuis>it's not even spiked
14:14:11  <mmalecki>OH NO
14:14:34  <bnoordhuis>re: onAny - i don't think anyone really (as in *really*) needs that
14:14:35  <mmalecki>100% of people who ever drank tea died later.
14:14:50  <bnoordhuis>same goes for the number of oxygen breathers
14:14:50  <mmalecki>bnoordhuis: I need it, now.
14:15:04  <bnoordhuis>that's why i switched to helium
14:15:08  <mmalecki>bnoordhuis: lol
14:15:15  <bnoordhuis>one of the nice side effects is that i'm the star of every party i go to
14:15:16  <mmalecki>bnoordhuis: I'll describe you my use case
14:15:25  <indutny>mmalecki: lets see
14:15:35  <mmalecki>bnoordhuis: stop lying, programmers don't go to parties
14:15:54  <bnoordhuis>mmalecki: i was a playboy millionaire before i became a programmer
14:16:44  <indutny>mmalecki: ok, bind is using try catch block somewhere inside
14:16:52  <indutny>mmalecki: so it's bailouting
14:16:53  <mmalecki>bnoordhuis: no, you were not
14:17:02  <mmalecki>bnoordhuis: it's this tea.
14:17:08  <bnoordhuis>do i ever lie?
14:17:20  <mmalecki>bnoordhuis: this question is self-recurring.
14:17:29  <indutny>mmalecki: if you'll replace .bind(this) with .apply(self) it will work much faster
14:17:31  <bnoordhuis>awesome, isn't it?
14:17:40  <indutny>mmalecki: I was rockstar
14:18:40  <mmalecki>indutny: you still are. nodejitsu people are rockstars :)
14:18:43  <indutny>isaacs: where are you?
14:18:48  <indutny>mmalecki: hehe :)
14:19:08  <piscisaureus__>mmalecki: re 100%
14:19:12  <bnoordhuis>hrm, i think i broke github
14:19:17  <indutny>bnoordhuis: nope, nt you
14:19:18  <piscisaureus__>bnoordhuis: not true, bnoordhuis is still alive
14:19:20  <indutny>that was me
14:19:54  <mmalecki>indutny: shit, you're right
14:20:08  <mmalecki>indutny: (this apply)
14:20:17  <mmalecki>is bind that price-y?
14:20:54  <indutny>mmalecki: yes
14:21:00  <indutny>mmalecki: node --trace-bailout ftw
14:22:09  <mmalecki>indutny: I haven't known this! thanks
14:25:20  <indutny>mmalecki: --trace-deopt, --trace-opt
14:25:29  <indutny>:)
14:29:30  * piscisaureus___joined
14:31:32  <mmalecki>indutny: useful! looks like my onAny can be optimized :)
14:32:18  * piscisaureus__quit (Ping timeout: 240 seconds)
14:33:28  <indutny>mmalecki: haha :)
14:33:37  <indutny>mmalecki: if code bailouts - it won't be optimized
14:34:00  <indutny>mmalecki: actually, only function that bailouts will be skipped by hydrogen
14:34:13  <mmalecki>indutny: right, I mean optimized by hand, not by compiler
14:38:26  <indutny>ah , socket.io broke my spdy module
14:38:27  <indutny>:(
14:39:54  <mmalecki>what do you mean by "broke"?
14:42:52  <indutny>mmalecki: it doesn't work with spdy
14:43:02  <indutny>whole connection becomes dirty
14:43:15  <indutny>ah, looks like I now
14:43:30  <mmalecki>interesting. chrome has some interesting debugging tool for spdy, btw
14:44:17  <mmalecki>described here: http://www.chromium.org/spdy/spdy-tools-and-debugging
14:48:03  * piscisaureus____joined
14:48:55  * piscisaureus___quit (Ping timeout: 248 seconds)
14:58:07  <indutny>mmalecki: ah, right
14:58:08  <indutny>thanks
14:58:34  <indutny>but I'm already using most of them
15:12:34  * piscisaureus____quit (Read error: Connection reset by peer)
15:12:56  * piscisaureus____joined
15:35:30  <indutny>mmalecki: https://spdy2.indutny.com:8081/
15:35:40  <indutny>it just fails
15:36:08  <indutny>:(
15:37:07  <mmalecki>indutny: can I see the code somewhere?
15:40:47  <indutny>mmalecki: yes, https://github.com/indutny/node-spdy/tree/refactor-0.6.x
15:40:50  <mmalecki>indutny: should it display Time: ?
15:41:05  <indutny>mmalecki: but you'll need to build node with latest openssl to get full support of spdy
15:41:11  <indutny>mmalecki: nope :)
15:41:28  <indutny>mmalecki: it should display Time: <%= +new Date %>
15:42:06  <mmalecki>indutny: it did
15:42:16  <indutny>mmalecki: and should refresh it everysecond
15:42:24  <mmalecki>well, it did once
15:42:56  <mmalecki>I see that it tries xhr-polling first
15:43:20  <indutny>mmalecki: it should use it
15:43:29  <indutny>mmalecki: websockets are using https
15:43:34  <indutny>mmalecki: not spdy
15:43:45  <indutny>so I disabled them
15:43:51  <mmalecki>ok
15:44:30  <mmalecki>indutny: it refreshes it *sometimes*
15:44:54  <indutny>mmalecki: haha :)
15:45:08  <indutny>mmalecki: for me it just fails on second refresh
15:45:19  <indutny>mmalecki: even nicier when running it locally
15:45:37  <indutny>mmalecki: at first refresh image will disapper, at second styles, and then everything
15:47:08  <mmalecki>hah. so it refreshed it every 30 seconds or so
15:47:27  * ericktjoined
15:52:19  <indutny>mmalecki: heh, what web inspectors says for you?
15:52:28  <indutny>mmalecki: does other requests fail or what?
15:52:37  <mmalecki>indutny: I'll gist you the log, ok?
15:54:41  <mmalecki>indutny: this time it didn't work, https://gist.github.com/dce4b5d67ff964aafb48
15:55:49  <mmalecki>indutny: and this time it did https://gist.github.com/16ff0c406d1910756772
15:58:21  <indutny>mmalecki: only thing that I see is that client sends RST_STREAM frames
15:58:28  <indutny>and I don't understand why
15:59:17  <mmalecki>reset stream?
15:59:36  <indutny>mmalecki: yes, looks like I got it... I can't find SYN_REPLY for 31 stream in 16ff0 gist
16:00:01  <mmalecki>:)
16:00:22  <indutny>mmalecki: but that's odd anyway
16:00:23  <indutny>:)
16:00:51  <mmalecki>indutny: it's called programming, I think ;)
16:01:13  <indutny>mmalecki: yeah
16:01:24  <indutny>mmalecki: actually, no, but that often happens
16:02:03  <mmalecki>it'd be boring if it wouldn't happen!
16:03:07  <CIA-111>libuv: Ben Noordhuis v0.6 * r0db3274 / src/unix/stream.c :
16:03:07  <CIA-111>libuv: unix: check UV_CLOSING flag in uv__write()
16:03:07  <CIA-111>libuv: uv__write() runs after the read callbacks have fired. Said callbacks may have
16:03:07  <CIA-111>libuv: closed the handle, handle that graciously. - http://git.io/xIYovQ
16:09:40  <indutny>mmalecki: intersting is that it almost works in firefox nightly
16:10:04  <mmalecki>indutny: have you tried chrome dev?
16:12:16  <indutny>mmalecki: nope, going to
16:12:24  <indutny>mmalecki: do you have canary installed?
16:12:38  <mmalecki>indutny: no, 17.0.942.0 dev
16:13:57  <indutny>mmalecki: does it works on it?
16:14:09  <mmalecki>indutny: kinda-ish
16:14:12  <indutny>mmalecki: btw, those resets has type="Cancel"
16:14:15  <mmalecki>indutny: it updates things sometimes
16:14:30  <indutny>mmalecki: that means that they was canceled by browser w/o errors from server
16:14:41  <indutny>mmalecki: not good
16:17:47  <mmalecki>indutny: what does it mean? malformed response?
16:20:36  <indutny>mmalecki: nope, just canceled reques :)
16:20:42  <indutny>request :)
16:24:40  <mmalecki>indutny: I fucked up? sorry, let me repeat it
16:28:20  * kuebkquit (Quit: Leaving.)
16:28:46  <indutny>mmalecki: np, looks like I found the case
16:28:56  <indutny>mmalecki: I'm able to reproduce it with one hanging connection
16:29:27  * isaacsjoined
16:29:37  * sh1mmerjoined
16:29:52  <mmalecki>indutny: ah, ok
16:31:11  <indutny>mmalecki: thanks a lot
16:31:46  * sh1mmerquit (Client Quit)
16:32:18  <mmalecki>indutny: :)
16:44:11  * ericktquit (Quit: erickt)
16:53:39  * isaacsquit (Quit: isaacs)
17:22:17  <ryah>yo
17:22:48  <piscisaureus____>oy
17:22:55  * piscisaureus____changed nick to piscisaureus
17:23:31  <ryah>how's it going?
17:23:46  <piscisaureus>thanks. how are you?
17:24:18  <ryah>:)
17:27:13  * dapjoined
17:28:11  <indutny>isaacs: where are you ? :(
17:29:47  <mmalecki>isaacs is Scooby Doo ;)
17:40:50  <indutny>yay 100 pull requests for node
17:41:06  <mmalecki>wow! nice!
17:42:20  <mmalecki>indutny: and 91 commits :) http://github-high-scores.heroku.com/joyent/node/high_scores/
17:42:22  <ryah>bnoordhuis: any ideas about mjr's bug?
17:42:49  <piscisaureus>shit bnoordhuis took the second position
17:42:55  <ryah>bnoordhuis: i'm going to pour over the source today and see if anything seems off
17:43:15  * Nohrybjoined
17:43:27  <mmalecki>2 more commits and I'll be better than mikeal, nice
17:44:34  * isaacsjoined
17:51:37  * Nohrybquit (Quit: Nohryb)
17:56:18  <piscisaureus>I had an idea for igor's problem today
17:56:32  <piscisaureus>we just need to leverage readv for sockets
17:58:27  * mikealquit (Quit: Leaving.)
18:05:43  <indutny>isaacs: ohh, yt man!
18:05:44  <indutny>hi!
18:05:50  <isaacs>hi
18:05:59  <indutny>isaacs: zlib zlib zlib! :)
18:07:04  <mmalecki>isaacs: and travis :)
18:11:33  * mikealjoined
18:13:09  * piscisaureus_quit (Ping timeout: 240 seconds)
18:13:26  * sh1mmerjoined
18:17:18  * ericktjoined
18:23:36  <bnoordhuis>ryah: did some tests and some poking, nothing obvious
18:24:05  <bnoordhuis>also, mjr noted that it sometimes takes 20 minutes to show up which is odd
18:25:46  <ryah>bnoordhuis: i wonder if it only happens after seeing a message with long headers
18:28:45  <bnoordhuis>ryah: hmm, maybe - i'll test that
18:29:03  <bnoordhuis>test/simple/test-http-parser.js has a long header test but that doesn't show anything
18:33:44  * mikealquit (Quit: Leaving.)
18:34:51  <ryah>bnoordhuis: can we talk after the scrum call regarding isolates - i want to get some tasks from you to work on
18:35:00  <bnoordhuis>ryah: sure
18:35:08  <ryah>thanks
18:36:18  * brsonjoined
18:48:27  <isaacs>what's the correct incantation to let the event loop die after opening stdin?
18:48:32  <isaacs>stdin.pause() doesn't release it
18:49:00  <mmalecki>isaacs: stdin.destroy()
18:49:04  <mmalecki>isaacs: but that's actually a bug.
18:49:35  <isaacs>mmalecki: that works. but, doesn't that mean it can't ever be opened again?
18:49:57  <mmalecki>isaacs: https://github.com/joyent/node/issues/2257
18:50:08  <isaacs>like, i want to be able to read n things, and when i have no more to read, let the program die naturally
18:50:13  <mmalecki>isaacs: I think it does. that's why it's a bug
18:50:54  <ryah>isaacs: how will you know there is nothing more to read?
18:51:03  <ryah>the user needs to EOF stdin
18:51:09  <ryah>s/user/caller/
18:51:36  <ryah>when stdin is EOFed it will decrement the event loop counter
18:52:00  <isaacs>ryah: well, let's say you have a shell script or something, you need to read username, read password, do some stuff, maybe read email address, or not.
18:52:13  <isaacs>ryah: the way it worked in 0.4, if stdin is paused, it's not blocking the loop
18:52:44  <isaacs>so you could just stdin.resume(), get some data, then stdin.pause() and remove your listeners.
18:52:51  <isaacs>and maybe some other part of the program might need to read more
18:53:06  <isaacs>the issue is that you might have a program with parts that read from stdin one at a time, and don't necessarily know about one another
18:53:21  <mmalecki>that's how all prompt modules do it. this bug breaks them hard.
18:53:25  <bnoordhuis>we should ref stdin when resumed, unref it when paused
18:53:35  <isaacs>bnoordhuis++ ^
18:53:41  <isaacs>that's how it should work.
18:55:39  <isaacs>the issue is that, if you .destroy() it, or get EOF on it, then you can't open it again.
18:57:23  <ryah>i'd be fine with that
18:58:44  <bnoordhuis>call?
18:58:57  <ryah>yep
18:59:00  <igorzi>yep
18:59:26  <isaacs>skype or phone?
18:59:30  <bnoordhuis>skype
18:59:35  <ryah>i'll start it
19:00:32  <ryah>piscisaureus: call?
19:04:54  <bnoordhuis>https://github.com/joyent/node/issues/2254
19:06:56  <piscisaureus>ryah: yeah
19:07:26  <piscisaureus>ryah: add me
19:08:03  <piscisaureus>bnoordhuis: aah
19:08:08  <piscisaureus>I feel left out
19:08:10  <piscisaureus>;-(
19:09:11  * mjr_joined
19:14:49  <ryah>bnoordhuis: how much longer are you online today?
19:15:04  <bnoordhuis>ryah: the next hour or so?
19:15:17  <ryah>bnoordhuis: okay - let's call in like 30 minutes
19:15:20  <bnoordhuis>cool
19:18:34  <CIA-111>node: Ryan Dahl v0.6 * r1a89c8d / doc/template.html : Add analytics tracking to docs - http://git.io/M2GG9w
19:19:50  <bnoordhuis>isaacs: something like that? https://gist.github.com/9b9491838fb2c30b68ea
19:20:38  <isaacs>bnoordhuis: yes.
19:20:48  <bnoordhuis>isaacs: okay, because that test works for me
19:20:55  <bnoordhuis>which is good, i suppose
19:21:02  <isaacs>oh really? weird.
19:21:47  <isaacs>bnoordhuis: yeah, it works for me as well.
19:22:32  <isaacs>bnoordhuis: oh, maybe it was that you can't pass in [0,1,2] to take over the shell
19:26:11  <isaacs>bnoordhuis: "we should ref stdin when resumed, unref it when paused" <-- you're talking about the TTY.unref function? I don't see any corresponding TTY.ref method.
19:26:45  <bnoordhuis>isaacs: yes and yes
19:27:03  <bnoordhuis>(second yes as in "yes, it's not there")
19:29:02  * pieternjoined
19:30:58  <isaacs>bnoordhuis: i see. it looks like uv_ref is being called n HandleWrap::Close
19:31:18  <isaacs>bnoordhuis: so, you're suggesting just add another HandleWrap::Ref that calls that? like the inverse of HandleWrap::Unref?
19:32:49  <bnoordhuis>isaacs: not quite - i think the current approach needs some reworking
19:32:58  <isaacs>i see
19:33:01  <mmalecki>bnoordhuis: re uv tests broken by indutny's patch, test-tty is broken, it timeouts
19:33:23  <bnoordhuis>isaacs: src/node.js, function createWritableStdioStream()
19:33:33  <indutny>mmalecki: bnoordhuis: have we applied my patch?
19:33:58  <mmalecki>indutny: no, I'm trying to justify applying it
19:34:05  <indutny>I thought it was superficial
19:34:14  <indutny>mmalecki: yep, it's not so simple
19:34:16  <bnoordhuis>isaacs: it creates the stream based on what type of fd stdin/stdout is
19:34:30  <bnoordhuis>ttys and pipes are unref'd unconditionally - that should probably change
19:34:31  <mmalecki>indutny: breaks uv's test-tty
19:34:34  <isaacs>bnoordhuis: i see. so we unref it manually, just to keep `process.stdin` access from opening stdin and keeping the process alive.
19:34:55  <isaacs>bnoordhuis: so, it looks like we should unref it on pause, and ref it on resume.
19:34:59  <bnoordhuis>isaacs: yes
19:35:00  <mmalecki>indutny: but I guess it's what isaacs and bnoordhuis are talking about now ;)
19:35:03  <isaacs>i think that's doable pretty easily, then
19:35:09  <isaacs>lemme try it. thanks.
19:35:12  <indutny>isaacs: but seems to be a bug anyway :)
19:35:35  <isaacs>mmalecki: well, more generally, i'm kind of sick of having to have npm call process.exit() manually
19:35:38  <isaacs>even on success
19:35:46  * Nohrybjoined
19:35:50  <indutny>+1
19:36:02  <mmalecki>isaacs: I know. that's what we do in our cli tool, but I hate it.
19:36:03  <isaacs>and i want to abstract out a nice little read(1) type prompt thing, but it keeps the process open if you ever do anything with stdin
19:36:05  <indutny>I'm managing a lot of cli apps
19:36:11  <isaacs>and that's dumb.
19:36:22  <mmalecki>yeah
19:37:08  <isaacs>bnoordhuis: so, it looks like, if we want to have this for pipes as well, it needs tobe in lib/net.js, not in lib/tty.js
19:37:17  * Marakjoined
19:39:08  <bnoordhuis>isaacs: yes, possibly
19:39:30  <bnoordhuis>at any rate, both tty and pipe wrap classes need to export ref and unref methods to js land
19:39:41  <isaacs>sure.
19:39:53  <isaacs>seems like we could just Ref in ReadStart and unref in ReadStop
19:40:46  <indutny>btw, are you guys going to document timers?
19:40:53  <isaacs>i guess we don't need to ref and unref for tcp wraps
19:41:14  <bnoordhuis>isaacs: for tty_wrap.cc that's probably true, not 100% sure about pipes
19:41:37  <isaacs>k
19:41:48  <bnoordhuis>or rather, regular pipes should keep the event loop alive
19:43:17  * mikealjoined
19:45:13  <mmalecki>won't it render stdin.resume() and pause() redundant?
19:45:18  <indutny>bnoordhuis: wait, process won't terminate until piping is finished?
19:45:28  <bnoordhuis>indutny: ?
19:45:44  * Nohrybquit (Quit: Nohryb)
19:45:49  <indutny>bnoordhuis: about ref&unrefing pipes
19:46:21  <indutny>looks like I missed point
19:46:26  <bnoordhuis>indutny: yes :)
19:46:30  <indutny>:)
19:46:47  <indutny>bnoordhuis: "regular pipes should keep the event loop alive"
19:46:54  <indutny>bnoordhuis: what is regular pipes?
19:46:58  <indutny>in this context
19:47:19  <bnoordhuis>indutny: e.g. the unix socket you're connected with to your db
19:47:27  <bnoordhuis>mmalecki: re test-tty, can you be a little more specific?
19:47:57  <isaacs>mmalecki: no, it'll render them much less redundant.
19:48:11  <indutny>bnoordhuis: ah, that pipes :)
19:48:16  <isaacs>mmalecki: since stdin.pause() will be how you say "Ok, i'm done reading from stdin now"
19:48:41  <indutny>isaacs: at least it'll behave like 0.4.x and 0.5.x
19:48:52  <mmalecki>isaacs: ah, makes sense.
19:48:55  <indutny>:)
19:48:59  <isaacs>mmalecki: just like 0.4
19:49:12  <isaacs>i mean, "resume" to start, and pause to end, is a bit odd.
19:49:42  <isaacs>we can probably make those like "open" and "close" or something better, i don't really care. as long as it's *possible* to do the right thing, that's all that matters really.
19:50:41  <mmalecki>bnoordhuis: I merged indutny's patch and now test-tty timeouts. I think it's the only test which shouldn't fail. but I guess it doesn't matter now.
19:52:44  <indutny>mmalecki: it's just not refing tty's on initialization
19:53:09  <mmalecki>indutny: that might be it, I haven't investigated it yet
19:55:07  <isaacs>igorzi: maybe you know this… how hard would it be to get the msi to support updating, rather than making the user manually uninstall it to get the new version?
19:55:14  <isaacs>igorzi: it'd be super awesome if we could even just push updates
19:55:36  <benvie>chrome style
19:55:43  <benvie>ninja update
19:55:51  * indexzerojoined
19:56:18  <mmalecki>benvie: most interesting thing there is the algorithm
19:56:32  <piscisaureus>ryah: I have to go soon. You want to talk now?
19:56:44  <indutny>mmalecki: yeah, chrome is using cool binary diff
19:57:36  <igorzi>isaacs: yeah, it should be pretty trivial to do what's called a major update, which is when the new msi just uninstalls the old one if it detects that it's installed
19:58:14  <isaacs>igorzi: yeah, it's jsut that havingi to go to control panel: add/remove software, find "nodejs" in the list, it's a pain
19:58:15  <igorzi>isaacs: or do you mean updating without installing new version of node?
19:58:30  <isaacs>igorzi: it could be an uninstall and reinstall, that's fine
19:58:48  <isaacs>super doubleplusgood if we can hook into the windows update thingie, though
19:59:42  <igorzi>i'll get the update to work for the next release.. i think there's an issue for it?
20:06:58  * Nohrybjoined
20:09:29  <indutny>isaacs: patch is ready :)
20:09:32  <indutny>uploading :D
20:11:54  <indutny>isaacs: https://github.com/joyent/node/pull/2276
20:12:02  <indutny>running tests
20:12:14  * Nohrybquit (Read error: Connection reset by peer)
20:13:09  <indutny>tests are passing
20:14:09  <isaacs>ryah, bnoordhuis: hm… i'm a bit confused about hte significance of the "wrap->unref" var. it looks like it's a boolean saying whether or not the thing needs to be unrefed, and true means we don't have a reference to it...?
20:14:26  * isaacsis confused easily by double negatives
20:15:04  <indutny>isaacs: unref => unreferenced
20:15:28  <indutny>but it's really confusing
20:15:40  <bnoordhuis>isaacs: ^ what indutny said and yes, confusing
20:15:42  <isaacs>yeah.
20:16:06  <isaacs>"foo->X is true if not Y" <-- antipattern
20:16:31  <isaacs>even worse: foo->notX is true if not X
20:16:58  <indutny>hehe
20:17:05  <indutny>should I fix that in PR?
20:17:21  <isaacs>indutny: nono, i'm digging into this stdin pause/resume thing
20:17:33  <indutny>ok, seems to be working for me
20:18:30  <indutny>isaacs: https://spdy2.indutny.com/ <- this site runs with my zlib patch support ;)
20:18:51  <isaacs>indutny: nice
20:21:24  * indutnyis going to sleep
20:21:25  <indutny>ttyl!
20:23:20  <bnoordhuis>indutny: sleep tight
20:23:29  <mmalecki>indutny: night
20:27:03  * isaacsquit (Ping timeout: 248 seconds)
20:29:10  <mjr_>Hey guys, I made some progress on our men leak issue with 0.6
20:29:12  * piscisaureusquit (Ping timeout: 245 seconds)
20:29:38  <mjr_>It seems related to aborting http client connections that are still waiting for a socket.
20:29:59  <mjr_>Still trying to figure out how to reliably reproduce it.
20:30:53  <einaros>do you have an app or scenario which loosely reproduces it?
20:31:11  <mjr_>Oh yes.
20:31:32  <mjr_>We have probably the busiest node app out there right now, and upgrading to 0.6 was a mixed blessing.
20:32:43  <mjr_>Basically, http server gets some incoming connections, and we need to make multiple outgoing http connections to various backend services to handle this request. If one of those backendn components is slow, the incoming client gives up.
20:33:08  <mjr_>So we abort all of the outgoing requests that we made on behalf of this client, and some of them seem to not get cleaned up.
20:33:11  <einaros>and you're using plain http; no socket.io or similar?
20:33:16  <mjr_>Plain HTTP.
20:33:37  <mjr_>Also HTTPS, but I don't think that's the culprit here, for once.
20:36:13  <bnoordhuis>mjr_: sounds plausible
20:36:27  <bnoordhuis>do you set req.connection.setTimeout()?
20:36:39  <mjr_>just defaults
20:37:02  <bnoordhuis>how do you abort the outgoing requests?
20:38:00  <bnoordhuis>mjr_: ^
20:38:06  <mjr_>lemme check
20:39:26  * paddybyersjoined
20:39:38  * bnoordhuisgets another cup of tea
20:41:05  <mjr_>so we do: out_client = http.request(); in_client.on("abort", function () { out_client.abort(); })
20:41:07  <mjr_>basically
20:42:51  <bnoordhuis>mjr_: 'abort' or 'aborted'?
21:05:13  <mjr_> this.in_client.req.on("aborted", function () {
21:05:21  <mjr_>sorry, phone call
21:11:29  * isaacsjoined
21:13:22  <bnoordhuis>mjr_: what about the 'close' event? do you abort outstanding connections if 'close' is emitted?
21:13:32  <mjr_>oh sure
21:13:45  <mjr_>wait, no
21:14:02  <mjr_>we listen for aborted, data, end, and drain on incoming http.
21:14:17  <mjr_>All at the req level.
21:14:55  <mjr_>We also do a lot of chunked uploads, if that's relevant. I know it's somewhat uncommon.
21:15:27  <mjr_>I haven't figured out if the leaking connections are uploads or not
21:16:27  <mjr_>what I did figure out is that if we avoid the backlog, then we avoid this leak. I obviously want to be able to recover from a backlog though.
21:16:52  <mjr_>Could it be that if you abort an outgoing request before it has a socket assigned that this somehow gets orphaned?
21:17:05  <bnoordhuis>mjr_: no, it gets queued
21:17:07  * mikealquit (Quit: Leaving.)
21:17:29  <bnoordhuis>you should listen for close, it's what's emitted if the connection is prematurely terminated
21:17:37  <mjr_>oh, not aborted?
21:17:58  <bnoordhuis>well... that too, it kind of depends on the scenario
21:18:22  <mjr_>Are there scenarios where we'd get a close on a request, but not an aborted?
21:18:44  * bnoordhuisdouble-checks http.js
21:19:45  <bnoordhuis>mjr_: yes - timeout, for example
21:19:54  <mjr_>oh really
21:20:01  <mjr_>Well then
21:20:31  <mjr_>So if an incoming chunked post gets a socket timeout, this emits close and not aborted?
21:20:57  <bnoordhuis>mjr_: yes - after two minutes by default
21:21:21  <mjr_>oh, this is the node 2 minute idle timer thing, or the kernel returning ETIMEDOUT on read?
21:21:48  <bnoordhuis>mjr_: the former, the idle timer
21:22:24  <mjr_>Hmm, I guess we leak those.
21:22:36  <mjr_>But doesn't that timer get cleared after the first read?
21:22:50  <ryah>it gets reset
21:23:15  <mjr_>I thought that http.js cleared that timer after parsing the headers
21:23:17  <mjr_>or something like that
21:23:33  <ryah>the unspoken rule (cc isaacs) is that all streams *always* get 'close'
21:23:38  <ryah>except zlib streams
21:23:42  <ryah>:)
21:23:57  * mikealjoined
21:24:01  <ryah>mjr_: no, i don't think so
21:24:23  <mjr_>OK, fair enough, I'll add a close listener. Did this change in 0.6?
21:24:32  <bnoordhuis>don't think so
21:24:33  <mjr_>Trying to figure out why it might be different on 0.6.
21:24:43  <ryah>i also don't think so
21:25:49  <ryah>oh wait, yes this might have changed
21:25:55  <ryah>mikeal: maybe you can weigh in on this
21:26:37  <ryah>mikeal: is it possible that client http streams used to emit 'aborted' on timeout but now emit 'close' ?
21:28:22  <ryah>oh wait - nevermind
21:28:29  <ryah>this is server http streams
21:29:26  * paddybyersquit (Quit: paddybyers)
21:29:28  <ryah>mjr_: how did you determine that there are outbound client stream leaking?
21:29:40  * mikealquit (Quit: Leaving.)
21:29:56  <mjr_>so there weren't enough outgoing sockets, and I increased the number of outgoing sockets
21:29:58  <ryah>(incidentally this is a situation that would be avoided by domains)
21:30:05  <mjr_>And the memory didn't go away.
21:30:15  <mjr_>Thankfully I had a REPL on everything
21:30:37  <mjr_>So basically http client queues were getting behind, but they were still doing work, just not as fast as more work was being added.
21:30:59  <mjr_>As the queues drained though, we didn't reclaim the memory.
21:31:09  <mjr_>I ASSUME because clients were timing out and we aborted the outgoing requests for them.
21:31:10  <ryah>so these outbound clients - do you think they're just timing out?
21:31:20  <mjr_>They are talking to a server that's slow
21:31:41  <mjr_>They are all grinding along, but doing like 2 req/sec instead of 200 req/sec, for example.
21:32:13  <ryah>hm - will you be able to put the fix in that bnoordhuis suggested and let us know?
21:32:19  <mjr_>So this backlog, it's obviously bad and we need to push this back pressure all the way down to our clients, which we will soon.
21:32:36  <mjr_>But the real issue is that when the backlog clears, some memory was held open forever.
21:32:49  <mjr_>Sure, I can add a close listener.
21:34:33  <mjr_>To be fair, we are really an exceptionally heavy user of HTTP client, I would guess anyway. I think yesterday we did around 4B client requests, but I had to turn off that metric because I can't track that many individual requests anymore.
21:35:05  <bnoordhuis>that's a lot of requests
21:35:52  <ryah>B
21:36:02  <mjr_>Yeah, it's really a ton of node processes doing a ton of work.
21:36:07  <mjr_>And it's only getting larger every day.
21:40:14  <ryah>so do the outbound http start out at 200 req/sec
21:40:18  <ryah>and then suddenly get slow?
21:40:58  <mjr_>one of the servers gets slow, for various reasons. Either its waiting for a database, it has a bug and is restarting, or something.
21:41:14  <mjr_>This router/proxy app is otherwise doing great.
21:41:25  <mjr_>But the destinations can't keep up.
21:44:27  <CIA-111>node: Ben Noordhuis v0.6 * r36815e4 / (src/node.js test/simple/test-process-exit.js): process: fix stack overflow when recursively calling process.exit() - http://git.io/eWAEEA
22:02:18  * dapquit (Quit: Leaving.)
22:03:43  * dapjoined
22:07:21  * mralephjoined
22:30:39  * piscisaureus_joined
22:43:47  * Nohrybjoined
22:44:45  * Nohrybquit (Client Quit)
22:51:46  * piscisaureus__joined
22:53:18  * piscisaureus_quit (*.net *.split)
23:12:29  * bnoordhuisquit (Ping timeout: 240 seconds)
23:23:43  * dapquit (Quit: Leaving.)
23:39:42  <isaacs>ryah: that rule is *extremely* unspoken.
23:40:09  <isaacs>ryah: in fact, ti's so unspoken, it can hardly be said to really exist.
23:42:54  * dapjoined