Description of problem:

Doing (something?) in katello during pool creation led to a situation where a subscription pool got into a wedged waiting state. Since candlepin is doing a table read from memory, it is not going back to help decongest this job nor subsequent pools that get added later.

I think that's right, anyway.  

The resolution is to assure candlepin can go back in and get those queued pool jobs back into a processed state.

psql snippet:


candlepin=> select id, state, targetid from cp_job where id like 'refresh%';
                         id                         | state |     targetid     
----------------------------------------------------+-------+------------------
 refresh_pools_2edd2e15-94c0-45ba-a52f-64c25229cb51 |     0 | ACME_Corporation
 refresh_pools_58f7af9c-164a-449b-a60a-4354d99aaeae |     3 | ACME_Corporation
 refresh_pools_595a4077-faef-4784-a33c-c3a6b2dbfa76 |     3 | ACME_Corporation
 refresh_pools_25a6bf5e-32e8-4cdd-802c-e941eed7bbbb |     0 | ACME_Corporation
 refresh_pools_feb237d6-da73-4e90-b375-2af7e45100ec |     0 | ACME_Corporation
 refresh_pools_c2c15f21-9db5-4743-84ca-2f2d479402ee |     0 | ACME_Corporation
 refresh_pools_b3d9cf0d-d650-4511-93b7-1c4e489e9a55 |     0 | ACME_Corporation
 refresh_pools_f1848de8-487e-4e84-a4f1-da762ab9dde4 |     0 | ACME_Corporation
 refresh_pools_d049cf7c-5c34-4e0d-8cf7-19f4d87b5ce0 |     0 | ACME_Corporation
 refresh_pools_d5ee9da1-40dd-4a6c-982f-41bd1c53dfaf |     0 | ACME_Corporation
(10 rows)