-
Improvement
-
Resolution: Fixed
-
Major
-
None
Hudson recently switched to using Jetty as an embedded servlet engine. It has a very small size, and very very good performance.
Put bluntly, the current use of Winstone SUCKS, and due to its threaded design will cause performance to slow to a crawl at 240+ requests a minute even on high end hardware with aggressive varnish caching. At the same time using an external Java EE container isn't that easy, so by following hudson and switching to Jetty we get the best of both worlds.
Thanks
md_5
- depends on
-
JENKINS-20128 HTTP two-way remoting does not work (jenkins-cli.jar without JNLP)
-
- Resolved
-
- is related to
-
JENKINS-20682 Starting Jenkins with defined --webroot or JETTY_HOME not working.
-
- Resolved
-
-
JENKINS-20074 JellyTagException following log message "org.eclipse.jetty.util.log.JavaUtilLog warn"
-
- Resolved
-
[JENKINS-18366] Jetty should be used rather than Winstone for embedded deployments
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Link |
New:
This issue is related to |
Resolution | Original: Fixed [ 1 ] | |
Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Winstone has ceased the development upstream, so we are the one maintaining it. That obviously doesn't make sense.
Another benefit is that this would also allow us to start delivering features that depend on WebSockets, etc.
This work involves writing a new driver code that accepts options that Winstone accepts but instead drive Jetty. For this purpose, I have refactored Winstone to explicitly list up all the options in use.
The general option compatibility is important so as not to disrupt existing deployments, even if we might consciously decide to skip some uncommon options if those are deemed too hard to match.