Problem with IdP startup

[Hancock Jr, Denis C.]

A problem with starting IdP version 2.0.0 has emerged.  Following a modification to release the Common Name (cn) attribute, the IdP failed to start up completely.

The catalina.out log seems to indicate a successful start with many INFO entries along with a few WARN entries, mostly relating to deprecated syntax.  These involve ch.qos.logback.*.  The final lines indicate that Coyote is starting on port 8080 and ajp13 is listening on port 9799.  JK is running and the server startup took 46200 ms.  Seems OK to my eyes....

The idp-process log shows that the attributes are being parsed, including the cn, which I had just released.  It then goes into a lot of INFO entries showing that the attribute filters were being parsed as well as the metadata.  It ends with a notification that the shibboleth.Handler.Manager had loaded a new configuration.

After attempting to connect to the IdP, the apache ssl log notes that an AJP connection was refused on port 8009.  the next line says that ap_proxy_connect_backend has disabled the worker for the backend.

netstat does not show a listener for port 8009.

Has anyone seen something similar to this?  All the troubleshooting techniques I can think of do not seem to point me in the right direction.

--
Denis C. Hancock, Jr.
System Administrator (Expert)
Division of IT, Research Support Computing
The Univerity of Missouri, Columbia