To use any of those async servlet features, we need Servlet 3.0, but it turns out that the servlet spec has designed this feature in such a way that webapp would have to opt into this support through web.xml.
Unfortunately, what this means is that if we want to start using servlet 3.0 functionality, we'd have to leave behind people who are running earlier versions of the container. There's no graceful fallback that works with servlet 2.5 containers. Now, servlet 3.0 came out in 2009, and in 1.535 Jenkins moved to Jetty-8 based Winstone 2.x that supports servlet 3.0, so we'd think good portion of the user base is already running on compatible servlet container. But I decided to look into this anyway. Many users run Jenkins through "java -jar jenkins.war", we expect that users of more recent Jenkins versions will likely run servlet 3 compatible container. When I look at people who are running >=1.509 and later, 70% of them run on servlet 3 compatible container. The number for >=1.532 is 84%, then for >=1.554 it's 94%. When I look at which container is dragging us down as of >= 1.554, you see that there's a sizable Tomcat6 deployments (2.5%). If we start requiring Servlet 3.0 these people will be in a nasty surprise. Then there's about 1.8% who claims to be running on Winstone 0.9.10, which is really puzzling, but I'm assuming these people are getting OEM-ed Jenkins of a sort (multiple large companies are known to do this), so these people will likely be able to update to Winstone 2.x automatically by virtue of getting a new jenkins.war from their upstream. So all in all I'd say if we start requiring Servlet 3.0 today, there'll be about 3% user base who will be impacted, which IMHO is acceptable loss to move forward. The results are in https://docs.google.com/spreadsheets/d/14YzFgKBB6BvbRU_1OjChC3efECWPs77TEGTU09t3KGw/edit#gid=873989456 Note that the spreadsheet only lists 20 or so most common containers. The total number does include the entire long tail (which amounts to less than 1%), so the estimate errs on the slightly conservative side. 2014-05-29 19:48 GMT-07:00 Kohsuke Kawaguchi <[email protected]>: > > Perhaps I should have mentioned it more explicitly, but I was only > thinking about using it to do updates after the initial page load, with > most of the server-side initial HTML rendering intact. > > So when WebSocket/SSE/etc does not work, all you lose is the dynamic > update, which I think is acceptable loss. > > > > On 05/29/2014 02:01 AM, teilo wrote: > >> Just so people are aware IE has no support for SSE[1]. >> >> IE is still commonly used in enterprises despite it many and continuous >> flaws. >> >> So far Jenkins has been pretty browser agnostic. >> >> /James >> >> [1] http://status.modern.ie/serversenteventseventsource >> >> On Thursday, 29 May 2014 08:26:38 UTC+1, Tom Fennelly wrote: >> >> >> On 29/05/2014 02:57, Michael Neale wrote: >> >>> >>> On Thu, May 29, 2014 at 11:33 AM, Christopher Orr <[email protected] >>> <javascript:>> wrote: >>> >>> >>> It may also be worth considering Server Sent Events — >>> basically one-way "push" from the server, without all the >>> handshaking and protocol upgrade fun of WebSockets. Could be >>> useful if clients are just listening for server updates, >>> without sending anything (as is generally the case today). >>> >>> Last week I wrote a quick experimental plugin to stream log >>> events as they happen via SSE to remote JavaScript clients for >>> any running build; I was surprised how simple it was to build.. >>> >>> (Though I just noticed that it has less support than >>> WebSockets (thanks, Microsoft): http://caniuse.com/eventsource) >>> >>> Chris >>> >>> >>> >>> >>> +1 on SSE. I have a fair bit of experience with websockets on >>> servers - enough to know that almost no one gets their proxies >>> right - and it is a source of complaints. SSE seems to work better >>> out of the box, alternatively long polling/comet can also work (a >>> given jenkins master doesn't have to scale to 10s of thousands >>> concurrent users, which is the assumption for a lot of other web >>> choices). >>> >>> Having said that, nearly halfway through 2014 websockets is >>> probably not a controversial choice and does open up a lot of >>> other options. If someone is accessing their jenkins via a proxy, >>> ssl and careful configuration is required to support http upgrade >>> and not break websocket too. >>> >> AFAIK... any proxy/gateway between the websocket client and server >> needs to be pretty much websocket aware. SSE would seem like a >> perfect fit for Jenkins since the client is listening only (not >> sending back to the server - could implement that on top anyway if >> needed). As far as I know SSE is a fancy long poll/comet style >> protocol and so would require the same considerations re number of >> concurrent users. >> >> -- >> 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] >> <mailto:[email protected]>. >> >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ > Try Jenkins Enterprise, our professional version of Jenkins > -- Kohsuke Kawaguchi -- 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.
