[undertow-dev] UT005085 connection was not closed cleanly, forcibly closing connection

[Stuart Douglas]

Should be fixed in 1.4.17.Final

Stuart

On Mon, Jun 19, 2017 at 7:18 PM, Christoph Sturm <me at christophsturm.com> wrote:
> Hello Stuart!
>
> the handler that generates this does not do anything special. It does some processing and then it calls endExchange without writing a response.
>
> it also also does not set any special headers.
>
> we do register our own conduits but in a separate xnio server where we listen on a raw socket but thats probably not related.
>
> thanks
>  chris
>
>
>> On 15 Jun 2017, at 03:04, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> I had a quick look into this, and I can't really see how this could be
>> generated. Is your application registering its own conduits by any
>> chance?
>>
>> The other thing that seems a bit odd is that the connection is being
>> closed, which is not the default. Are you explicitly setting the close
>> header?
>>
>> Stuart
>>
>> On Wed, Jun 14, 2017 at 9:13 AM, Christoph Sturm <me at christophsturm.com> wrote:
>>> this was with the latest version built from the 1.4.x branch.
>>>> On 14 Jun 2017, at 02:11, Stuart Douglas <sdouglas at redhat.com> wrote:
>>>>
>>>> Which version of Undertow? There was a recent bug that could
>>>> potentially cause this (UNDERTOW-1068) , that should be fixed in the
>>>> 1.4.16.Final release.
>>>>
>>>> Stuart
>>>>
>>>> On Mon, Jun 12, 2017 at 6:37 PM, Christoph Sturm <me at christophsturm.com> wrote:
>>>>> hello undertow developers!
>>>>>
>>>>> We see this exception
>>>>>
>>>>> UT005085: Connection io.undertow.server.protocol.http.HttpServerConnection at 7ba04d76 for exchange HttpServerExchange{ POST /pixel ….. response {Connection=[close], Content-Length=[0], Date=[Mon, 12 Jun 2017 16:31:06 GMT]}} was not closed cleanly, forcibly closing connection
>>>>>
>>>>> in our log files, and looking at the undertow source that should never happen. is this something related to our code or is it just some strange behaviour from the client?
>>>>> if it’s something that we cannot fix, maybe it can be logged by the io logger instead to so we can turn it off easily?
>>>>>
>>>>> or is there a jboss-logging way to disable logging for a single error code?
>>>>>
>>>>> thanks
>>>>> chris
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>