DIRACGrid / DIRAC

DIRAC Grid
http://diracgrid.org
GNU General Public License v3.0
114 stars 176 forks source link

Exceptions from RegistrationAgent #205

Closed fstagni closed 13 years ago

fstagni commented 13 years ago

From the LHCb production installation, I see:

2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: Pfn.pfnparse: Exception while parsing pfn: None 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: == EXCEPTION == 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: <type 'exceptions.TypeError'>:expected string or buffer 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: File "/opt/dirac/pro/DIRAC/Core/Utilities/Pfn.py", line 70, in pfnparse 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: if not re.search( ':', pfn ): 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: File "/tmp/acasajus/tmpYXAxUMDiracDist/Linux_x86_64_glibc-2.5/lib/python2.5/re.py", line 142, in search 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: return _compile(pattern, flags).search(string) 2011-09-22 10:31:16 UTC DataManagement/RegistrationAgent EXCEPT: ===============

Would you mind having a look? I don't know if it requires a quick fix or not.

KrzysztofCiba commented 13 years ago

I will take a closer look, if you don't mind. IMHO this TypeError comes from

RegistrationAgent.executeRequest() -> ReplicaManager.registerFIle() -> ReplicaManager.__registerFile() -> StorageElement.getPfnForProtocol() -> pfnparse()

but I need to dig a little deeper to understand what is exactly passed in this chain as pfn.

BTW can you please direct me to the log file?

graciani commented 13 years ago

The "exception" is due to passing wrong arguments to the function. It is trapped, reported and a proper error is returned.

except Exception: errStr = "Pfn.pfnparse: Exception while parsing pfn: " + str( pfn ) gLogger.exception( errStr ) return S_ERROR( errStr )

if the calling method is properly checking return value it should not be a "problem".

KrzysztofCiba commented 13 years ago

That's we know. IMHO the problem is how this pfn == None was put over there.

fstagni commented 13 years ago

I can only say that I don't see this exception anymore in today's logs. Yesterday it was probably trying to register files that were still not existing in the BKK. This was due to another problem, related with the Request system, which I fixed yesterday afternoon by resetting flags in the DB. You may have a second look, because I might be wrong, but probably there's no problem at all. Maybe, this exception can be trapped and reported as a normal ERROR, up to you to decide.

Thanks, Federico

graciani commented 13 years ago

The exception is trapped and a proper error returned. The trace back is only there to allow debugging of the caller to know what was going on in more detail.

fstagni commented 13 years ago

It's seems there's nothing to do here... closing.