Configuring a file-backed HTTP resource for attribute filters

[Brent Putman]

On 7/21/15 12:51 PM, Cantor, Scott wrote:
> On 7/21/15, 12:35 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>> 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.
>

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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150721/014bd00a/attachment.html>