Use case:

Only a single instance of the iOS Simulator can be used at a time, therefore limiting its use to one project. Projects using the iOS Simulator should be the member of a shared category, which defines a maximum of one concurrent execution per node, since each node has only one iOS Simulator available at a time. Starting a second concurrent use of the iOS Simulator with xcodebuild tests will cause the first use to crash and fail.

Problem:

Assume X projects are in a category. When these projects have builds running that consume all of the available max defined concurrent executions, the plugin will correctly throttle new builds by placing them in the queue.

If more than two builds are queued and one build completes, all builds will start when only one should start (so long as the node/s have additional executors available).

Steps to reproduce:

1. Create a new throttling category "test-category" with a max of 1 concurrent build per node
2. Configure a single node N (master is okay) with 4 executors
3. Create four identical freestyle jobs A, B, C, and D configured to be a member of the throttling category "test-category", restricted to node N, and with one execute shell step "sleep 60"
4. Start each of the jobs in order - A, B, C, D

Actual:
1. Build for project A starts on node N
2. Builds for projects B, C, and D are queued
3. Build for project A completes
4. Builds for projects B, C, and D start on node N
5. Builds for projects B, C, and D complete

Expected:
1. Build for project A starts on node N
2. Builds for projects B, C, and D are queued
3. Build for project A completes
4. Build for project B (or another, however the queue is sorted) starts on node N
5. Builds for other projects remain queued
6. As the builds complete, pop one off the queue to consume the new slot