Community
Participate
Working Groups
Created attachment 210813 [details] hudson queue Feb 9, 2012 around 11:45 Looking at the jobs, it seems like there is a large queue waiting for Hudson slaves to run their builds lately. If you look at the individual jobs, some of them are waiting for the next executor while some of them are specifically tied to slave1. Now that we have more executors available perhaps people who initially tied their jobs to slave1 need to be reminded that they should not tie their jobs to a certain slave to allow the queue to proceed more quickly.
Are you suggesting they leave that field empty? Or, just pick an option that lists several machines? I'll confess I might have misunderstood, but thought we can not leave it empty, since some of the machines are very specific to mac, windows, performance, etc. So, knowing a concrete value to use would help us know how to set up our jobs ... or, let us know if that's not needed.
> Looking at the jobs, it seems like there is a large queue waiting for Hudson > slaves to run their builds lately. Is that necessarily a bad thing? Was this queue blocking one of your jobs from running? Or is there simply an expectation that all queued jobs should be executed immediately. As more and more projects opt for Continuous Integration, where builds are triggered automatically by a commit, I expect that there is not a human actively waiting on the output of these builds, so I'm not sure why having a queue of triggered builds is necessarily bad. Later in the day the queue was empty, so all the builds that were there were serviced.
We happened to be discussing the state of Hudson in the Architecture council. At the time, we looked at the queue and there were about 20 jobs queued. And the same time, it looked like many of the jobs were tied to slave 1, and many of the other slaves were idle and not running jobs. We just thought that some teams might need to be reminded to untie their builds from a specific slave to facilitate faster builds. We thought that perhaps several teams had tied their builds to a specific slave in the past when some of the slaves were very unstable and never bothered to change it back. In fact, Doug commented that he had done just this with his CDT builds and that he was going to change it. David, yes, I realize that there are architecture limitations for some builds. However, you can list the pool of machines that are applicable to your build using regular expressions in the node and label menu, I'll attach an example from one of my configurations.
Created attachment 210874 [details] regexp node configuration
(In reply to comment #3) > At the time, we looked at the queue and there were about 20 jobs queued. Just closing the loop on this one -- the reason so many jobs were queued was a bad plugin. Builds were uselessly being queued for no reason.
I think we can close this one as fixed. Jobs aren't queuing up so quickly, and we've added a few new slaves.
