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.
Hudson should check if any job is running and inform about it
Hudson should rerun jobs after reloading configuration.
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 . But again that's just my $0.02.
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.
Winston Prakash Messages: 449 Registered: August 2011 Location: Fremont, CA USA
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.
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.