2680 2005-02-02 14:32 Can't change source url for gram job staged files 2012-09-05 11:42:26 1 1 1 Unclassified GRAM wsrf managed execution job service 3.9.5 All All RESOLVED WONTFIX P3 enhancement 4.4 1 jfrey@cs.wisc.edu smartin@mcs.anl.gov dangulo@cs.uchicago.edu lane@mcs.anl.gov madduri@mcs.anl.gov smartin@mcs.anl.gov jfrey@cs.wisc.edu 2005-02-02 14:32:18 To my knowledge, once a ws-gram job is submitted, it is not possible to change the source URL for any stage files that are part of that job. This makes it painful to use a source url that includes a dynamic port. If the client gridftp server crashes and restarts on a different port, all submitted jobs must be removed and resubmitted, losing any work they've accomplished. This is likely to be the way that Condor-G will operate in the future (standing up its own gridftp server). We would like the ability for a client to change the source URL of staged files after the corresponding job resource has been created. We feel this is important functionality for good fault-recovery. jfrey@cs.wisc.edu 2005-02-02 14:39:03 This is a loss of functionality versus pre-web services GRAM, which does allow the updating of source URLs for staged files. smartin@mcs.anl.gov 2005-02-02 16:08:19 I don't see this happening in 4.0. We'll have to talk about what makes sense to do for 4.2 For 4.0, here are a couple options: 1. Ensure that the URL won't change. Use a well known port for the client side GridFTP server 2. Stage the files by hand (not gram). Use the cleanup hold feature to stop the MEJS from cleaning up the jobs files. Stage the files by hand through the GridFTP server. Then release the job to complete the cleanup. lane@mcs.anl.gov 2005-11-02 17:43:49 We've talked about publishing the FS mapping XML document as an RP. Perhaps we should do that and say, "if you want finer control over staging, then you need to use RFT or GridFTP directly." After all, at best this creates a race condition between when GRAM submits transfer requests to RFT and the server URL update. So it may not even work and you'll have to re-submit the job anyway. jfrey@cs.wisc.edu 2005-11-02 20:01:52 Would it be feasible to add support in RFT for changing the URLs for an existing transfer resource? The new URLs would be used the next time a transfer is attempted. lane@mcs.anl.gov 2006-10-02 12:20:44 Would an acceptable solution to this be to simply provide a gsiftp URL list RP for selected files? This wouldn't give you the reliability of RFT, but would allow you to simply pull the files and not worry about a client-side GridFTP server. madduri@mcs.anl.gov 2006-10-02 13:00:02 Subject: Re: Can't change source url for gram job staged files We talked about adding this capability to RFT where we provide an operation to "modify" a request. There was not enough interest to convince development time. bugzilla-daemon@mcs.anl.gov wrote: > http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=2680 > > > > > > ------- Comment #5 from lane@mcs.anl.gov 2006-10-02 12:20 ------- > Would an acceptable solution to this be to simply provide a gsiftp URL list RP > for selected files? This wouldn't give you the reliability of RFT, but would > allow you to simply pull the files and not worry about a client-side GridFTP > server. > > > > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > jfrey@cs.wisc.edu 2006-10-02 14:52:59 Providing a list of gsiftp URLs for the client to transfer is a possible solution. We'll have to investigate how much work it'd be to add support for this in Condor-G. bacon@mcs.anl.gov 2007-09-19 11:37:52 Reassigning to current GRAM developer to close/fix as appropriate. smartin@mcs.anl.gov 2012-09-05 11:42:26 Doing some bugzilla cleanup... Resolving old GRAM3 and GRAM4 issues that are no longer relevant since we've moved on to GRAM5. Also, we're now tracking issue in jira. Any new issues should be added here: http://jira.globus.org/secure/VersionBoard.jspa?selectedProjectId=10363