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

Participants

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

Conclusions

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-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback