Tuesday, 2015-01-27

*** fivebats <fivebats!~fivebats@72.52.77.52> has joined #immutant00:37
*** cap10morgan__ <cap10morgan__!~cap10morg@50.153.129.151> has joined #immutant00:58
*** cap10morgan__ <cap10morgan__!~cap10morg@50.153.129.151> has quit IRC (Ping timeout: 244 seconds)01:05
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant01:10
*** fivebats <fivebats!~fivebats@72.52.77.52> has quit IRC (Quit: quit)01:27
*** statonjr <statonjr!~statonjr@cpe-098-024-171-126.carolina.res.rr.com> has quit IRC (Quit: statonjr)01:42
*** jcrossle_ <jcrossle_!~user@71-90-202-246.dhcp.stls.mo.charter.com> has joined #immutant02:34
*** jcrossley3 <jcrossley3!~user@redhat/jboss/jc3> has quit IRC (Read error: Connection reset by peer)02:34
jbossbotgit [immutant] push thedeuce f42862a.. Jim Crossley Added test using Jersey's SSE client lib [IMMUTANT-439]...03:18
jbossbotgit [immutant] push thedeuce URL: http://github.com/immutant/immutant/commit/f42862acd03:18
jbossbotjira [IMMUTANT-439] Provide SSE support in web [Open (Unresolved) Feature Request, Major, Jim Crossley] https://issues.jboss.org/browse/IMMUTANT-43903:18
projectodd-ciProject immutant2-incremental build #442: SUCCESS in 19 min: https://projectodd.ci.cloudbees.com/job/immutant2-incremental/442/03:38
projectodd-ciJim Crossley: Added test using Jersey's SSE client lib [IMMUTANT-439]03:38
jbossbotjira [IMMUTANT-439] Provide SSE support in web [Open (Unresolved) Feature Request, Major, Jim Crossley] https://issues.jboss.org/browse/IMMUTANT-43903:38
*** JulioBarros <JulioBarros!~juliobarr@c-50-186-32-133.hsd1.or.comcast.net> has joined #immutant04:53
*** jcrossle_ is now known as jcrossley3-away05:21
*** _kardan <_kardan!~daniel_ka@c-31-209-39-157.cust.bredband2.com> has joined #immutant06:04
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has joined #immutant06:17
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has quit IRC (Ping timeout: 264 seconds)06:31
*** deadghost <deadghost!~deadghost@2001:41d0:1:b6d8::1> has quit IRC (Ping timeout: 244 seconds)07:22
*** mgoldmann|away is now known as mgoldmann07:27
*** galderz <galderz!galder@redhat/jboss/galderz> has joined #immutant08:09
*** marianoguerra <marianoguerra!~marianogu@p548FD830.dip0.t-ipconnect.de> has joined #immutant08:16
*** marianoguerra <marianoguerra!~marianogu@emesene/grandpa/marianoguerra> has joined #immutant08:16
*** je <je!~je@mail.natur-energi.dk> has joined #immutant08:25
*** dm3 <dm3!~dm3@pub158181119172.dh-hfc.datazug.ch> has joined #immutant08:26
*** jwm <jwm!~jwm@73.168.212.183> has quit IRC (Ping timeout: 272 seconds)08:35
*** jwm <jwm!~jwm@73.168.212.183> has joined #immutant10:01
*** galderz <galderz!galder@redhat/jboss/galderz> has quit IRC (Quit: This computer has gone to sleep)10:50
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has joined #immutant10:56
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant12:07
*** statonjr <statonjr!~statonjr@cpe-098-024-171-126.carolina.res.rr.com> has joined #immutant12:19
*** galderz <galderz!galder@redhat/jboss/galderz> has joined #immutant12:23
*** bbrowning_away is now known as bbrowning12:54
*** galderz <galderz!galder@redhat/jboss/galderz> has quit IRC (Quit: This computer has gone to sleep)12:56
*** jcrossley3-away is now known as jcrossley314:03
*** bobmcw <bobmcw!~bobmcw@71.48.146.62> has joined #immutant14:19
*** bobmcw <bobmcw!~bobmcw@71.48.146.62> has quit IRC (Changing host)14:19
*** bobmcw <bobmcw!~bobmcw@redhat/jboss/bobmcw> has joined #immutant14:19
*** tcrawley-away is now known as tcrawley14:22
jcrossley3tcrawley: i need help with http streams when you get a chance14:24
jcrossley3basically, i need to know whether to expect a client to be able to close one :)14:25
tcrawleyhowdy!14:25
tcrawleya client can close at will, but the server won't know until it tries to send data to the closed channel14:26
tcrawleysince it's one-way, there's no way for the client to signal the server that it should close14:26
jcrossley3that's kinda weird for SSE, because the clients try to reconnect, by default.14:27
tcrawleycan you explain that?14:27
tcrawleydo they try to reconnect automatically when the server closes the connection? or when the client triggers a close?14:28
jcrossley3the former14:28
tcrawleyhow does that relate to the client closing then?14:29
tcrawleyoh, you mean there's no clean way for the client to shut it down?14:29
jcrossley3right14:29
jcrossley3unless both of them close14:29
tcrawleyor just the client closes, and lets the server discover it's gone14:29
jcrossley3if the events the server needs to send are fixed, then the socket will remain open unless both ends close14:30
tcrawleyif the client closes, the next send from the server should close the stream on that side14:31
jcrossley3right, but what if there is no next event?14:31
tcrawleythen on-close won't be triggered on the server, and there isn't much we can do about that14:31
tcrawleyother than a timeout of some sort14:32
jcrossley3is that a limitation of undertow?14:32
tcrawleyit's a limitation of TCP/IP14:32
jcrossley3i guess i can't grok how one end can't close the pipe14:33
jcrossley3but maybe i've never in my whole life used a unidirectional stream :)14:33
tcrawleyI should say it's really a limitation of HTTP, conjoined with TCP14:34
tcrawleysince http has no heartbeat mechanism built in, the only way to know when the client is gone is to try and send data to it14:35
jcrossley3maybe SSE services are usually designed as infinite?14:36
tcrawleyI think it's "as long as the page is there, give me a channel to send data to it"14:37
tcrawleyand if you care about when the client goes away, you send a heartbeat event every x seconds14:37
jcrossley3wfm14:38
tcrawleyone of those will fail and close14:38
tcrawleyjcrossley3: and yeah, I saw the sente email. I really want to get streaming finished :)14:39
tcrawleyI'm working on making send! async for streams now14:39
tcrawleyalmost done with that I hope14:39
tcrawleythen docs14:40
jcrossley3tcrawley: should i expect :on-close to be called when i send! to a channel the client closed?14:49
tcrawleyjcrossley3: yes, that should work14:57
tcrawleyI'm trying to think if we have a test for that14:57
tcrawleywe probably don't14:57
jcrossley3i couldn't find any tests of a stream with an :on-close14:58
jcrossley3but i'm struggling with one RIGHT NOW14:58
jcrossley3things aren't progressing14:59
tcrawleythere's stream-on-close-should-be-invoked-when-closing-on-server-side in integ-test, but that's server-side close, obviously14:59
jcrossley3maybe my problem is that send! is currently synchronous?15:01
jcrossley3would that prevent :on-close from being called?15:01
tcrawleycan you gist your current version?15:01
tcrawleyit shouldn't prevent it, no15:01
jcrossley3https://gist.github.com/a50dfc633fadb94e9f3f15:02
jcrossley3all i did was add an extra send!15:03
jcrossley3line #1015:03
jcrossley3and uncomment #2015:03
tcrawleycan you try sleeping between 9 & 10?15:05
jcrossley3i did :)15:05
jcrossley3MSP can't help us here15:06
tcrawleycan you wrap the body of your on-open in (future )?15:07
jcrossley3sure15:07
jcrossley3same15:08
tcrawleyok, hmm15:08
tcrawleycan you just pend that for now until I get async send working, and we can take another look?15:08
jcrossley3sure15:09
tcrawleydonkey!15:11
*** galderz <galderz!galder@redhat/jboss/galderz> has joined #immutant15:11
projectodd-ciStarting build #1386 for job overlay (previous build: SUCCESS)15:16
projectodd-ciProject overlay build #1386: SUCCESS in 46 sec: https://projectodd.ci.cloudbees.com/job/overlay/1386/15:17
jcrossley3overlay, so cute15:18
tcrawleyheh15:20
*** je <je!~je@mail.natur-energi.dk> has quit IRC (Ping timeout: 252 seconds)15:23
tcrawleyjcrossley3: I have async send! working in utow, and in WF 9.alpha1. It won't work in WF 8.1 or 8.2 due to: https://issues.jboss.org/browse/WFLY-371515:39
jbossbotjira [WFLY-3715] Async servlets cause lock timeouts for distributable sessions [Resolved (Done) Bug, Major, Paul Ferraro] https://issues.jboss.org/browse/WFLY-371515:39
jcrossley3huh15:40
tcrawleyour options are: send! isn't async in WF at all, or it's conditionally async based on the wF version15:40
tcrawleyor we don't support 8.x15:40
jcrossley3i like the latter, um, second one15:40
tcrawleywhat happens is we end up calling asyncContext.complete() on a different thread than where we called start(), and if you're using sessions, you end up not freeing the lock on the session15:41
tcrawleysince it uses a ThreadLocal in 8.x15:42
tcrawleyeven though calling .complete() on another thread is perfectly legal (and kinda the point) for async servlets15:42
tcrawleyI'll see if I can detect the WF version15:43
jcrossley3cool15:45
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)16:01
*** galderz <galderz!galder@redhat/jboss/galderz> has quit IRC (Ping timeout: 252 seconds)16:06
*** GitHub185 <GitHub185!~GitHub185@192.30.252.46> has joined #immutant16:18
GitHub185[wunderboss] tobias pushed 2 new commits to master: http://git.io/Fc3k16:18
GitHub185wunderboss/master 81059bb Toby Crawley: Add a managed thread pool component....16:18
GitHub185wunderboss/master 2729289 Toby Crawley: Make http stream send async in undertow....16:18
*** GitHub185 <GitHub185!~GitHub185@192.30.252.46> has left #immutant16:18
jbossbotTitle: Comparing 9f7e1b72f7f1...27292899c889 · projectodd/wunderboss · GitHub16:18
projectodd-ciProject wunderboss-incremental build #189: SUCCESS in 3 min 3 sec: https://projectodd.ci.cloudbees.com/job/wunderboss-incremental/189/16:21
projectodd-ci* Toby Crawley: Add a managed thread pool component.16:21
projectodd-ci* Toby Crawley: Make http stream send async in undertow.16:21
jbossbotgit [immutant] push thedeuce a387eb1.. Toby Crawley Update to newer wboss that provides async send in undertow [IMMUTANT-521]16:27
jbossbotgit [immutant] push thedeuce URL: http://github.com/immutant/immutant/commit/a387eb18f16:27
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52116:27
tcrawleyjcrossley3: there's async send! in undertow at least ^16:27
jcrossley3so we have our own thread pools now?16:28
tcrawleyyep, since a servlet container doesn't expose one to you16:28
tcrawleywe could get a handle to one, but I didn't want to further tie us to WF16:29
tcrawleywe don't use it when outside the container16:29
jcrossley3seems like we'd want to use the container's when in-container, no?16:29
tcrawleyexcept servlet containers don't expose thread pools to you16:30
jcrossley3i guess i don't understand why we need them exposed16:30
jcrossley33.1 does async, right?16:30
tcrawleyright, and you are responsible for managing a thread pool for your app16:31
jcrossley3is that only in response?16:31
tcrawleyactually, that's not quite true16:31
tcrawleyit does provide a pool you can dispatch to16:31
jcrossley3so 3.1 expects you to BYOTP?16:31
tcrawleybut you have to dispatch to it via the asyncContext, and you don't have access to the pool to do a general execute() call16:32
tcrawleyso if you need direct access to the pool, you BYO16:32
tcrawleylet me take another look though, and see if we can use the AC16:33
projectodd-ciProject immutant2-incremental build #443: SUCCESS in 9 min 49 sec: https://projectodd.ci.cloudbees.com/job/immutant2-incremental/443/16:37
projectodd-ciToby Crawley: Update to newer wboss that provides async send in undertow [IMMUTANT-521]16:37
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52116:37
tcrawleyjcrossley3: hey, with some small changes, we can use the container's pool via the AsyncContext16:43
tcrawleythanks for the prod!16:44
tcrawleythe entry point is AsyncContext.start(Runnable), which, given it's name (and examples I'd seen), I thought you could only call it once16:44
tcrawleybut all it really does is throw the Runnable on the pool's queue, so can be called repeatedly16:45
*** jcrossle_ <jcrossle_!~user@71-90-202-246.dhcp.stls.mo.charter.com> has joined #immutant16:47
jcrossle_tcrawley: this makes me a little nervous http://java.dzone.com/articles/limited-usefulness16:47
jbossbotTitle: The Limited Usefulness of AsyncContext.start() | Javalobby16:47
jcrossle_but mayhap 3.1 and/or undertow mitigate what he describes16:47
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Ping timeout: 246 seconds)16:48
*** jcrossle_ <jcrossle_!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Client Quit)16:48
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has joined #immutant16:48
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Changing host)16:48
*** jcrossley3 <jcrossley3!~user@redhat/jboss/jc3> has joined #immutant16:48
tcrawleyI think we're ok, because we're not doing long-running work on the thread. the runnable just pumps data from a queue to the output stream. all the long-running work is wherever it would normally be, even w/o async send16:53
tcrawleyand I suspect in WF we're using the XNIO worker pool, the same as we get outside16:54
tcrawleyI'm confirming that now16:54
jcrossley3kk!16:54
tcrawleyif we want true async perf, we would want to rewrite it all on top of netty :)16:55
jcrossley3behave now16:59
*** dm3 <dm3!~dm3@pub158181119172.dh-hfc.datazug.ch> has quit IRC (Ping timeout: 252 seconds)17:02
*** lanceball is now known as lance|afk17:24
tcrawleyjcrossley3: does your test now work with async send!?17:44
jcrossley3tcrawley: no17:48
jcrossley3which probably doesn't surprise us given the result after wrapping in a future17:52
tcrawleytru17:52
tcrawleye17:52
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant17:54
jcrossley3fwiw, neither a future nor the MSP help post async-sends either17:56
tcrawleyalright, I'll write a test for a non-sse client closing and see where that gets me17:58
*** jcrossley3 is now known as jcrossley3-away17:59
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)18:45
*** lance|afk is now known as lanceball18:59
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant19:01
*** je <je!~je@x1-6-c0-3f-0e-f8-01-dc.cpe.webspeed.dk> has joined #immutant19:09
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)19:17
*** siksia <siksia!~siksia@unaffiliated/siksia> has joined #immutant19:17
*** siksia <siksia!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)19:20
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant19:20
*** bbrowning is now known as bbrowning_away19:23
*** siksia <siksia!~siksia@unaffiliated/siksia> has joined #immutant19:23
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)19:23
*** siksia <siksia!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)19:26
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant19:26
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant19:45
*** GitHub82 <GitHub82!~GitHub82@192.30.252.40> has joined #immutant19:49
GitHub82[wunderboss] tobias pushed 1 new commit to master: http://git.io/FWZD19:49
GitHub82wunderboss/master 1158fca Toby Crawley: Allow sync sends to HTTP streams for WildFly 9.0.0.Alpha1 and up....19:49
*** GitHub82 <GitHub82!~GitHub82@192.30.252.40> has left #immutant19:49
jbossbotTitle: Allow sync sends to HTTP streams for WildFly 9.0.0.Alpha1 and up. · 1158fca · projectodd/wunderboss · GitHub19:49
*** bbrowning_away is now known as bbrowning19:50
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 244 seconds)19:55
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)19:58
projectodd-ciProject wunderboss-incremental build #190: SUCCESS in 10 min: https://projectodd.ci.cloudbees.com/job/wunderboss-incremental/190/20:00
projectodd-ciToby Crawley: Allow sync sends to HTTP streams for WildFly 9.0.0.Alpha1 and up.20:00
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant20:00
tcrawleyjcrossley3-away: for an HTTP stream in undertow, I can get it to trigger closing when the client goes away20:04
tcrawleyif the client is a browser20:04
tcrawleyI can't replicate that behavior with http-async-client, but closing the client may not close the network connection20:05
jbossbotgit [immutant] push thedeuce 97f6d4f.. Toby Crawley Use wboss that provides async sends for WF 9.0.0.Alpha1 and up [IMMUTANT-521]20:06
jbossbotgit [immutant] push thedeuce URL: http://github.com/immutant/immutant/commit/97f6d4fd720:06
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52120:06
*** gws_ <gws_!~gws@2601:7:680:45b:f66d:4ff:fe04:3329> has joined #immutant20:22
*** borkdude_ <borkdude_!~borkdude@2a02:2308:20:0:216:3eff:fe5f:4c0b> has joined #immutant20:25
projectodd-ciProject immutant2-incremental build #444: SUCCESS in 23 min: https://projectodd.ci.cloudbees.com/job/immutant2-incremental/444/20:31
projectodd-ciToby Crawley: Use wboss that provides async sends for WF 9.0.0.Alpha1 and up [IMMUTANT-521]20:31
jbossbotjira [IMMUTANT-521] Add API for async channels [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/IMMUTANT-52120:31
*** jcrossley3-away is now known as jcrossley320:31
jcrossley3tcrawley: so you see the on-close fire when the client closes from a browser?20:31
jcrossley3i thought i tested that, but maybe not20:31
tcrawleyyep, and by "close" I mean "close the browser tab"20:32
tcrawleyI haven't tried an SEE20:32
tcrawleySSE*20:32
*** gws <gws!~gws@2601:7:680:45b:f66d:4ff:fe04:3329> has quit IRC (*.net *.split)20:32
*** borkdude <borkdude!~borkdude@2a02:2308:20:0:216:3eff:fe5f:4c0b> has quit IRC (*.net *.split)20:32
jcrossley3ah20:33
jcrossley3i was gonna jam one in the feature-demo20:34
jcrossley3see any problem with bumping its dep to latest incremental?20:34
tcrawleynope, go for it20:34
tcrawleyactually, lemme push20:34
jcrossley3kk!20:34
tcrawleyI already bumped it to use async/20:35
tcrawleyfor ws20:35
jcrossley3coolio20:36
tcrawleypushed20:38
*** GitHub21 <GitHub21!~GitHub21@192.30.252.45> has joined #immutant20:38
GitHub21[feature-demo] tobias pushed 1 new commit to master: http://git.io/FWDx20:38
GitHub21feature-demo/master 60a2e23 Toby Crawley: Update for new async stuffs.20:38
*** GitHub21 <GitHub21!~GitHub21@192.30.252.45> has left #immutant20:38
jbossbotTitle: Update for new async stuffs. · 60a2e23 · immutant/feature-demo · GitHub20:38
*** jcrossle_ <jcrossle_!~user@71-90-202-246.dhcp.stls.mo.charter.com> has joined #immutant20:39
tcrawleyjcrossle_: pushed20:39
*** jcrossley3 <jcrossley3!~user@redhat/jboss/jc3> has quit IRC (Ping timeout: 244 seconds)20:40
*** jcrossle_ is now known as jcrossley320:44
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)20:57
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant20:57
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)20:59
jcrossley3tcrawley: style question for you20:59
tcrawleysup?21:00
jcrossley3wouldn't middleware/wrap-websocket look a little less intimidating than as-channel in the demo's web.clj?21:00
tcrawleyI was *just* thinking the same thing, and suspected that's what you were going to bring up :)21:01
jcrossley3:)21:01
tcrawleydo it up, homie21:01
jcrossley3kk!21:01
jcrossley3i do like that it can be used in multiple handlers served by defroutes, but i think it's kinda distracting in that particular case21:02
tcrawleyI agree21:03
jcrossley3weird21:04
tcrawleyindeed21:06
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant21:07
*** je <je!~je@x1-6-c0-3f-0e-f8-01-dc.cpe.webspeed.dk> has quit IRC (Quit: Leaving)21:11
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)21:23
*** siksia <siksia!~siksia@unaffiliated/siksia> has joined #immutant21:23
*** bbrowning is now known as bbrowning_away21:24
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has joined #immutant21:27
*** qwerty_nor <qwerty_nor!~Thunderbi@5.248.107.224> has quit IRC (Ping timeout: 276 seconds)21:30
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Remote host closed the connection)21:33
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant21:34
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Ping timeout: 255 seconds)21:38
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has joined #immutant21:43
*** dm3 <dm3!~dm3@pub158181107115.dh-hfc.datazug.ch> has quit IRC (Remote host closed the connection)21:46
*** tcrawley is now known as tcrawley-away21:47
*** siksia <siksia!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)21:48
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant21:49
*** jcrossley3 <jcrossley3!~user@71-90-202-246.dhcp.stls.mo.charter.com> has quit IRC (Read error: Connection reset by peer)21:56
*** _kardan <_kardan!~daniel_ka@c-31-209-39-157.cust.bredband2.com> has quit IRC (Quit: ["Textual IRC Client: www.textualapp.com"])21:58
*** gws_ is now known as gws22:02
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)22:04
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant22:06
*** cemerick <cemerick!~cemerick@c-24-34-140-98.hsd1.ma.comcast.net> has quit IRC (Ping timeout: 245 seconds)22:08
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Read error: Connection reset by peer)22:17
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant22:21
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has quit IRC (Quit: BYE)22:52
*** jbossbot <jbossbot!~JBossBot@redhat/jbossbot> has quit IRC (Quit: jbossbot)22:54
*** audaxion <audaxion!~siksia@unaffiliated/siksia> has joined #immutant23:06
*** jbossbot <jbossbot!~JBossBot@redhat/jbossbot> has joined #immutant23:14
*** GitHub162 <GitHub162!~GitHub162@192.30.252.46> has joined #immutant23:44
GitHub162[feature-demo] jcrossley3 pushed 1 new commit to master: http://git.io/F8Ie23:44
GitHub162feature-demo/master 84a821b Jim Crossley: Introduce an SSE example23:44
*** GitHub162 <GitHub162!~GitHub162@192.30.252.46> has left #immutant23:44
jbossbotTitle: Introduce an SSE example · 84a821b · immutant/feature-demo · GitHub23:44
*** jcrossley3 <jcrossley3!~user@redhat/jboss/jc3> has joined #immutant23:44
jcrossley3tcrawley-away: there's a comment in web.clj describing the race condition that can (and usually does) occur when the server closes the channel before the client does. in that case, the client will reconnect after waiting a few seconds.23:48
jcrossley3weirdly, i seem to see more :on-close calls on the server than i see reconnect attempts on the client. i'm not sure why.23:49
jcrossley3eventually, the client will win and close its EventSource before the server closes the channel, and things settle down. give it a try!23:49
jcrossley3you may have to click the Start button a few times to see it23:50
jcrossley3i see the same behavior with FF and chrome23:54

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!