Occasional problem with InCommon metadata refreshes

[Cantor, Scott]

On 6/27/14, 2:58 PM, "Brian Koehmstedt" <bkoehmstedt at ucmerced.edu> wrote:
>
>Thanks Scott.  This morning I switched to the HTTP-backed metadata
>provider as you and Tom recommended.
>
>Again I had problems that were almost identical to what I originally
>reported.  The log reports successful metadata load from
>md.incommon.org, but then none of the Incommon services worked and I had
>to back out the change and restart.  After I did that, it worked again.

That really just doesn't make any sense, so something is clearly wrong
here. Not that you couldn't figure that out...

>But I better confirm with you: If it takes the IdP say X number of
>seconds to download that 10MB, would I normally expect to see a 0-byte
>backing file while it's downloading?  Or is this evidence something
>environmental is wrong with the filesystem?

I really have no idea. I would assume that's likely, if that's what Java's
doing to overwrite the file. I don't know what a typical file open() call
with the overwrite flag set will do.

But the size of the file really doesn't matter, the IdP isn't going to
swap in a new copy of the metadata into use until it's got a validly
loaded and filtered instance to do that with.

The bugs seem to be cases where it stops reloading improperly, but I've
never heard any complaints that it somehow overwrite valid metadata with a
null copy. What seems to happen for some people is that the metadata
expires in memory and never gets replaced with a fresh copy, but you
wouldn't see logs showing it reload the metadata in that case.

-- Scott