immutant 2017-07-20

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?

Sorry, in undertow

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

I'll see if thread dumps tell me anything

Ah, I reproduced it!

Give me a few min to clean it up

ok, the essential elements are 1) reuse the connection 2) request has a non-empty body

maybe I need to close the body? will try that

ok that seems to be the issue

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

I don't know if it's intentional

@favila this is a huge help, thanks! i'll try to look at it over the weekend.

It's no longer a blocker for me: I will just ensure all request bodies are closed

Thanks for your help!

@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/

I will do that

is this a bug? regression?

now that I know the problem I'm not sure

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

oh, wait, this is the request body

so I send! response and close? = true

but request body was still open, so next request on same connection isn't processed

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

looks like stalled connection

@tcrawley how does that reconcile that it works on 1.3 undertow?

I would say either 1.3 closed it, or didn't care if it was left open

i guess it should be possible to confirm that