[GSM-WG] About synchronous srmLs with offset and count

[Riccardo Zappi]

Hi Alex,
thanks for your fast and clear answer.

Your answer confirms what I suspect, that is the naive use of 
offset/count in the srmLs can lead to insidious bugs in middleware based 
on it.

Maybe, it could be useful force to return also a requestToken when the 
srmLs includes the parameters offset/count and the result does not 
contain all the files pointed out by the request.

What do you think?

Thanks,
Riccardo



Alex Sim wrote:
> spec does not really say how ls request is handled for changing
> information, but this can be handled with the asynchronous call.   Two
> possible ways with this case: One, upon srmLs request, get the snapshot
> of the path at the time, and return to the client by the offset/count,
> and subsequent srmLs status call can return the rest of the contents by
> offset/count - being asynchronous.   Two, upon srmLs request, get just
> as many as server/client can handle and return to the client by
> offset/count, and on the next srmLs status call or different srmLs call
> with different offset/count, return to the client that portion. The
> second approach cannot really handle the changing information, and
> second call may even get some information that was already passed in the
> first call.
> 
> If you want to know how it's implemented currently, bring it up to the
> implementation mailing list.
> 
> -- Alex
> 
> 
> 
> On 10/14/09 9:58 AM, Riccardo Zappi wrote:
>> Hi,
>> probably we have already discussed this, but I would like return to the 
>> topic because I'm not able to find, both in the current SRM 
>> specification and in the archives of various SRM mailing lists, a 
>> conclusive answer.
>>
>> The doubt is in the interpretation of 'offset' and 'count' parameters in 
>> the case of a synchronous implementation of srmLs.
>>
>> The problem arises when in addition to offset and count parameters, it 
>> is specified at least one directory within SURL array and 'numOfLevels' 
>> is greater than zero. In this case, some SURLs pointed out by the 
>> request are not enumerated in the requests (i.e. the files within the 
>> directory) and therefore, the list of files may be change between 
>> subsequent calls, since files can be added or removed from the directory 
>> by some other concurrent SRM requests.
>>
>> For example, suppose you want list the content of a directory, and you 
>> do not know the exact number of files on it. Your first attempt fails 
>> with SRM_TOO_MANY_RESULTS, so you proceed with the use of count and 
>> offset. I think it is appropriate to suppose that SRM returns the lists 
>> of the files always in the same order, whatever it is.
>> Suppose that between two successive requests, one file is removed in the 
>> directory by another users/process, and that file fits in the part of 
>> list you already retrieved. In this case, your successive request skips 
>> one file, because your offset can take into account positions lose 
>> because of deletion from other SRM requests.
>>
>> We believe it is appropriate to explain better in the SRM specification 
>> the behavior expected in the case of offset, count, 'numOfLevels'> 0 and 
>> directories, with a synchronous srmLs implementation.
>>
>> Thanks in advance for any comments.
>>
>> Cheers,
>> Riccardo
>>
>>   


-- 
------------------------------------------------------------------------------- 

Riccardo Zappi

Istituto Nazionale di Fisica Nucleare - CNAF
Viale Berti Pichat, 6/2,  40127 BOLOGNA - ITALY
Phone:  +39-051-609-2868                Fax:    +39-051-609-2746
e-mail: riccardo.zappi at cnaf.infn.it
-------------------------------------------------------------------------------