Marco,

No, this message is unrelated to the problem below.

What this message indicates is, that the corresponding resource of a
job is reloaded in the GT4 container at startup time.
The information about a job is not only held in memory, but also
persisted to disk. In case of a container shutdown, the in-memory
resource goes away, but when you restart it, it'll be reloaded from
the persisted data.
This ensures that a job is still manageable for a user after a
GT4 container restart, like query job status, delete the job.

A fix for the problem described below is not in 4.0.8.
If you think you run into it, apply the fix as described.

Martin

Marco Lackovic wrote:
> Hello,
> 
> when starting the container I sometimes get the following message:
> 
> 2010-03-24 11:44:11,609 INFO  exec.ManagedExecutableJobHome
> [Thread-2,recover:207] Recovered resource with ID
> 3cb225a0-36b6-11df-a43d-bc4c724692c3.
> 
> I am wondering whether it is related with the following problem and
> whether it has been then fixed in the version 4.0.8.
> 
> 
> On Wed, Aug 27, 2008 at 2:55 PM, Martin Feller <[email protected]> wrote:
>> Ok, i think i see it now. You are hitting a combination of generous
>> locking and a potential for an infinite loop in which your container
>> happily cycles.
>>
>> This situation can happen if your job wants to fetch a non-existing
>> credential (probably destroyed earlier) from the delegation service
>> and then, because the credentail does not exist anymore, tries to
>> delete the user proxy file created from that credential earlier, which
>> does not exist either, because it was probably deleted when the
>> credential was destroyed.
>> A not completely uncommon situation i guess, and we handle that badly.
>>
>> I'll have to check how this should be fixed best. This fix should
>> then also find it's ways into the VDT. I'll open a bug for that.
>>
>> A quick fix for you to go on is:
>> Replace
>>
>>    -delete)
>>        # proxyfile should exist
>>        exec rm "$PROXYFILE"
>>        exit $?
>>        ;;
>>
>> by
>>
>>    -delete)
>>        if [ -e "$PROXYFILE" ]; then
>>            exec rm "$PROXYFILE"
>>            exit $?
>>        else
>>            exit 0
>>        fi
>>        ;;
>>
>> in $GLOBUS_LOCATION/libexec/globus-gram-local-proxy-tool
>>
>> (A patch would have been nicer, but i don't know if our versions of
>> that file are the same)
>>
>> I'm quite sure that this solves your problem. Please let me know.
> 
> 
> 
> 
> 

Reply via email to