Running Hudson builds with a lower process priority

Question

At my office we have an older server running Hudson (1.395) and a collection of other things (JIRA and SVN being the important two). When Husdon is running builds, the slowdown on the server is very noticeable.

I've been trying to find a way to re-nice the build processes that Hudson kicks off (we use maven). There doesn't seem to be an option for this. I don't want the copy of Tomcat Hudson is running in to be at a lower priority, so I've been trying to figure out a way to only have it apply to the build process. Without replacing/adding servers/slaves, these are the only options I've seen:

1. I can replace the maven plugin with my own, which launches Java through nice. This seems like a long way to go for such a small change, although I have found where in the code the change would go (in MavenProcessFactory.java, around line 110). This would be a maintenance burden

2. I can point Hudson at a fake Java directory. By doing this, I could replace Java with a shell script that would call the real Java, reniced.

3. I could setup some kind of script, like with cron, but I'd have to catch every sub-process to do it right

Has anyone done something like this? Do you know of another option?

Option #3 is a clear hack. #2 avoids me having to touch the code (so I wouldn't have to worry about future upgrades), but it isn't clear what's going on. Patching the code would require some upkeep, but I could make it clear how I'm running Maven or even make the niceness configurable on a per-project basis.

Answer 1

Absent a facility in the software itself that lets you do this, you've pretty much outlined the three options available to make it happen without working too hard.
Looking at those options more closely:

Option 3 sucks. Don't do it. Too complex and too much potential to screw up.

Option 1 sucks less - You just need to remember to patch every time you upgrade, which is annoying.

Option 2 is the Path of Least Suck. It's what I would do.
Yes it's not immediately obvious what's going on, but if you document what you've done (and the documentation is in an immediately obvious place) it's not a bad solution.