
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 9/14/16 5:43 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:73085078-A437-4540-8A1C-A9885B5F3057@osu.edu"

      type="cite">

      <pre wrap="">On 9/14/16, 5:19 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:


If we implemented "priming" with a background thread, we'd need something like that anyway, </pre>

    </blockquote>

    <br>

    If priming is done by just externally executing metadata resolve

    requests (i.e. ignoring the return values), I don't think anything

    additional is needed.  It's handled by the existing read/write lock.<br>

    <br>

    I didn't mention, but with this proposal, another way to prime the

    resolver is to just dump XML into the cache (e.g. drop files into

    the cache directory).  You actually don't even have to name them in

    any particular way.  On the init and enumeration, if the existing

    cache key doesn't match the expected cache key (for example, on the

    restart you changed the cache key generator function), it updates

    the record in the cache to be indexed by the expected one.  That's

    the reason for the updateKey(currentKey, newKey) method.  This is

    not tested yet, though.<br>

    <br>

    <blockquote cite="mid:73085078-A437-4540-8A1C-A9885B5F3057@osu.edu"

      type="cite">

      <pre wrap="">and I'm not sure that it's all that different than the general locking we'll need for normal usage.</pre>

    </blockquote>

    <br>

    Actually, you may be right for the above reason.  I guess you just

    get the write lock and if you already have "live" metadata, you skip

    that cache entry - it would have been from an incoming request

    (since the background thread started) and the one in cache would

    necessarily already match it, I think, having been newly written

    (assuming lazy iteration of the filesystem).<br>

    <br>

    <blockquote cite="mid:73085078-A437-4540-8A1C-A9885B5F3057@osu.edu"

      type="cite">

      <pre wrap=""> But, I'm also not saying it's worth it, I think a predicate you could inject would take care of tuning the startup cost well enough.</pre>

    </blockquote>

    <br>

    I'll start out with that for sure.<br>

    <br>

  </body>

</html>