I was using immutant.web.async/as-channel to free up workers early for longer http requests, like this:

(let [f (future (expensive-response))]
  (async/as-channel
    {:on-open (fn [ch] (async/send! ch @f {:close? true}))}))

In immutant 2.1.6, this works, but in 2.1.7 and 2.1.9 this doesn't. After enough requests (= to number of workers, approx 4) all future requests hang

It's as if those channels are not closing. But I did look in a debugger and observe UndertowHttpChannel.send(message, shouldClose, onComplete) called with message = bytes[] and shouldClose=true.

Help?

@favila sorry you're having trouble. if it worked in 2.1.6, then I expect we introduced a regression with the fixes for either IMMUTANT-627, IMMUTANT-630, or IMMUTANT-632

you might try overriding your undertow dep[s] to 1.3.23.Final to rule out 627

@jcrossley3 thanks investigating. So newer immutant should work with older 1.3.x series undertow?

(I will need 1.4.19 for UNDERTOW-1139 eventually, but I could at least isolate whether undertow or immutant is reponsible)

@favila yes, it should work. and that would be great if you could confirm 627 introduced the regression.

i say should, but who knows 🙂

@jcrossley3 This works:

[org.immutant/web "2.1.9"
                  :exclusions [io.undertow/undertow-core io.undertow/undertow-servlet io.undertow/undertow-websockets-jsr ]
                  ]
                 [io.undertow/undertow-core "1.3.23.Final"]
                 [io.undertow/undertow-servlet "1.3.23.Final"]
                 [io.undertow/undertow-websockets-jsr "1.3.23.Final"]

(i.e. depending on 1.3.23.Final)

so something about 1.4.x, or the interaction between UndertowHttpChannel and 1.4.x, causes this

@jcrossley3 1.3.30.Final also works (latest stable on 1.3.x I believe)

I can't manage to make a minimal though