Pre-meeting on "busy" storage services (11/02/2009)


J.P. Baud, F. Donno, A. Frohner, E. Lanciotti, G. Lo Presti, R. Mollon, A. Sciabà, D. Smith, P. Tedesco


Suggesting that the client specifies desiredTotalRequestTime and the server should do its best to abort a request, if the time is reached and the client did not abort it explicitly (i.e. the client has crashed). Returning remainingRequestTime is desirable but less important.

Suggested a back-off algorithm on both synchronous and asynchronous methods: if an SRM_INTERNAL_ERROR is received, the client shall use an exponential retry period on the same operation.

Suggested an asynchronous polling method:

  1. send an srmPrepareToGet/Put
  2. in a loop with an exponential retry period until something changes: srmGetRequestSummary (lighter on the SRM)
  3. use srmGetStatus to get the details of the change.

On the metascheduling level: it is very hard to give a meaningful estimate on how "busy" is the SE, so we give up on that for now.

-- AndreaSciaba - 12 Feb 2009

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r1 - 2009-02-12 - AndreaSciaba
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback