Shibboleth IdP 3.2.1 on Windows 2012r2

[Michael A Grady]

> 
>> Would frequency of looking for changed config files have any impact?
> 
> That would be an obvious issue to look at. It can't be metadata, because everybody has that.

I'll have them set that to less frequent to see if it impacts anything.

> 
>> We did have this IdP accessing a remote filter file  (in addition to its local one) thru
>> HTTPS (using SWITCH config as an example), but we turned that off just in
>> case that was having any impact. But the behavior stayed the same, with the
>> growth.
> 
> That would have been my guess, so that doesn't leave much. I think the most productive thing to find out is the answer to my original question. If others are running it on this OS, then that proves the problem is local.

I've worked with the same combo at several places, 2012r2, InCommon metadata, etc. Some with our "SplitAuthn" extension. So far everyone else is good at 1500 or 2048mb, haven't reported any problems, and they have the same frequency of update and also consuming that "central attribute filter file".  But no one with anywhere near the same relatively heavy use of the IdP, no one else with O365 and ECP.

But I should go back and see what memory pattern they are seeing.

> 
> I don't think it's possible to be using a different XML parser without having errors, but looking for copies of Xerces might be worth a minute or two.
> 

This was a newly setup VM, clean install of Java and the IdP/Jetty combo. And no other Java app installed, in fact, other than Firefox and an LDAP Browser, pretty much not anything that isn't a base 2012r2 server. So can't imagine how there could be another copy.

Thanks for the discussion and suggestions; it is puzzling.

--
Michael A. Grady
IAM Architect, Unicon, Inc.