Eclipse Community Forums: Hudson » hudson reloading configuration

Help

Home

Home » Archived » Hudson » hudson reloading configuration

Show: Today's Messages :: Show Polls :: Message Navigator

hudson reloading configuration [message #1034358]

Fri, 05 April 2013 10:43

Ireneusz Grala

Messages: 10
Registered: March 2013

Junior Member

Hello.
The problem with reloading configuration is that it stops all executing jobs without any notification. When You accidentally reload config all jobs are stopped and there's no information which where running.

Solution 1
Hudson should check if any job is running and inform about it

Solution 2
Hudson should rerun jobs after reloading configuration.

Best regards

Irek

Report message to a moderator

Re: hudson reloading configuration [message #1038270 is a reply to message #1034358]

Wed, 10 April 2013 16:49

Christian Schulz

Messages: 25
Registered: March 2013

Junior Member

In general I would prefer the first solution similar to the shutdown functionality.
Perhaps additional you can add a checkbox, which allows to kill all running jobs.

Report message to a moderator

Re: hudson reloading configuration [message #1039528 is a reply to message #1038270]

Fri, 12 April 2013 09:02

k z

Messages: 71
Registered: October 2012

Member

Solution 1 is the only way to go. Ongoing jobs should be aborted before restart and user should confim that. CUrrently they are lost.

Report message to a moderator

Re: hudson reloading configuration [message #1039558 is a reply to message #1039528]

Fri, 12 April 2013 09:45

Steve Christou

Messages: 125
Registered: June 2012
Location: Milwaukee, Wisconsin

Senior Member

Take a look at bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=382446.

If you ask me, reloading configurations should not stop the build and should remember what builds were being executed or currently being executed. I believe hudson works in that all the job configurations are loaded into memory and pushed to the config.xml file and loaded back into memory when you press the reload configurations from disk.

My $0.02 would be to remove that option completely and just load the configuration always from disk. You will take a small performance hit because you're loading from disk a lot(every time you load the job configuration page and every time a job runs), but can always get a fresh copy of the configuration page even if you modify the config.xml file directly, you can decrease the memory footprint by not saving configuration files in memory if there are a few hundred(thousand) jobs, and remove future problems with reloading configurations Smile

. But again that's just my $0.02.

/**
 * @author Steven Christou
 * @dev    Hudson-ci
 */

Report message to a moderator

Re: hudson reloading configuration [message #1039585 is a reply to message #1039558]

Fri, 12 April 2013 10:15

Christian Schulz

Messages: 25
Registered: March 2013

Junior Member

Quote:

if there are a few hundred(thousand) jobs

I am willing to migrate back from Jenkins to Hudson, but I noticed in Jenkins already that a few jobs with about 500 builds per job takes very long to startup Jenkins. It is really a mass to work with it.

Do you really want to perform everytime a load from disk?
What if you have about 20 active users? Per user on each reload a new load from disk?

I think caching the config itself which has a size of some kb is a good idea, but there is a strategy missing what happens if someone wants to reload the files.
The best solution in my opinion would be similar to the shutdown system described in my post before.

Report message to a moderator

Re: hudson reloading configuration [message #1039819 is a reply to message #1039585]

Fri, 12 April 2013 16:33

Winston Prakash

Messages: 534
Registered: August 2011
Location: Fremont, CA USA

Senior Member

Christian, we are actively working on two main topics

- Reduce memory foot print
- Improve performance

The basic idea is to lazy load every thing on demand, rather than eagerly loading at startup. We are thoroughly investigating all the avenues to improve performance.

The main principle of Eclipse Hudson project is performance and stability over tons of new features. Slowly and steadily we are working on that. Cleaning up the libraries at 3.0 was a major step forward.

About issue with Reloading

- A dialog should appear to confirm reloading
- I think the best policy is to put Hudson in quiet mode, that is waiting to finish all the running jobs but no scheduling of new jobs. Once all the jobs are done reload
- Though I'm not in favor, but we could have a checkbox saying abort all jobs. This extreme measure is only if there is an assurance Hudson is messed up beyond the benefit of running all jobs and only solution is quickly reload the configuration.

Winston Prakash
Eclipse Hudson team

Report message to a moderator

Re: hudson reloading configuration [message #1039930 is a reply to message #1034358]

Fri, 12 April 2013 20:35

John M.

Messages: 198
Registered: July 2010

Senior Member

Hello Winston,

Sounds very interesting for me. Smile

I hope it is going well.
I want to switch in the next months.

Are there any plans to integrate a database or similar? It is just my own curiosity.

Your idea of reloading sounds similar to the shutdown functionality.
I would suggest to use it.

[Updated on: Fri, 12 April 2013 20:39]

Report message to a moderator

Re: hudson reloading configuration [message #1039948 is a reply to message #1039930]

Fri, 12 April 2013 21:13

Winston Prakash

Messages: 534
Registered: August 2011
Location: Fremont, CA USA

Senior Member

Hi John, could you explain your question "Are there any plans to integrate a database or similar?"

Winston Prakash
Eclipse Hudson team

Report message to a moderator

Re: hudson reloading configuration [message #1039951 is a reply to message #1039948]

Fri, 12 April 2013 21:19

John M.

Messages: 198
Registered: July 2010

Senior Member

Hello,

I hope I didn't interrupted the thread. :/
I am a friend of database based systems like configuration, build meta data and similar, which can also give a boost in performance.
Mostly a database is faster than the IO directly.

Report message to a moderator

Previous Topic:	Aborting SVN checkout locks workspace
Next Topic:	Warnings plugin hanging

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 16 11:20:38 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter