[jboss-jira] [JBoss JIRA] (WFLY-4693) Slow HTTPS Upload provokes High CPU Load

[Serge Mürset (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Serge Mürset updated WFLY-4693:
-------------------------------
               Description: 
This issue is a reopen of https://issues.jboss.org/browse/UNDERTOW-345.

This Issue is not fixed with Wildfly 9.0 CR1 when using the standard config without any timeouts set (however, above mentioned ticket indicates issue was fixed in Undertow 1.2.0.Beta6). 

This is a major bug, as just one client with bad connectivity will cause a 100% CPU Load on Wildfly whilst the HTTPS upload is being read. It's also a real-world bug, as every note-worthy productive server will have at least one client with bad connectivity at any given time. Duration of the high CPU load directly correlates to the duration it takes the client to send all his POST data.

  was:
This issue is a reopen of https://issues.jboss.org/browse/UNDERTOW-345.

This Issue is not fixed with Wildfly 9.0 CR1 (contrary to what was indicated in above mentioned ticket). Issue is fixed when XNIO trunk (https://github.com/xnio/xnio)  is built and replaces XNIO 3.3.1 module.

This is a major bug, as just one client with bad connectivity will cause a 100% CPU Load on Wildfly whilst the HTTPS upload is being read. It's also a real-world bug, as every note-worthy productive server will have at least one client with bad connectivity at any given time. Duration of the high CPU load directly correlates to the duration it takes the client to send all his POST data.

    Workaround Description: 
This is the recommended solution for people looking to fix the CPU problem. Just set the read-timeout in standalone.xml, and High CPU Load is gone (even if the client sends all bytes within the timeout).
<https-listener name="https" socket-binding="https" security-realm="UndertowRealm" read-timeout="20000" />

Issue can be fixed when XNIO trunk (https://github.com/xnio/xnio)  is built and replaces XNIO 3.3.1 module in Wildfly. It's not clear however how stable this snapshot is.

  was:
Issue is fixed when XNIO trunk (https://github.com/xnio/xnio)  is built and replaces XNIO 3.3.1 module. It's not clear however how stable this snapshot is.

This is the recommended solution for people looking to fix the CPU problem. Just set the read-timeout in standalone.xml, and High CPU Load is gone (even if the client sends all bytes within the timeout).
<https-listener name="https" socket-binding="https" security-realm="UndertowRealm" read-timeout="20000" />



> Slow HTTPS Upload provokes High CPU Load
> ----------------------------------------
>
>                 Key: WFLY-4693
>                 URL: https://issues.jboss.org/browse/WFLY-4693
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.0.CR1
>            Reporter: Serge Mürset
>            Assignee: Stuart Douglas
>              Labels: undertow, web
>
> This issue is a reopen of https://issues.jboss.org/browse/UNDERTOW-345.
> This Issue is not fixed with Wildfly 9.0 CR1 when using the standard config without any timeouts set (however, above mentioned ticket indicates issue was fixed in Undertow 1.2.0.Beta6). 
> This is a major bug, as just one client with bad connectivity will cause a 100% CPU Load on Wildfly whilst the HTTPS upload is being read. It's also a real-world bug, as every note-worthy productive server will have at least one client with bad connectivity at any given time. Duration of the high CPU load directly correlates to the duration it takes the client to send all his POST data.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)