I see that you have resolved your issue, but I just wanted to point out a
couple of things in case you run into this again.
First, and most importantly, you should NEVER try to do anything to a
sleeping job. Jobs put themselves to sleep for a reason, and it's
impossible for the Queue System or anyone else to know why and what that job
is waiting for. However, in the case of RDB Refresh, I can tell you exactly
why this particular job sleeps (read on for more info on this...).
Second, for troubleshooting what the problem really was and how to fix it,
what would be helpful in your case is not necessarily the error from the CBS
failure, but the error from the Custom Field sync job that failed (read
below to understand what I mean by this). Also the error from the RDB
Refresh job that failed would be helpful. These 2 errors together can help
determine what went wrong.
Third, I'll try to explain the RDB Refresh process, but here is the quick
version (below is a more lengthy text version):
1. RDB Refresh job is "chosen" by the Queue to process.
2. RDB Refresh selects some number of entities (resources, custom fields,
whatever was restored) to restore/sync.
3. RDB Refresh places one job in the Queue for each entity it chose in step
2.
4. RDB Refresh job goes to sleep (this is only an indicator to the Queue
that it should not be a candidate for processing at this time) and sets its
wakeup time for 5 minutes later.
picked up for processing by the Queue>
5. RDB Refresh wakes up (this only means that its wakeup time has passed,
and the Queue will now consider it as a "processable" job).
6. RDB Refresh gets chosen for processing by the Queue System.
7. RDB Refresh assesses whether all of the jobs from step 3 have been
processed by the Queue yet.
If yes, then if there are more entities to be restored/synced, go
back to step 2.
If yes, then if there are no more entities to be restored/synced,
then go to step 8.
If no, then go to step 4.
8. RDB Refresh determines whether it should succeed or fail.
If ALL entities processed with no errors, then succeed.
Else fail.
The RDB Refresh job itself is merely a "monitor" of the admin restore
individual reporting sync jobs. It is a bottleneck of sorts, so that the
Reporting System doesn't completely flood your Queue with requests to sync
data from an admin restore all at once. Think of the organizations who have
thousands and thousands of Resources, Custom Fields, etc. So what the RDB
Refresh job does is get a certain number of entities (custom fields, in your
case) to sync, place jobs in the Queue for those entities, and go to sleep
waiting for those new jobs to get processed. Again, in order for the
Reporting System to not flood your Queue, the RDB Refresh job will sleep for
a minimum of 5 minutes in one "interval" (but could sleep longer if the
entities it is waiting for are taking longer than 5 minutes), no matter
what. If any ONE of the entities it is trying to sync fails to do so, then
the RDB Refresh job itself will fail. If ALL entities synced just fine,
then the RDB Refresh job will succeed. This is just a way to tell you if
any one of the entities failed, so you can investigate.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm