A delay in the writing of the results file (results.zip) to the shared file system can cause one or more of the following errors leading to a failure of batch analysis:

Timeout: File is not a valid zip file ...results.zip

URL is not a file: ...results.zip

These errors are also captured in the following log on the Columbus server:

/var/log/columbus/web/long-tasks.log

In vesions of ColumbusPlus up to 2.8.2 the following file on the server can be modified to increase the amount of time before reading the results.zip file:

/usr/local/PerkinElmerCTG/Columbus2.8/webapp/columbus/cluster/tasks.py

For example change line 173 from:

submit_results_to_columbus.apply_async((job, cluster_conf_dir), countdown=5)

to

submit_results_to_columbus.apply_async((job, cluster_conf_dir), countdown=30)

This example increases the countdown time to 30 seconds. After changing restart Columbus for changes to take effect:

$ /etc/init.d/columbus restart

If accurately gauge the amount of time it took to write the results.zip successfully try the following:

- From the error message copy the path to the results.zip file

- On the Columbus server navigate to this directory that contains the results.zip

- In this path you should find a postprocessing directory containing a DONE file (this is written after the results.zip file has completed)

- Use the following command to get the status of the file

$ stat DONE

- Compare the time of the error with the Modify date of the file

- At the very least this will give you the amount of time you will need to add to countdown (though add more to act as a further contingency)

In versions above 2.8.2 (i.e soon to be released 2.9.0) the strategy to check the results is changed further. It features as timeout on line 50 of aforementioned file. In light of new strategy it is highly unlikely this value needs to be changed but is shown here for reference.