00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:14  <kellabyte>so http pipelining works great on windows but for some reason not so on OSX, after I write I'm not calling uv_close(), does that sound correct?
00:00:31  <kellabyte>write meaning respond to the request
00:00:54  <kellabyte>wrk responds with timeouts
00:08:46  * loladiroquit (Quit: loladiro)
00:15:09  * loladirojoined
00:18:04  * dapquit (Quit: Leaving.)
00:26:04  <wolfeida_>kellabyte: Have you had a look on the wire?
00:26:25  * kazuponjoined
00:26:35  <kellabyte>wolfeida_: not yet, whats a good HTTP debugging tool? I know of fiddler on windows (easier to understand than wireshark)
00:26:59  <kellabyte>wolfeida_: what do you suggest for osx?
00:27:23  <wolfeida_>kellabyte: I use the terminal version of wireshark mostly, there is a program called charles for OSX
00:27:41  * txdvquit (Remote host closed the connection)
00:27:56  <wolfeida_>kellabyte: All your reall interested in is whether or not connections are being reused atm right?
00:28:21  <wolfeida_>you can do this on OSX with netstat or dtrace
00:28:24  <kellabyte>wolfeida_: no, that's http keep-alive, pipelining is another thing
00:28:31  * txdvjoined
00:28:54  <kellabyte>well both reuse connections but one won't wait for responses to send requests
00:29:07  <wolfeida_>hmm i need to read the spec but pipelining is async queuing of requests without waiting for response
00:29:15  <kellabyte>yeah
00:29:32  <kellabyte>keep-alive also reuses the connection, but it waits for a response before sending the next request
00:29:37  <wolfeida_>yeah
00:29:54  <wolfeida_>so you could do it in tshark i think
00:30:07  <kellabyte>this code sitting on libuv worked fine on windows, so something I maybe am doing wrong I dunno
00:30:08  <wolfeida_>do you have homebrew installed?
00:30:12  <kellabyte>yup
00:30:51  * kazuponquit (Ping timeout: 258 seconds)
00:31:04  <wolfeida_>brew install wireshark
00:31:14  <wolfeida_>Either way that is a VERY handy tool
00:31:26  <kellabyte>ok
00:32:00  <wolfeida_>this is the page i use a lot http://kvz.io/blog/2010/05/15/analyze-http-requests-with-tshark/
00:32:53  <wolfeida_>gives you a few recipes which will enable you to see http in the terminal in both verbose (OMG SO MUCH TEXT) and brief mode :)
00:33:20  * loladiroquit (Quit: loladiro)
00:33:22  <kellabyte>wicked, thanks :) installing now
00:34:05  <kellabyte>am I correct in my libuv knowledge that to keep a connection open properly for keep-alive or pipelining I just don't call uv_close()?
00:35:35  <wolfeida_>kellabyte: I have seen your posts on twitter, your way ahead of me on libuv knoweldge :) either way i like to see proof via the wire
00:36:20  <kellabyte>wolfeida_: haha :)
00:37:01  <wolfeida_>sudo tshark -i en1 -R "http.request || http.response" tcp port 80 or tcp port 443
00:37:31  <wolfeida_>that will give you a breif list of http requests and responses, note i am using wireless so the interface specified is eth1
00:37:34  <wolfeida_>en1 sorry
00:37:55  <wolfeida_>en0 is typically the wired interface unless your on an air or something
00:38:02  <kellabyte>damn, brew getting a 404 on the wiresharp bzip
00:39:14  <wolfeida_>do a brew update
00:40:48  * loladirojoined
00:41:58  <wolfeida_>if the wireshark recipe is listed after the update try again otherwise you can tweak the brew it is just a simple ruby script
00:45:47  * AvianFluquit (Remote host closed the connection)
00:48:23  <kellabyte>yeah update looks to be downloading a new bzip, thanks
00:53:32  <wolfeida_>just refreshing my memory on http pipelineing
00:54:23  <wolfeida_>and watching it happen in wireshark
00:54:24  <indutny>fuck pipelining
00:54:25  <indutny>use spdy
00:54:26  <indutny>:)
00:54:30  * dapjoined
00:54:40  <wolfeida_>indutny: haha
00:55:04  <indutny>really, just reply "Connection: close"
00:55:07  <indutny>hehe
00:57:20  <wolfeida_>reading the Head-of-line blocking article on wikipedia quite a bit out of date
00:58:57  <wolfeida_>someone needs at add a note next to out of order delivery, "seen frequently when observing data that has passed over any mobile network"
01:00:58  <wolfeida_>HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response.
01:01:26  <wolfeida_>You see that a lot with bad http client implementations
01:02:14  <wolfeida_>kellabyte: It is my understanding that http pipelining is a required feature of HTTP 1.1
01:02:48  <kellabyte>wolfeida_: ah, interesting
01:02:54  <wolfeida_>from memory if you don't want to use it you pretty much have to use HTTP 1.0
01:03:04  <kellabyte>wolfeida_: I want pipelining
01:03:17  <kellabyte>wolfeida_: tshark on lo0 seems to not be showing any output, hmm
01:03:44  <wolfeida_>kellabyte: Yeah i think that interface is protected from memory
01:04:07  <MI6>libuv-master: #82 UNSTABLE smartos (3/188) windows (4/189) linux (1/188) osx (1/188) http://jenkins.nodejs.org/job/libuv-master/82/
01:05:02  <wolfeida_>hmm says it should work on OSX
01:05:13  * mikealquit (Quit: Leaving.)
01:05:25  <wolfeida_>kellabyte: are you using port 80 or 443?
01:05:31  <kellabyte>8000
01:05:42  <kellabyte>I put that in the tshark command line though
01:05:54  <wolfeida_>sec i will try it
01:05:55  <kellabyte>if I don't do the http -r thing you had, it outputs some stuff
01:08:47  <wolfeida_>tshark -i lo0 -R "http.request || http.response" -d tcp.port==8000,http tcp port 8000 or tcp port 443
01:09:07  <wolfeida_>you need to tell it to decode 8000 as http
01:09:28  * dominictarrquit (Quit: dominictarr)
01:10:53  <kellabyte>ah cool now I'm seeing stuff!
01:12:01  <wolfeida_>kellabyte: now you should be able to deduce pipelining by the order in which requests and responses come through
01:12:14  <kellabyte>interesting, 2 gets, to responses, 2 gets, no responses, I've set wrk to do 2 pipeline requests
01:12:15  <wolfeida_>sound correct?
01:12:54  <kellabyte>wolfeida_: is there a way to spit out the details like the actual response text etc?
01:13:12  <wolfeida_>add a -V switch but get ready for a lot of text
01:13:23  <wolfeida_>you can add fields to the output
01:13:34  <wolfeida_>at the moment your seeing the default fields
01:14:31  <wolfeida_>-T fields -e http.cookie
01:14:34  <wolfeida_>for example
01:14:56  <wolfeida_>kellabyte: Each decoder has a page on wireshark wiki from memory
01:15:33  * sblomquit (Ping timeout: 240 seconds)
01:16:20  <kellabyte>wolfeida_: cool thanks, I'll check it out
01:16:33  <kellabyte>thanks so much for the help
01:16:40  <kellabyte>seems for some reason I stop responding
01:16:56  <wolfeida_>kellabyte: for what your hacking on that tool will help a ton
01:17:08  <kellabyte>my libuv code shows 1 less pair of header requests than what tshark see's going out on the wire
01:18:00  <wolfeida_>kellabyte: could be buffering of some sort going on ?
01:22:46  <MI6>libuv-node-integration: #29 UNSTABLE smartos-ia32 (3/582) osx-x64 (1/582) smartos-x64 (1/582) osx-ia32 (1/582) windows-x64 (8/582) windows-ia32 (7/582) http://jenkins.nodejs.org/job/libuv-node-integration/29/
01:22:54  <kellabyte>wolfeida_: dunno yet, hopefully find out sooner than later :)
01:24:43  <wolfeida_>kellabyte: haha good luck, the two tools i use a lot for this sort of thing are wireshark and dtrace
01:26:02  <kellabyte>wolfeida_: thanks! and thanks for the help :)
01:26:47  <wolfeida_>kellabyte: np any time, you also in the process refreshed my knowledge of tshark :)
01:26:58  * kazuponjoined
01:27:08  <kellabyte>:)
01:29:17  * pooyajoined
01:31:32  * kazuponquit (Ping timeout: 252 seconds)
01:44:49  * dapquit (Quit: Leaving.)
01:44:53  * pooyaquit (Quit: pooya)
02:02:15  * trevnorrisquit (Quit: Leaving)
02:19:59  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:22:55  * pooyajoined
02:26:09  * loladiroquit (Quit: loladiro)
02:34:23  * loladirojoined
02:35:43  * c4milojoined
03:04:37  * piscisaureus_quit (Ping timeout: 248 seconds)
03:12:39  <kellabyte>any libuvers awake? :P
03:15:12  * dscape_quit (*.net *.split)
03:15:12  * joclekquit (*.net *.split)
03:15:20  <rvagg>wrong time of day for action in here kellabyte
03:16:22  <kellabyte>rvagg: ah ok no prob :)
03:20:12  * dscape_joined
03:20:12  * joclekjoined
03:24:07  * brsonquit (Ping timeout: 260 seconds)
03:27:28  * kazuponjoined
03:29:18  <wolfeida_>kellabyte: almost have that gist running just need to work out how to add a main function
03:31:39  <kellabyte>wolfeida_: oh cool :)
03:31:55  * kazuponquit (Ping timeout: 246 seconds)
03:36:17  <wolfeida_>kellabyte: seems to accept 128 requests then die
03:37:33  * mikealjoined
03:38:55  <wolfeida_>so for some reason the backlog setting is not working correctly i think
03:39:01  <wolfeida_>kellabyte: have you had a look at https://github.com/bnoordhuis/libuv-chat/blob/master/src/main.c
03:39:36  <wolfeida_>kellabyte: either way my seriously rough version is here https://github.com/wolfeidau/uvwebserver
03:41:59  <kellabyte>wolfeida_: yeah I saw that, I can't see anything there that looks majorly different, I thought I was misusing uv_read_start() but the use looks similar
03:42:10  <kellabyte>its like libuv isn't sending me anymore bytes although wireshark shows more
03:50:19  * kazuponjoined
03:54:26  <wolfeida_>kellabyte: So it responds correctly 244 times
03:54:55  <kellabyte>with wrk using --pipeling 2?
03:54:58  <kellabyte>or more
03:58:39  <wolfeida_>kellabyte: I am just using siege localhost:8000 at the moment what is wrk?
03:59:15  <kellabyte>wolfeida_: https://github.com/wg/wrk/tree/pipeline
03:59:43  <kellabyte>might be exposing the same problem in siege, I dunno, I was testing pipelining with wrk which is a client that supports pipelining if you get that specific branch
04:00:08  <kellabyte>with --pipeline 2 you'll see 2 requests, 2 responses, then 2 requests, and no responses
04:02:26  <kellabyte>ok bed time, if you do find anything, tweet me :P back at it tomorrow!
04:03:00  * c4miloquit (Remote host closed the connection)
04:07:54  <wolfeida_>kellabyte: yeah np
04:10:03  * pooyaquit (Quit: pooya)
04:10:52  * brsonjoined
04:23:10  * defunctzombiechanged nick to defunctzombie_zz
04:36:25  * TooTallNatejoined
04:38:02  * TooTallNatequit (Client Quit)
05:16:46  * loladiroquit (Quit: loladiro)
05:17:24  * mikealquit (Quit: Leaving.)
05:19:29  * kellabyte2joined
05:19:50  * loladirojoined
05:20:06  * mikealjoined
05:20:38  * CoverSli1ejoined
05:21:19  * toothrjoined
05:25:28  * kellabytequit (*.net *.split)
05:25:28  * CoverSlidequit (*.net *.split)
05:25:28  * toothrotquit (*.net *.split)
05:30:03  * kellabyte2changed nick to kellabyte
05:41:04  * kazuponquit (Remote host closed the connection)
06:11:26  * kazuponjoined
06:20:03  * kazuponquit (Ping timeout: 260 seconds)
06:25:58  * abraxasjoined
06:30:17  * abraxasquit (Ping timeout: 252 seconds)
06:40:01  * mikealquit (Quit: Leaving.)
06:43:54  * mikealjoined
07:04:36  * benoitcquit (Ping timeout: 245 seconds)
07:05:16  * benoitcjoined
07:14:39  * rendarjoined
07:16:40  * kazuponjoined
07:21:31  * kazuponquit (Ping timeout: 264 seconds)
07:34:33  * kazuponjoined
08:26:17  * abraxasjoined
08:30:35  * abraxasquit (Ping timeout: 252 seconds)
08:31:42  * kazuponquit (Remote host closed the connection)
09:11:01  * kazuponjoined
09:24:52  * loladiroquit (Quit: loladiro)
09:54:30  * hzjoined
10:06:48  * hzquit (Ping timeout: 264 seconds)
10:08:04  * brsonquit (Ping timeout: 256 seconds)
10:17:12  * toothrchanged nick to toothrot
10:39:58  * luxigojoined
10:41:13  * bnoordhuisjoined
10:49:15  * dominictarrjoined
11:01:15  * kazuponquit (Remote host closed the connection)
11:16:46  * c4milojoined
11:26:44  <tjfontaine>bens awake
11:30:08  <mmalecki>wow, it's barely 1 PM and he's awake?
11:30:35  <tjfontaine>on a saturday no less
11:31:37  * kazuponjoined
11:33:09  <mmalecki>there has to be something wrong, I'm sure
11:33:32  <tjfontaine>bnoordhuis: is everything ok?
11:33:40  <bnoordhuis>the house was on fire
11:33:41  <bnoordhuis>but yeah
11:33:53  <tjfontaine>it's out now? or you moved?
11:34:03  <bnoordhuis>i moved to the front of the house
11:34:11  <bnoordhuis>tjfontaine: https://github.com/joyent/node/pull/5325 <- is that ready to go in?
11:34:17  <bnoordhuis>it says 0.11.2
11:34:59  <tjfontaine>I don't think isaacs cut an 11.2 for the node-0.11.1 release so
11:35:06  <bnoordhuis>ah okay
11:35:11  <bnoordhuis>i see the dtrace stuff in deps/uv/
11:35:32  <tjfontaine>yes, but there's a uv.gyp fix that needs to land
11:35:33  <bnoordhuis>this 'only official releases' stuff is kinda limiting
11:35:50  <mmalecki>bnoordhuis: like that: http://www.golfbytourmiss.com/gbtm/wp-content/uploads/2012/07/House-on-fire.png ?
11:35:57  <tjfontaine>because gyp is a tempermental bitch
11:36:39  <bnoordhuis>mmalecki: indeed :)
11:37:30  <bnoordhuis>re upgrades, i move we move to a scheme where we do intermediate upgrades + an official libu release when we release node
11:37:37  <bnoordhuis>*libuv
11:38:05  <bnoordhuis>esp. in master because there's easily two or three weeks between releases
11:38:08  <tjfontaine>that makes sense to me, merge libuv at will, but cut a libuv same-day as node
11:38:13  <bnoordhuis>yep
11:38:58  <bnoordhuis>isaacs: you around?
11:39:05  <bnoordhuis>indutny: and you?
11:39:12  <tjfontaine>it's pretty early in .ca land right now
11:39:33  <bnoordhuis>right. what timezone are the bahamas in?
11:39:44  <tjfontaine>and indutny is on his way back to NYC? they're same as NY
11:39:47  <tjfontaine>afaik
11:39:52  * kazuponquit (Ping timeout: 256 seconds)
11:40:02  <tjfontaine>which is -4 right now I think
11:40:08  <bnoordhuis>ah right. okay, let's discuss it on monday
11:41:21  <tjfontaine>I'm on my way to -4 today as well
11:42:08  <bnoordhuis>oh? why?
11:42:53  <tjfontaine>surprise visit for my moms birthday
11:47:02  <bnoordhuis>congratulations!
11:47:24  <tjfontaine>heh
11:48:56  <tjfontaine>I'll pass along your well wishes :)
12:00:24  * hzjoined
12:00:30  <mmalecki>do you guys run Linux on MacBooks, per chance?
12:00:41  <bnoordhuis>on and off
12:00:45  <bnoordhuis>it's hit and miss
12:00:56  <bnoordhuis>mostly miss
12:01:09  <mmalecki>bnoordhuis: is installation a pain?
12:01:19  <bnoordhuis>mmalecki: not if it works :)
12:01:50  <bnoordhuis>sorry, gotta go. ask me about it tonight
12:01:56  * bnoordhuiswaves
12:02:17  <mmalecki>:) o/
12:06:10  * bnoordhuisquit (Ping timeout: 252 seconds)
12:06:54  <mmalecki>daaamn, valgrind is sure broken on OS X
12:36:50  * kazuponjoined
12:41:17  * kazuponquit (Ping timeout: 255 seconds)
12:48:18  * `3rdEdenjoined
13:12:22  * bnoordhuisjoined
13:13:07  * piscisaureus_joined
13:15:12  * bnoordhuisquit (Read error: Operation timed out)
13:37:23  * kazuponjoined
13:37:59  * defunctzombie_zzchanged nick to defunctzombie
13:41:17  * trippehquit (Quit: leaving)
13:42:01  * kazuponquit (Ping timeout: 258 seconds)
13:50:36  * hzquit (Ping timeout: 264 seconds)
13:55:29  * hzjoined
14:08:23  * AvianFlujoined
14:37:57  * kazuponjoined
14:40:40  * `3rdEdenquit (Remote host closed the connection)
14:44:30  * kazuponquit (Ping timeout: 264 seconds)
14:51:31  * c4miloquit (Remote host closed the connection)
15:06:25  * benoitcquit (Excess Flood)
15:06:25  * loladirojoined
15:08:10  * loladiroquit (Client Quit)
15:13:51  * benoitcjoined
15:21:30  * bnoordhuisjoined
15:26:07  * txdvquit (Remote host closed the connection)
15:33:09  * bnoordhuisquit (Ping timeout: 252 seconds)
15:40:30  * kazuponjoined
15:45:14  * kazuponquit (Ping timeout: 252 seconds)
16:09:21  * txdvjoined
16:11:27  <txdv>hello
16:27:33  * loladirojoined
16:34:24  * loladiroquit (Ping timeout: 264 seconds)
16:41:05  * kazuponjoined
16:43:33  * AvianFluquit (Remote host closed the connection)
16:45:54  * inolenquit (Quit: Leaving.)
16:46:12  * inolenjoined
16:47:06  * kazuponquit (Ping timeout: 245 seconds)
16:47:35  * loladirojoined
17:11:19  * loladiroquit (Quit: loladiro)
17:26:38  * defunctzombiechanged nick to defunctzombie_zz
17:37:39  <kellabyte>any libuvers awake this afternoon? :)
17:43:39  * kazuponjoined
17:44:48  * loladirojoined
17:49:23  * pooyajoined
17:52:12  * kazuponquit (Ping timeout: 256 seconds)
17:53:15  * perezdjoined
17:54:36  * perezdquit (Client Quit)
17:55:30  * perezdjoined
17:56:51  * mikealquit (Quit: Leaving.)
17:57:25  * mikealjoined
17:58:59  * mikealquit (Client Quit)
18:02:21  * pooyaquit (Quit: pooya)
18:04:04  * `3rdEdenjoined
18:10:26  * piscisaureus_quit (Ping timeout: 252 seconds)
18:25:21  * mikealjoined
18:30:22  * piscisaureus_joined
18:30:54  * defunctzombie_zzchanged nick to defunctzombie
18:33:37  * hzquit
18:37:56  * piscisaureus_quit (Ping timeout: 252 seconds)
18:40:55  <kellabyte>I would appreciate a second set of eyes on this, I'm doing something wrong with libuv I think :) https://gist.github.com/kellabyte/5426722
18:42:31  * mikealquit (Quit: Leaving.)
18:44:08  * `3rdEdenchanged nick to `3E
18:48:48  * kazuponjoined
18:53:26  * kazuponquit (Ping timeout: 255 seconds)
18:58:52  * mikealjoined
19:17:18  * bnoordhuisjoined
19:20:43  <kellabyte>bnoordhuis: hiya! how are you? I was wondering if you might have a few minutes to check out something I'm having trouble with :)
19:21:41  <bnoordhuis>kellabyte: sure, shoot
19:23:29  <kellabyte>bnoordhuis: wicked! thanks so much :) I'm having difficulties with http_parser, I gathered a bunch of info of the problem here: https://gist.github.com/kellabyte/5426722
19:23:46  <kellabyte>I'm sure the webserver.c implementation is misusing libuv perhaps but I'm not sure what
19:24:17  <bnoordhuis>kellabyte: i'm really only good at yes/no type of questions
19:24:40  <bnoordhuis>i.e. "can i use quux when foo is assigned to bar?" "yes" (or no as the case may be)
19:25:27  <kellabyte>bnoordhuis: ah okay, sorry. do you know who I can talk to about libuv and http_parser? I'm having difficulty understanding what is wrong
19:25:50  <kellabyte>bnoordhuis: I saw you on the commit list so sorry for bothering you
19:25:58  <bnoordhuis>kellabyte: well, me i suppose
19:26:42  <roxlu>kellabyte: I had a never ending loop a couple of weeks ago too
19:26:58  <bnoordhuis>btw, i didn't know wrk supports pipelining
19:27:21  <roxlu>kellabyte: I think I fixed it by creating a separate loop (uv_loop_new())
19:27:51  <roxlu>(it was actually a "bug" caused by my own code)
19:28:51  <bnoordhuis>kellabyte: ./wrk -d1 -t1 -c1 --pipeline 2 http://127.0.0.1:8000/ <- are you sure htat line does what you think it does?
19:28:55  <bnoordhuis>*that
19:29:48  <kellabyte>bnoordhuis: the wireshark output looks to do what I expect it to be doing (minus the last requests)
19:30:57  <bnoordhuis>kellabyte: `git grep pipeline` on wrk's repo doesn't show any hits
19:32:43  <kellabyte>bnoordhuis: https://github.com/wg/wrk/tree/pipeline
19:33:07  <bnoordhuis>ah
19:33:27  <bnoordhuis>then my next question would be: does wrk implement it correctly?
19:33:32  <kellabyte>ah I need to update my git instructions, I thought submodules auto fetch but they don't lol
19:33:57  <bnoordhuis>almost all tools that do http pipelining bork it in some way
19:35:44  <kellabyte>bnoordhuis: dunno but several people recommended it so I'm going to blame my usage of libuv before I blame a thing people are successfully testing with lol
19:36:03  <kellabyte>is there another pipelined benchmark tool thats better to try?
19:37:49  <bnoordhuis>httperf does, i think
19:37:59  <bnoordhuis>curl does too but that's not really a benchmarking tool, of course
19:38:40  <kellabyte>well at this point I can't even benchmark because it just fails in under 4 requests
19:40:32  <bnoordhuis>do non-pipelined keep-alive requests work?
19:40:35  <kellabyte>and after_write() gets called forever from uv_write()
19:40:37  <kellabyte>yup
19:40:48  * defunctzombiechanged nick to defunctzombie_zz
19:40:49  <bnoordhuis>btw, http_parser itself doesn't really support pipelining
19:41:24  <bnoordhuis>how did you add it?
19:41:48  <kellabyte>bnoordhuis: it seems to be a writing issue not a reading one unless I understand the problem wrong but my output shows its reading the messages
19:42:02  <kellabyte>what do you mean by add it? I just included http_server.h and .c to my project
19:42:11  <kellabyte>thanks for the help btw :)
19:43:01  <kellabyte>after_write() is endlessly happening so does that indicate some kind of endless loop its stuck on?
19:43:08  <kellabyte>from uv_write()
19:43:20  <bnoordhuis>kellabyte: do you create a new http_parser struct after on_headers_complete?
19:43:30  <bnoordhuis>for the next pipelined request, i mean?
19:43:48  <bnoordhuis>if you keep using the same one, well, things are bound to go corrupt
19:44:01  <kellabyte>bnoordhuis: ah! that may be a problem then since I'm not :)
19:44:19  <kellabyte>bnoordhuis: doesn't explain why it worked on windows though, or is it just a timing thing and I got lucky?
19:44:34  <bnoordhuis>probably
19:47:41  <kellabyte>bnoordhuis: are you talking about this call? http_parser_init(&client->parser, HTTP_REQUEST);
19:48:09  <bnoordhuis>kellabyte: yes
19:48:25  <bnoordhuis>see, that's the kind of questions i'm good at
19:48:57  <kellabyte>bnoordhuis: yeah, sorry for being difficult, I'm just having difficulty understanding the problem
19:49:28  <bnoordhuis>kellabyte: http pipelining means that multiple requests are fired off simultaneously over the same connection
19:49:45  <kellabyte>bnoordhuis: yups
19:49:51  * kazuponjoined
19:49:55  <kellabyte>bnoordhuis: and without waiting for the response like in keep-alive
19:50:12  <bnoordhuis>you can't just use a single http_parser because you're not receiving/responding in serial but concurrently
19:50:37  <bnoordhuis>if i read your code correctly, you use a single instance now
19:50:45  <kellabyte>bnoordhuis: per connection, yeah
19:50:51  <bnoordhuis>yep
19:51:14  <bnoordhuis>what it should do is fork the http_parser instance in its on_headers_complete cb
19:51:21  * mikealquit (Quit: Leaving.)
19:51:38  <bnoordhuis>and then you have to make sure that the right request body data gets fed to the right http_parser instance, of course
19:52:12  <kellabyte>hmm
19:52:29  <bnoordhuis>it's not trivial
19:52:41  <bnoordhuis>that's also the reason why almost nothing implements pipelining
19:54:13  * kazuponquit (Ping timeout: 248 seconds)
19:54:28  <kellabyte>but I'm only using http_parser for reading, so isn't it just getting a sequence of requests?
19:57:10  <kellabyte>I guess what my question is, as far as http_parser is concerned, isn't pipelining or keep-alive both a sequence of requests? just one is pausing while one is not
19:57:39  <kellabyte>but does the stream actually change?
19:58:10  <bnoordhuis>do the requests have bodies?
19:58:35  <bnoordhuis>if not, then using the same instance works by accident
20:00:35  <kellabyte>ah, so just to clarify my understanding, one http_parser per request, so on_message_complete is almost when I want to create a new one?
20:00:44  <kellabyte>if I want to support body etc
20:02:00  * c4milo_joined
20:04:11  <bnoordhuis>kellabyte: yeah, but now that i think of it, that's really only an issue when parsing responses (as a client that made pipelined requests)
20:04:25  <bnoordhuis>that is, some servers don't send the responses back in the same order as you requested them
20:04:36  <bnoordhuis>doesn't apply here so never mind i mentioned that
20:05:43  <kellabyte>bnoordhuis: okay, so ignore needing multiple parsers, back to 1 per connection?
20:06:03  <bnoordhuis>yep
20:06:41  <kellabyte>bnoordhuis: ok so now I'm back to confused cuz I dunno what's wrong lol
20:07:04  * mikealjoined
20:07:21  <bnoordhuis>it could be a couple of things
20:07:22  <kellabyte>bnoordhuis: I'm already doing one http_parser per connection but uv_write() seems to be in an endless loop calling the callback
20:07:45  <bnoordhuis>you might be freeing the handle's memory too soon, for instance
20:07:52  <bnoordhuis>or it could be a wrk bug
20:09:10  <kellabyte>the netty folks have been testing pipelining with wrk I believe, so I'm not apt to just blame it so quickly
20:09:33  <kellabyte>the uv_write() endless callback loop doesn't indicate its a reading issue I don't think
20:10:36  <bnoordhuis>what do you see when you attach a debugger?
20:10:50  <bnoordhuis>that should tell you quick enough why it's looping
20:10:53  * loladiroquit (Ping timeout: 240 seconds)
20:11:53  <kellabyte>I'm trying to do that now, the xcode project gyp generates seems to build but doesn't actually run anything lol
20:16:16  <kellabyte>bnoordhuis: btw I believe http pipelining requires responses to be in the order of the requests, I don't think there's any sequence number to know any response from any other so its kinda required I think, if I read things correct
20:19:12  <bnoordhuis>that's correct. that doesn't stop some servers from messing it up though :)
20:19:20  <bnoordhuis>servers/proxies
20:24:43  <kellabyte>bnoordhuis: true, but the parser shouldn't care, it'll just get the wrong one lol
20:24:55  * loladirojoined
20:25:01  <kellabyte>which may mess up the implementation but shouldn't mess up http_parser any I don't think
20:26:26  <kellabyte>starting to think this is a uv_write() misuse on my part somewhere
20:27:58  * jmar777joined
20:39:49  <bnoordhuis>kellabyte: reading your code, i think you're corrupting client->write_req
20:39:54  <bnoordhuis>that is, reusing it before libuv is done with it
20:41:01  <bnoordhuis>when i malloc/free the write req, pipelining works
20:43:34  <kellabyte>bnoordhuis: oh hmm, can you gist what you changed please?
20:45:31  <bnoordhuis>kellabyte: here you go: https://gist.github.com/bnoordhuis/f3dc5a6df6f37b300c5e
20:50:26  * kazuponjoined
20:51:04  <kellabyte>bnoordhuis: no more timeouts or read errors reported in wrk!
20:51:36  <kellabyte>bnoordhuis: so if I was corrupting it, that makes sense why uv_write() was all messed up, I was screwing up its state
20:52:19  <bnoordhuis>yep. it was corrupting the queue it was part of
20:54:56  * kazuponquit (Ping timeout: 246 seconds)
20:56:22  <kellabyte>bnoordhuis: I knew it was my fault, thank you so very much for your time and help :)
20:56:43  <bnoordhuis>no problem :)
20:56:59  <kellabyte>are you @bnoordhuis on twitter? I want to give a shoutout thanks :)
20:58:02  * luigyjoined
20:58:51  <bnoordhuis>kellabyte: i am but i don't use twitter. i only have the account because someone created it for me :/
20:59:14  <kellabyte>lol
20:59:24  <kellabyte>whatever, you're getting the shoutout anyhow :P
21:00:48  * jmar777quit (Remote host closed the connection)
21:01:57  * inolenquit (Read error: Connection reset by peer)
21:02:16  * inolenjoined
21:03:18  <MI6>joyent/node: Ben Noordhuis master * 41b75ca : cluster: clean up lib/cluster.js Clean up and DRY the cluster source cod - http://git.io/uDYs3A
21:03:48  * brsonjoined
21:15:33  <kellabyte>now to re-test on windows!
21:15:48  <kellabyte>amazing how lucky the timing was last week knowing that bug now :P
21:17:06  * inolenquit (Ping timeout: 245 seconds)
21:17:31  * inolenjoined
21:17:51  <wolfeida_>kellabyte: good to see you got it fixed
21:19:20  <kellabyte>wolfeida_: all bnoordhuis, not me :)
21:24:51  <MI6>nodejs-master: #166 UNSTABLE osx-ia32 (1/582) windows-ia32 (8/582) smartos-x64 (2/582) smartos-ia32 (1/582) windows-x64 (8/582) http://jenkins.nodejs.org/job/nodejs-master/166/
21:26:30  * rendarquit
21:39:06  * hzjoined
21:50:59  * kazuponjoined
21:55:54  * kazuponquit (Ping timeout: 264 seconds)
22:03:50  * hzquit
22:22:18  * `3Equit (Remote host closed the connection)
22:28:23  * trevnorrisjoined
22:31:06  * mikealquit (Quit: Leaving.)
22:48:02  * loladiroquit (Quit: loladiro)
22:51:34  * kazuponjoined
22:55:57  * kazuponquit (Ping timeout: 256 seconds)
22:59:05  * loladirojoined
23:09:04  * trevnorrisquit (Quit: Leaving)
23:32:44  * bnoordhuisquit (Ping timeout: 252 seconds)
23:35:19  * isaacs_mobilejoined
23:43:52  * mikealjoined
23:52:06  * kazuponjoined
23:57:06  * kazuponquit (Ping timeout: 264 seconds)
23:58:05  * luxigoquit (Ping timeout: 255 seconds)
23:59:22  * dominictarrquit (Quit: dominictarr)