<html>

  <head>

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

      http-equiv="Content-Type">

  </head>

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

    <br>

    <br>

    <div class="moz-cite-prefix">On 7/21/15 12:51 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote cite="mid:147FD267-DC69-43CF-8CB2-CC7716E840B1@osu.edu"

      type="cite">

      <pre wrap="">On 7/21/15, 12:35 PM, "users on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:users-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><users-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:

</pre>

      <blockquote type="cite">

        <pre wrap="">Well, I haven't been following all the details of this thread, but I think you could get this if you are using a filesystem caching variant of the HttpClient.  There I think the cached data will persist across restarts, so indeed the first fetch after an IdP restart could be doing a conditional GET, if the resource had been fetched and cached previously.

</pre>

      </blockquote>

      <br>

    </blockquote>

    <br>

    Hmm, actually, on second look I think this shouldn't be happening. 

    Our FileCachingHttpClientBuilder actually returns an HttpClient

    proxy which amongst other things implements destroy() such that the

    file-based cache ought to be cleared.  Looks like destroy() ought to

    be called on the bean based on the wiring in global-system.xml.  So

    that's a bit murky, needs more investigation.<br>

    <br>

    IIRC, the reason we did that is that with the file-based cache, only

    the response bodies are actually cached on disk.  The response

    metadata is still in-memory (I think), so on a restart that stuff is

    getting lost anyway.  So what seemed to be happening was that the

    file storage was getting orphaned, if it's not cleared out on

    shutdown.  This was awhile ago though, so I could be mistaken.<br>

    <br>

    <br>

  </body>

</html>