| 240 | | === Queuing === |
| 241 | | |
| 242 | | Before any loading clients can do anything, you must queue something up. To do this run: |
| 243 | | |
| 244 | | {{{ |
| 245 | | ./run.sh queue.py someConfig |
| 246 | | }}} |
| 247 | | |
| 248 | | When run, {{{load.py}}} first queues up all the exposures or stacks that it needs to process, then works through them sequentially, doing detections first then stacks. The master list comes from the gpc1 {{{addRun}}} table, which lists all items currently merged into the DVO database we are using. From this list, {{{ippToPsps}}} subtracts items that have already been successfully loaded to the datastore already, and queues up the remainder. |
| 249 | | |
| 250 | | Because it is possible, and usual, to run multiple versions of {{{load.py}}} in order to speed up loading time, the methods to queue and begin processing a new batch form a critical section. This simply means that the 'batch' table in the {{{ippToPsps}}} database is locked by a client looking for a new item to process, then released afterwards. |
| 251 | | |
| 252 | | An important factor in the queuing of items is the current ''epoch'', which is set in the config. |
| | 240 | |