Shib IdP 2.4.4 Issue

James McCartin jmccartin at
Mon May 18 15:39:13 EDT 2015

After I set the log options to DEBUG I found the following in the log when Shibboleth stops working:

17:19:52.210 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider:267] - Error occurred while attempting to refresh metadata from ''
java.lang.OutOfMemoryError: Java heap space

I checked my Tomcat Java Options and did not have any memory management settings configured.  I am going to add the options listed in and see if that solves the problem.

-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Michael A Grady
Sent: Thursday, May 7, 2015 2:01 PM
To: Shib Users
Subject: Re: Shib IdP 2.4.4 Issue

On May 7, 2015, at 9:42 AM, Jarno Huuskonen <jarno.huuskonen at> wrote:

> Hi,
> On Thu, May 07, James McCartin wrote:
>> I'm having an issue with Shibboleth and I'm hoping someone can help me in determining the cause.
>> Issue: Periodically Shibboleth stops working.  Users see a message that the SAML 2 SSO profile is not configured for relying party (address of SP for whatever app they are trying to access).
>> Fix: Restart the Tomcat service
>> I looked through the Shibboleth logs and the only thing I'm seeing is the refresh of metadata at the time Shibboleth stops working.  I'm going to change the IdP logs from INFO to DEBUG to see what else is happening.  Beyond that, I'm not sure what else to do.  Any thoughts?
> We've had similar problems in the past (with idp version < 2.4.4). Few 
> of these problems occurred at the same time when our firewall turned 
> into tarpit(connections seemed to connect but AFAIK no data was 
> transferred).
> You could try increase logging to see if http client / 
> metadataprovider logs any clues why it's failing. We have these loglevels:
>    <logger name="org.opensaml.saml2.metadata.provider" level="INFO"/>
>    <logger name="org.apache.commons.httpclient" level="DEBUG"/>
> -Jarno
> --
> Jarno Huuskonen
> --
> To unsubscribe from this list send an email to 
> users-unsubscribe at

Be sure that your Tomcat/servlet container setup includes at least the minimum memory settings specified here:

We were sure those settings were in place on one instance, but they weren't, and that was causing a failure when trying to update a large feed like InCommon's. You could see the update start to take place in the logs (with the metadata logging set to DEBUG), and it would just never complete. And in failing, it even killed the timer getting reset to ever check that feed again. Didn't impact any other feeds, or the IdP in any other obvious way. (I assume there were messages in the Tomcat log, but didn't have access to those.) But we also didn't have the latest point release of the IdP, so maybe the behavior of 2.4.4 would be different.

Michael A. Grady
IAM Architect, Unicon, Inc.

To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list