Metadata reload errors logged on DEBUG only
Basics
Logistics
Basics
Logistics
Description
Environment
None
is cloned by
Activity
trscavo@ncsa.illinois.edu September 18, 2015 at 8:14 PM(edited)
trscavo@ncsa.illinois.edu
September 18, 2015 at 8:14 PM
(edited)
To work around this issue prior to the release of V3.2, add the following logger to /opt/shibboleth-idp/conf/logback.xml:
<!-- the following logger works around issue https://issues.shibboleth.net/jira/browse/OSJ-125 -->
<logger name="org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver" level="DEBUG"/>
Tom Zeller September 15, 2015 at 2:29 PM
Tom Zeller
September 15, 2015 at 2:29 PM
Agree, just wanted to make the suggestion.
Scott Cantor September 15, 2015 at 2:27 PM
Scott Cantor
September 15, 2015 at 2:27 PM
I don't think "Out of memory" will be confusing to people (well, not the people who can be helped at all).
Tom Zeller September 15, 2015 at 2:25 PM
Tom Zeller
September 15, 2015 at 2:25 PM
Case closed, just wondering if we should try and catch the OutOfMemoryError to log something "more meaningful", not sure exactly what that would be.
Scott Cantor September 14, 2015 at 7:41 PM
Scott Cantor
September 14, 2015 at 7:41 PM
r4337, upped to ERROR.
Fixed
Details
Details
Assignee
Scott CantorReporter
Scott CantorComponents
Fix versions
Created September 14, 2015 at 7:39 PM
Updated June 22, 2021 at 8:42 PM
Resolved September 14, 2015 at 8:51 PM
Under low memory conditions, we're catching the OutOfMemory exception in the AbstractReloadingMetadataResolver class to log it, but it's only logged on DEBUG.
We catch the exception it rethrows in the refresh thread, but that doesn't get logged, so all the log shows on INFO is a stream of Next refresh time is... messages that make it appear to be checking for changes but not finding any.
We should also review the service reload code for any similar issue.