This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-20
Channels
- # aleph (4)
- # beginners (47)
- # boot (22)
- # cider (7)
- # clara (1)
- # cljs-dev (8)
- # cljsrn (21)
- # clojure (180)
- # clojure-argentina (13)
- # clojure-gamedev (1)
- # clojure-italy (5)
- # clojure-poland (4)
- # clojure-russia (17)
- # clojure-spec (19)
- # clojure-uk (33)
- # clojurescript (107)
- # cursive (61)
- # data-science (1)
- # datomic (7)
- # emacs (69)
- # euroclojure (1)
- # graphql (1)
- # hoplon (11)
- # immutant (43)
- # jobs (1)
- # leiningen (3)
- # off-topic (5)
- # om (10)
- # onyx (2)
- # parinfer (52)
- # pedestal (11)
- # re-frame (31)
- # reagent (23)
- # ring-swagger (3)
- # schema (2)
- # specter (7)
- # unrepl (9)
thanks for confirming that @favila
i'm glad it's not something we did, but sad it's upstream 🙂
will that workaround keep you afloat until i can get around to looking at those upstream changes?
I'm going to try harder today to see what is wrong. Unfortunately I wasn't able to reproduce with a new project with minimal handler
i wonder if 1.3.30 includes the fix that triggered us to update
Do you happen to know how the channel ultimately communicates its closed state to whatever schedules them in immutant?
i'm not sure, no. i'd have to refresh my memory on that code.
Ok. That was As far as I could get in my tracing. I know for sure the channel gets closed
ok, the essential elements are 1) reuse the connection 2) request has a non-empty body
So, the request will not finish (channel will not be closed) until the originating request's body is closed. This is a difference between 1.3.x and 1.4.x
@favila this is a huge help, thanks! i'll try to look at it over the weekend.
@favila can i trouble you to create an issue to capture what you found, including your expectations, workaround and the gist? https://issues.jboss.org/projects/IMMUTANT/
no hurry
thanks again!
not closing the response body doesn't seem necessary (unless I am missing something), but it is certainly sloppy
call it a bug. none of the categories are significant. we can re-categorize later. just want to get the essential info in one place
I thought we closed bodies at one point, but I may be thinking of !async, just ring bodies. I think send!
should close a closable body when it is done
I think it would be reasonable for immutant to try to close that for you, especially if this happens when you never even try to read the body
@tcrawley how does that reconcile that it works on 1.3 undertow?
i guess it should be possible to confirm that