Bug 3466 – Delegation always fails once on empty persistent directory

Bug 3466 - Delegation always fails once on empty persistent directory

Summary:

Delegation always fails once on empty persistent directory

Status:	RESOLVED FIXED

Product:	Java WS Core
Component:	globus_wsrf_core
Version:	4.0.0
Platform:	PC Linux

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Jarek Gawor

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-06-10 12:44 by Mats Rynge
Modified:	2005-06-27 14:17 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Mats Rynge 2005-06-10 12:44:58

After changing the persistent directory to non-standard directory, delegation
service always fails the first usage, but creates the needed dir, and works in
subsequent uses. Example:

[rynge@devrandom ~]$ globusrun-ws -submit -S -s -F nimrod.isi.edu:5000 -Ft
Condor -c /nfs/asd/rynge/globus/egee/load-5
Delegating user credentials...Failed.
Cleaning up any delegated credentials...Done.
globusrun-ws: Error trying to delegate
globus_delegation_client_util: DelegationFactoryPortType_RequestSecurityToken
callback failed.
globus_soap_message_module: SOAP Fault
Fault code: soapenv:Server.userException
Fault string: java.rmi.RemoteException: Error creating service resource;
nestedexception is:
        org.globus.delegation.DelegationException:  [Caused by: Failed to
storeresource; nested exception is:
        java.lang.RuntimeException: Failed to create storage directory:
'/nfs/asd2/globus/.globus/persisted/nimrod:5000/DelegationResource']

[rynge@devrandom ~]$ globusrun-ws -submit -S -s -F nimrod.isi.edu:5000 -Ft
Condor -c /nfs/asd/rynge/globus/egee/load-5
Delegating user credentials...Done.
Submitting job...Done.

------- Comment #1 From Rachana Ananthakrishnan 2005-06-14 11:26:38 -------

I tested Delegation Service on Windows and Linux (NFS) and saw no issues with 
persistence, both with default and non-standard directory.

Mats confirms that he sees this only with GRAM interaction and in case of non-
standard and default directory/

Peter, have you seen this before ? Any ideas ?

------- Comment #2 From Peter Lane 2005-06-14 13:00:08 -------

I didn't even know that you could specify a non-standard persistence data
directory, so no I haven't seen this before.

------- Comment #3 From Mats Rynge 2005-06-14 13:50:30 -------

It has really nothing to do with the non-standard directory. This also happens
if the default one does not exist. Try this:

 - stop container
 - rm ~/.globus/persisted
 - start container
 - run job

------- Comment #4 From Peter Lane 2005-06-14 14:11:47 -------

Ok, sorry.  I didn't look deep enough at the original post.  Actually I have
seen this before on occasion with GRAM too.  It's never been consistently the
first time everytime.  I remove the directory quite often and don't see it that
much.  I would say that this is a core issue since the common persistence
classes are there.

------- Comment #5 From Jarek Gawor 2005-06-14 16:25:44 -------

This is most likely a problem in core in FilePersistenceHelper - reassigning.

------- Comment #6 From Mats Rynge 2005-06-27 14:17:38 -------

I just tried to reproduce with a new build from globus_4_0_branch, and was not
able to. Closing as fixed.

Thanks!