I implemented all basic options, which are in --help
Not supported options are these:
--httpDoHostnameLookups, httpsDoHostnameLookups,
handlerCountStartup, logThrowingLineNo - these are not supported in
Winstone 2.0
--webappsDir, hostsDir - because only one instance of Jenkins can
run in container
--handlerCountMaxIdle - not using own ExecutorService
--debug, logThrowingLineNo
--spdy - not currently supported in Undertow, but it will be in
next release, which is in version beta
--httpKeepAliveTimeout, httpsKeepAliveTimeout - currently used for
the whole container (cannot be set separately)
As you said, it runs on Java SE 6.
Undertow currently does not support loading of web.xml automatically (in
one function call as Jetty). I implemented
own parser, which support all tags used in Jenkins, but it does not
support all tags in servlet specification. BUT it is designed
to be easily extended.
On 06/04/2014 11:50 PM, Kohsuke Kawaguchi wrote:
If it's faster and smaller, it seems to me that this should be
something we should work toward integrating.
How complete is this in terms of the command line option compatibility?
I also notice that Undertow implements Servlet 3.1 but without
requiring Java SE 7. That's great, except I wonder if it's violation
of the servlet spec which would probably demand SE 7 as the minimum?
Anyone else cares to make a pitch on why we should prefer this over
the current Jetty-based one?
On 06/04/2014 12:49 PM, Jesse Glick wrote:
On Wed, Jun 4, 2014 at 10:31 AM, Jakub Bartecek <[email protected]>
wrote:
https://github.com/jbartece/undertow4jenkins
Interesting work indeed. I guess section 2.6.3 of
https://github.com/jbartece/undertow4jenkins/blob/master/thesis/tex/projekt.pdf?raw=true
about comparison with Jetty is the crucial thing to explore, if we are
to move off of a familiar and battle-tested container.
Runtime responsiveness is definitely of interest; it sounds like the
improvements could be on the order of a few percent, which matters. Is
the measured speedup mostly related to serving static resources, or
better general stream handling, or something else?
Startup time of the servlet container is probably negligible compared
to that of Jenkins core. You suggested that startup time might be
significant in the context of Jenkins’ hour-long integration tests,
but I doubt it is a major contributor, certainly not 50%; would be
happy to be proven wrong. (By the way replacing the bundled container
has no effect on the web container used by integration tests; this is
hardcoded to be Jetty, in JenkinsRule/HudsonTestCase. Acceptance tests
using the default “Winstone” controller run Jenkins as a JAR and so
would use the currently bundled container; these also make actual HTTP
requests heavily, whereas integration tests only occasionally do so,
and so could really be affected by the choice of container.)
2% reduction in application size would be nice, though not a prime
consideration.
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
