In V2.5 if the ODBC connector can't talk to the database at service start-up it backs off and uses mem: (I think in 2.4.x it didn't back off and just gave #500 errors?)
CRIT Shibboleth.Config : failed to instantiate StorageService (db): ODBC StorageService failed to connect to database. INFO Shibboleth.Config : no StorageService plugin(s) installed, using (mem) in-memory instance
This is good in that the server starts and works; however if the app relies on ODBC for reliability (say due to non sticky LB) then it's likely to result in a unreliable app.
The /Shibboleth.sso/Status reports the following even when it's using memory when it was told to use the db. <SessionCache><OK/></SessionCache>
It would be great if the status handler would report it was faulty. (Or report the type in use mem/db/etc and allow the monitoring system polling the status page to alert that all wasn't well.
Environment
shib on IIS in Windows 2008 R2 with ODBC plugin talking to MSSQL
Behavior was the same on 2.4 as far as I can tell, but I think it's appropriate to "correct" it such that if a StorageService attribute is explicitly set, that it MUST find that service or fail to load. If omitted, then it behaves as before, and pulls a default service to use.
Modern configs omit the whole element and will default the service, but configs specifying an ODBC service will fail if the service isn't available.
Paul Brears
October 9, 2012 at 3:47 PM
A fail fast option would work with us.
I believe that 2.4 failed on start-up but without downgrading I can't tell. It might be the fails I saw on 2.4 weren’t quite the same and therefore behaved differently.
Scott Cantor
October 9, 2012 at 2:47 PM
I don't think 2.4 was any different, but it's possible, I'll check.
I don't think there's any clean way for the status handler to know (it could with an API change of course, but that's not happening soon). Probably it's more doable to add an option to "fail fast" and not get the cache created in this case.
In V2.5 if the ODBC connector can't talk to the database at service start-up it backs off and uses mem:
(I think in 2.4.x it didn't back off and just gave #500 errors?)
CRIT Shibboleth.Config : failed to instantiate StorageService (db): ODBC StorageService failed to connect to database.
INFO Shibboleth.Config : no StorageService plugin(s) installed, using (mem) in-memory instance
This is good in that the server starts and works; however if the app relies on ODBC for reliability (say due to non sticky LB) then it's likely to result in a unreliable app.
The /Shibboleth.sso/Status reports the following even when it's using memory when it was told to use the db.
<SessionCache><OK/></SessionCache>
It would be great if the status handler would report it was faulty. (Or report the type in use mem/db/etc and allow the monitoring system polling the status page to alert that all wasn't well.