Fork me on GitHub
#immutant
<
2017-07-20
>
jcrossley313:07:53

thanks for confirming that @favila

jcrossley313:07:35

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

jcrossley313:07:04

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

favila13:07:24

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

jcrossley313:07:57

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

favila13:07:07

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

favila13:07:22

Sorry, in undertow

jcrossley313:07:41

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

favila13:07:45

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

favila13:07:33

I'll see if thread dumps tell me anything

favila17:07:32

Ah, I reproduced it!

favila17:07:40

Give me a few min to clean it up

favila17:07:30

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

favila17:07:58

maybe I need to close the body? will try that

favila17:07:48

ok that seems to be the issue

favila17:07:11

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

favila17:07:23

I don't know if it's intentional

jcrossley318:07:23

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

favila18:07:03

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

favila18:07:08

Thanks for your help!

jcrossley318:07:16

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

favila18:07:28

I will do that

jcrossley318:07:37

thanks again!

favila18:07:44

is this a bug? regression?

favila18:07:52

now that I know the problem I'm not sure

favila18:07:29

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

jcrossley318:07:38

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

tcrawley18:07:52

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

tcrawley18:07:02

oh, wait, this is the request body

favila18:07:37

so I send! response and close? = true

favila18:07:57

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

tcrawley18:07:09

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

favila18:07:12

looks like stalled connection

jcrossley318:07:12

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

tcrawley18:07:38

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

jcrossley318:07:02

i guess it should be possible to confirm that