On Thu, Oct 17, 2013 at 5:49 AM, Peter Cock p.j.a.cock@googlemail.com wrote:
On Thu, Oct 17, 2013 at 11:36 AM, John Chilton chilton@msi.umn.edu wrote:
I broke the TaskWrapper last week with my exit code handling "fix", the double semi-colon thing you are seeing there. Your fix would break non-task split jobs so that is probably the problem(?) Hopefully? Want to revert 8e001dc9675c and pull in the changeset I just pushed out.
Otherwise, I will test out task splitting later today.
I am very sorry.
-John
Thanks John,
Those of us running with galaxy-dist expect minor breakage from time to time - I do this to avoid more pain if the problems were not spotted by the community and reached galaxy-central and thus our production Galaxy instance.
Well they have given me commit access so expect a lot more "minor breakage" :).
(And with the job splitting not being enabled by default, I am aware that I am in a relatively small group of Galaxy admins using it.)
I don't think my fix hurts non-task split jobs, but I will now try your fix on the default branch:
I think it will in at least some cases if metadata is getting set externally, I don't see how it is preventing some commands from running together, I could totally be wrong though.
At any rate, I tested the version with my fix on your blast wrappers, with task splitting on and off, submitting to a DRM and using the local job runner, and they all seemed to work. Let me know if your galaxy instance is unconvinced.
https://bitbucket.org/galaxy/galaxy-central/commits/329ea7a83af4f389a7c95ee4...
This appears to also address a metadata issue, which if I am lucky may be the fix for this issue?:
http://lists.bx.psu.edu/pipermail/galaxy-dev/2013-October/017031.html
I doubt your luck is so good. That problems looks like some sort of disk caching issue to me (galaxy process and worker node having inconsistent views of the same file system), I doubt this will fix it. Though hopefully I am wrong on both counts :).
Thanks for reporting the problem and the fix!
-John
Thanks,
Peter