Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Re-introduction of https://shibboleth.atlassian.net/browse/IDP-1020 ?
Basics
Technical
Logistics
Basics
Technical
Logistics
Description
We have a monitoring script that authenticates itself via an test sp against our IdP every minute . After successful authentication the monitoring request a SLO. This works a few times, then fails with the following errors:
idp-process.log
net.shibboleth.idp.session.SessionException: Exceeded retry attempts while adding to secondary index
at net.shibboleth.idp.session.impl.StorageBackedSessionManager.indexBySPSession(StorageBackedSessionManager.java:657)
Reverting to JPA StorageService immediately resolves the issue.
Thank you.
Environment
Tested with Debian 12 Bookworm, OpenJDK 17, Tomcat 10 and IdP 4.3.1, seems also apply to Debian 11 Bullseye, OpenJDK 11, Tomcat 9 and IdP 4.3.1
Activity
Rod WiddowsonDecember 3, 2023 at 11:27 AM
The code has been shipped in V2. No further feedback -> closed
Rod WiddowsonAugust 7, 2023 at 1:23 PM
I’ll make that changes as part of this case. Before wednesday
Scott CantorAugust 7, 2023 at 12:42 PM
I think I would leave it, seeing as it really hasn’t come up until now. We do need to apply this same fix to the JDBCPairwiseIdStore in shib-attribute-impl though.
I think that’s about the only other case.
Rod WiddowsonAugust 5, 2023 at 10:43 AM
Change made and documented. Leaving open pending question of default
Rod WiddowsonAugust 5, 2023 at 10:29 AM
@Scott Cantor Do we want to flip the Transactional level in this release (the think passed to setTransactionIsolation to “Don’t set”?
We have a monitoring script that authenticates itself via an test sp against our IdP every minute . After successful authentication the monitoring request a SLO. This works a few times, then fails with the following errors:
idp-process.log
net.shibboleth.idp.session.SessionException: Exceeded retry attempts while adding to secondary index at net.shibboleth.idp.session.impl.StorageBackedSessionManager.indexBySPSession(StorageBackedSessionManager.java:657)
postgres db server:
2023-06-06 14:56:29.345 CEST [485227] tsso@tsso ERROR: duplicate key value violates unique constraint "shibpid_pkey" 2023-06-06 14:56:29.345 CEST [485227] tsso@tsso DETAIL: Key (localentity, peerentity, persistentid)=(http://dummy.com/idp/c101715f-8b05-4eb4-b6f8-4b2084e65598, http://dummy.com/sp/c101715f-8b05-4eb4-b6f8-4b2084e65598, c101715f-8b05-4eb4-b6f8-4b2084e65598) already exists. 2023-06-06 14:56:29.345 CEST [485227] tsso@tsso STATEMENT: INSERT INTO shibpid (localEntity, peerEntity, persistentId, principalName, localId, peerProvidedId, creationDate, deactivationDate) VALUES ($1, $2, $3, $4, $5, $6, $7, $8)
Other users despite the monitoring user may still authentifcate against the IdP but it is rather unresponsive.
This seems the exact behavior reported in https://shibboleth.atlassian.net/browse/IDP-1020.
Reverting to JPA StorageService immediately resolves the issue.
Thank you.