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

[Alex Sim]

That's an asynchronous way of handling it with snapshot of request saved
internally...
spec has a way to do that with the status call.

-- Alex



On 10/14/09 12:22 PM, Riccardo Zappi wrote:
> 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
>>>
>>>   
>
>