Stale Request in Clustered Environment

[Jarno Huuskonen]

Hi,

On Wed, Nov 04, Aaron Cargo wrote:
> Good morning all and greetings from western Pennsylvania;
> 
> We're finalizing a Shibboleth 3 deployment to handle campus authentication
> for approximately 5000 users. We've a pair of servers running server 2012
> behind a load balancer and are using mysql for session storage by setting
> the following values in conf/ldap.properties on both machines.
> 
> idp.session.StorageService=shibboleth.JPAStorageService
> idp.artifact.StorageService = shibboleth.JPAStorageService
> idp.replayCache.StorageService = shibboleth.JPAStorageService
> 
> Sessions are visible in the mysql database while active and everything
> appears to function correctly for either server until the second server is
> placed into production on the load balancer.

Is the LB configured for sticky sessions (meaning that client goes
to same backend(idp) server during authentication (or atleas for few minutes)).

> When we do, users begin receiving "Stale Request" messages when attempting
> to authenticate or access a new SP. It doesn't matter which of the two
> servers is active behind the load balancer, and it doesn't happen to every
> user or for every request. Once a user gets the stale request message, only
> dropping one of the idp's from the loadbalancer or an extended wait seems
> to resolve the message and allow login, and each new attempt at accessing
> the login process seems to refresh the waiting period.

Anything about the stale requests in idp-process.log ?
And have you checked access_logs that the stale requests are not
"replayed" (for example client uses back-button or some proxy/lb server
caches requests when it shouldn't).

-Jarno

> Am I missing something simple or immediately obvious to anyone? If not,
> what logging/configuration snippets would be useful in diagnosing this
> issue?

-- 
Jarno Huuskonen