immutant

http://immutant.org Note: dev discussion happens in #immutant on FreeNode IRC.
2017-07-20T13:03:53.487352Z

thanks for confirming that @favila

2017-07-20T13:04:35.507461Z

i'm glad it's not something we did, but sad it's upstream 🙂

2017-07-20T13:05:04.522327Z

will that workaround keep you afloat until i can get around to looking at those upstream changes?

favila 2017-07-20T13:05:24.531677Z

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

2017-07-20T13:05:40.539637Z

huh

2017-07-20T13:06:57.576849Z

i wonder if 1.3.30 includes the fix that triggered us to update

favila 2017-07-20T13:07:07.581681Z

Do you happen to know how the channel ultimately communicates its closed state to whatever schedules them in immutant?

favila 2017-07-20T13:07:22.588510Z

Sorry, in undertow

2017-07-20T13:07:41.597585Z

i'm not sure, no. i'd have to refresh my memory on that code.

favila 2017-07-20T13:08:45.628332Z

Ok. That was As far as I could get in my tracing. I know for sure the channel gets closed

favila 2017-07-20T13:09:33.650741Z

I'll see if thread dumps tell me anything

favila 2017-07-20T17:03:32.187697Z

Ah, I reproduced it!

favila 2017-07-20T17:03:40.192542Z

Give me a few min to clean it up

favila 2017-07-20T17:07:30.325367Z

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

favila 2017-07-20T17:08:58.374297Z

maybe I need to close the body? will try that

favila 2017-07-20T17:28:48.045158Z

ok that seems to be the issue

favila 2017-07-20T17:37:11.334336Z

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 2017-07-20T17:37:23.341351Z

I don't know if it's intentional

2017-07-20T18:35:23.340259Z

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

favila 2017-07-20T18:36:03.363636Z

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

favila 2017-07-20T18:36:08.366394Z

Thanks for your help!

2017-07-20T18:38:16.438679Z

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

2017-07-20T18:38:27.445294Z

no hurry

favila 2017-07-20T18:38:28.445800Z

I will do that

2017-07-20T18:38:37.450583Z

thanks again!

favila 2017-07-20T18:38:44.454962Z

is this a bug? regression?

favila 2017-07-20T18:38:52.459077Z

now that I know the problem I'm not sure

favila 2017-07-20T18:39:29.481222Z

not closing the response body doesn't seem necessary (unless I am missing something), but it is certainly sloppy

2017-07-20T18:39:38.486099Z

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

favila 2017-07-20T18:39:44.490Z

ok

2017-07-20T18:40:52.528753Z

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

2017-07-20T18:41:02.535159Z

oh, wait, this is the request body

favila 2017-07-20T18:41:06.537469Z

yes

favila 2017-07-20T18:41:37.554702Z

so I send! response and close? = true

favila 2017-07-20T18:41:57.566460Z

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

2017-07-20T18:42:09.572450Z

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

favila 2017-07-20T18:42:12.574227Z

looks like stalled connection

2017-07-20T18:43:12.608332Z

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

2017-07-20T18:43:38.622909Z

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

2017-07-20T18:44:02.636171Z

i guess it should be possible to confirm that

2017-07-20T18:44:19.645872Z

mayhap

favila 2017-07-20T19:22:38.923058Z

https://issues.jboss.org/browse/IMMUTANT-634