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

[Alex Sim]

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
>
>