On 05/30/2014 12:46 AM, Stephen Connolly wrote:
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
I posted http://jenkins-ci.org/content/thinking-about-moving-servlet-30
and created https://issues.jenkins-ci.org/browse/JENKINS-23378 to
solicit feedbacks.
Let's see how it goes.
On 30 May 2014 07:45, Kohsuke Kawaguchi <[email protected]
<mailto:[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] <mailto:[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
<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] <mailto:[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 jenkinsci-dev+unsubscribe@__googlegroups.com
<mailto:jenkinsci-dev%[email protected]>
<mailto:[email protected]
<mailto:jenkinsci-dev%[email protected]>>.
For more options, visit https://groups.google.com/d/__optout
<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]
<mailto:[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]
<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
--
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.
