[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] Hudson shutdown wait from hell
- From: Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
- Date: Fri, 10 Feb 2012 08:19:58 -0600
- Delivered-to: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=l78oKlpRDsCTCLhmZtwcOAhId6pyGwEjaCc2MdCWFdM=; b=mZBUOnnGtJt/fIqOasthf21fxBGoArwD/WfNnXqPOf6tKhzBjurjbQCgsjafB+0LIe W16qpuy9P/B+o7JZjepsPR5rHY0FO/sYLibCaDJQKYCre6pTUped/d8p3avqnERTz6q4 J9z9II/Fh8UtdRhPHb8EIa05daSZ/YrdZlHZI=
a new mailing list for hudson build issues?
it could be processed by a script even, after 5 distinct messages from
different addresses it could trigger the restart itself and free up
the webmasters time!
On Fri, Feb 10, 2012 at 08:14, Campo, Christian
> I am personally very much in favor of having a new mailing list for hudson
> build infrastructure messages. Many issues like slaves hanging, hudson is
> restarted are short-lived issues that are not always worth a bugzilla
> entry. Also cross project list gets really a lot of traffic from hudson
> issues currently which maybe is not interesting to people who dont build
> I am sure also some messages get lost because not cross project mails dont
> have a high priority for everyone. And they could reduce the redundant
> traffic on all the other channels that Denis mentioned.
> It shouldnt make bugzilla redundant but it could be used for every message
> about hudson that we otherwise post to cross-projectÅ.
> just a thought
> Am 08.02.12 20:49 schrieb "David M Williams" unter
>>I'd agree with this general idea ... perhaps a general notice go out on a
>>mailing list "hudson is being shutdown and restarted ... any jobs not done
>>by +1 hour [or something] will be killed". (I'm proud to say I cancelled
>>one of my running aggregator jobs when I saw it was about to be shutdown,
>>saving 50 minutes or so (if I was only job running) .... partially because
>>I knew it needed to run again anyway.
>>But, now I am panicking ... seeing 30 jobs stacked up in queue! I suggest
>>anyone that has a non-essential job running or queued up consider
>>it until Hudson "stabilizes" and then run your nightlies, etc. I looks
>>the number of threads (executors) has been reduced again (understandably).
>>But, who knows, maybe it will clear itself up in an hour or two? In time
>>for our RC3 deadline?
>>In general, I'll say there's been very little communication about the
>>of Hudson .... seems several comments made or questions asked on this list
>>with no response ... Hudson restarted, configuration changes all without
>>comment. Is there some resistance to that? Everyone too busy to
>>communicate? Is their a better channel? Hudson bug list? Do we need a
>>"hudson-and-infrastructure" mailing list? Just asking.
>>The queue is down to 26 now ... in the 10 minutes I took to write this
>>note ... if that rate holds, it will be clear in 90 minutes or so? :/
>>From: ÂMiles Parker <milesparker@xxxxxxxxx>
>>To: Â ÂCross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
>>Date: Â02/08/2012 02:22 PM
>>Subject: Â Â Â [cross-project-issues-dev] Hudson shutdown wait from hell
>>Sent by: Â Â Â cross-project-issues-dev-bounces@xxxxxxxxxxx
>>I wanted to bring up a Hudson annoyance and see if people had ideas for
>>improving this. What's happening now is that any time Hudson gets sent a
>>shutdown, everyone is locked out until the last job in queue finishes.
>>Which is a) Good news for the people with running builds, b) Bad news for
>>everyone else. Observing that most of the time most of us are Âin category
>>b) I vote for making things work better for group b). Nothing against
>>PTP :D, but they happen to be in group a) this time around and the last
>>took 22 hours. :O But there are lot's of long builds out there. This means
>>that snapshots are delayed for everyone.
>>So I'm wondering if it might be possible to have some kind of policy where
>>builds are terminated with prejudice under shutdown. I'm not sure if a)
>>this is even supportable OOTB in Hudson, and b) whether that would have
>>possibility of FUBAR'ing anyone project builds. As project builds should
>>not be relying on previous state, I would say that the answer to b is
>>probably no. I also imagine allowance should be made for key builds such
>>aggregator. IIRC in the past when in release panic mode we were triggering
>>hard shutdowns from time to time.
>>cross-project-issues-dev mailing list
>>cross-project-issues-dev mailing list
> compeople AG
> Untermainanlage 8
> 60329 Frankfurt/Main
> fon: +49 (0) 69 / 27 22 18 0
> fax: +49 (0) 69 / 27 22 18 22
> web: http://www.compeople.de/
> Vorstand: JÃrgen Wiesmaier
> Aufsichtsratsvorsitzender: Christian Glanz
> Sitz der Gesellschaft: Frankfurt/Main
> Handelsregister Frankfurt HRB 56759
> USt-IdNr. DE207665352
> cross-project-issues-dev mailing list