[
https://issues.jboss.org/browse/WFLY-4693?page=com.atlassian.jira.plugin....
]
Serge Mürset updated WFLY-4693:
-------------------------------
Workaround Description:
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, 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" />
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.
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 (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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)