The Hudson UI had been very responsive
since these changes were made. I haven't seen any network timeouts
either when trying to contact slaves. Kudos to all those involved
in making these improvements. Much appreciated!
Let me clarify, what I meant by "bundled"
(I think the correct word is
embedded) and "standalone". You can use the hudson.war
Just run the war as a regular executable jar using java -jar hudson.war.
In this case it uses the jetty jars bundled with in the war and starts
an embedded jetty which in turn uses the hudson.war itself
Server server = new Server();
URL warUrl = protectionDomain.getCodeSource().getLocation();
WebAppContext context = new WebAppContext();
Other way (which Matt is doing now), drop the war file in a "webapps"
folder of a normal Jetty distribution.
Wondering if there is any performance difference between the above two.
On 2/28/12 12:16 PM, Jesse McConnell wrote:
> not sure what is meant by 'bundled' vs 'standalone' really
> maybe osgi vs normal distribution? or embedded vs normal distribution?
> in those cases there shouldn't be any real default difference, osgi
> has its natural bit of classloader muckity muck muck but in terms
> processing of a request from start to finish...not that I know of.
> more info on what is meant by 'bundled' vs 'standalone' would help
> clarify that though
> jesse mcconnell
> On Tue, Feb 28, 2012 at 14:08, Winston Prakash
> <winston.prakash@xxxxxxxxx> wrote:
>> On 2/28/12 11:42 AM, Webmaster(Matt Ward) wrote:
>>> Hi Folks,
>>> I know it's short notice but as it's quiet for Hudson
this week I'm going
>>> to move us off the Winstone servlet and onto Jetty. I've
>>> ready to go so at 4pm I'll shut Hudson down and then startup
>>> instance. I expect we'll be offline for about 10 minutes.
>> Nice. Good news is, for Hudson 3.0.0 we don't have to do this,
>> replaced Winstone with Jetty as a bundled server.
>> I'm interested to know, from Jetty folks, if there is a difference
>> Jetty bundled server and Standlone server in terms of performance.
>> - Winston
>> cross-project-issues-dev mailing list
> cross-project-issues-dev mailing list
cross-project-issues-dev mailing list