[
https://issues.jboss.org/browse/WFLY-4693?page=com.atlassian.jira.plugin....
]
Serge Mürset updated WFLY-4693:
-------------------------------
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" />
was:
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.
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)