Jetty Quickstart with Shib IDP?

[Dylan Martin]

It takes a few minutes.  Is that not considered a long time?

The idp-process.log says

2016-11-15 11:34:27,950 - DEBUG
[net.shibboleth.idp.attribute.filter.spring.impl.AttributeFilterPolicyParser:84]
- Parsing configuration for attribute filter policy: main

A few minutes after that, the next line is

2016-11-15 11:37:03,783 - DEBUG
[net.shibboleth.idp.attribute.filter.spring.impl.AttributeRuleParser:97] -
permitValueRules [Generic bean: class
[net.shibboleth.idp.attribute.filter.Matcher$1]; scope=prototype;
abstract=false; lazyInit=false; autowireMode=0; dependencyCheck=0;
autowireCandidate=true; primary=false; factoryBeanName=null;
factoryMethodName=null; initMethodName=null; destroyMethodName=null]

Top doesn't show any java processes near the top, same with iotop and
iftop.  The time it seems to be waiting varies from 30 seconds to 3 minutes
and possibly longer.

I don't have a federation.  I have two SPs configured.

I should upgrade to 3.3.0.  It would be pretty dumb to bug you all and find
out the new version fixes my problem.

Thanks!
-Dylan






On Sat, Nov 12, 2016 at 11:21 AM, Brent Putman <putmanb at georgetown.edu>
wrote:

>
>
> On 11/11/16 5:11 PM, Dylan Martin wrote:
>
> Hi all.  I'm trying to get my IDP to start more quickly.  I'm using Jetty
> 9.3.13 and Shib IDP 3.2.1.  I found the Jetty Quickstart module (
> http://www.eclipse.org/jetty/documentation/9.3.0.v20150612/
> quickstart-webapp.html) and I'm trying to make it work.
>
>
> I'm wasn't familiar with that Jetty feature.  Doesn't necessarily sound
> like a bad idea, as long as it works, but: Have you looked at the container
> logs and the idp-process.log to ascertain exactly why your IdP's startup is
> slow in the first place?  I didn't actually think Jetty's startup was known
> to be all that slow (compared to newer Tomcat versions, which is horrible
> and requires extraordinary measures to address, see our Tomcat install
> docs).
>
> I only mention because: One of the biggest/slowest things that the IdP
> potentially does at start is to download large batch metadata files via
> HTTP (from your federation(s), etc).  When those are sufficiently large, as
> they often are with InCommon, etc, that can take quite a long time.
>
> In IdP 3.3.0, which was just released this week, we added new support in
> the batch HTTP metadata resolvers for executing the time-consuming HTTP
> fetch in a background thread, if the backup file from a previous download
> is available on the filesystem. The backup file is still loaded in the
> foreground thread, but that doesn't require any network ops, so is much
> faster.  This should usually dramatically reduce the foreground processing
> time (i.e. the startup time) when the backup file is present.  This is
> enabled by default when using a FileBackedHTTPMetadataProvider.  This
> isn't in the wiki docs yet, but should be there sometime next week.
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20161115/77c265ab/attachment.html>