I'd put that decision on the agenda for the next meeting. I'd also recommend pinging the users's list for feedback... there could be a large number of tomcat 6 people behind firewalls preventing the ping-back... now if they are not engaged with the users list... well let's do all we can to see if we can move forward with this
On 30 May 2014 07:45, Kohsuke Kawaguchi <[email protected]> wrote: > 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. > -- 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.
