Announce: Database Backed Storage Service

[Wessel, Keith]

Thanks, Paul. Seems like a reasonable starting point.

I did enable debug logging this morning before I emailed the list for the usual edu.internet2.middleware.shibboleth, org.opensaml, and edu.vt.middleware.ldap. Yeah, I know those last two were overkill.

But I don't see the debug log entry you're ferring to. What should I be logging at debug level that I'm not?

Thanks,
Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Wednesday, January 08, 2014 12:18 PM
To: Shib Users
Subject: Re: Announce: Database Backed Storage Service

Keith,

The storage engine is grabbing whatever value is stored by Shib as the PrincipalName to put into the login ID field. Since its storing the expire time, then it has to be the full SessionManagerEntry object that its getting. So that implies there is no PrincipalName being set in that object.

I don't see any useful debug statements in the code that could be enabled at the trace level, just what it already prints at debug, which is not a lot of detail on the object internals. Now, there is this line:

log.debug("New persistent session save to db [{}]", s.getLoginId());


So object "s" represents the data that was just written to the DB. I don't have a statement to tie that to the session ID though. If you can see it in your test environment, you could enable debug and log a single transaction. Still not sure that would point to what's wrong. I don't think it's the storage service code, but don't see a way to tell either.

Paul


On 1/8/14 12:55 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Paul and others,
>
>One more email, and I think we'll be good to go with this excellent 
>addition to the IDP.
>
>We put this in production last night, and everything seems to be going 
>to the database fine with one significant exception: login_id is not 
>being populated. Of course, with out that, the other IDP node can't do 
>much with an existing session.
>
>I know SSO is working within the same node, so it's something with it 
>being written to the database. The session is being created with the 
>correct session_id and session_expire_time columns in the database...
>just no login_id.
>
>Oddly, I'm now seeing this behavior on our test environment, too, and I 
>know login_id was being populated yesterday when I was dealing with the 
>other objects logging to the database that correctly had null login IDs.
>
>Before I go pointing fingers at our DBA for accidentally changing 
>something in the database when the extra scheduled procedure for 
>deleting rows when the create_date was old enough and there was no 
>session_expire_time, I'm trying to find something else to check here.
>
>Any suggestions why login_id might not be getting populated in the 
>database?
>
>Thanks,
>Keith
>
>
>-----Original Message-----
>From: Wessel, Keith
>Sent: Monday, January 06, 2014 4:16 PM
>To: 'Shib Users'
>Subject: RE: Announce: Database Backed Storage Service
>
>Thanks, Paul. This is what I suspected.
>
>We'll add that to the stored procedure for removing the rows with 
>session_expire_times in the past that don't get cleaned up 
>automatically, and we should be all set.
>
>Keith
>
>-----Original Message-----
>From: users-bounces at shibboleth.net 
>[mailto:users-bounces at shibboleth.net]
>On Behalf Of Paul Hethmon
>Sent: Monday, January 06, 2014 4:01 PM
>To: Shib Users
>Subject: Re: Announce: Database Backed Storage Service
>
>Keith,
>
>I just looked back over the code and I see two different Java objects I
>recognize:
>
>1. SessionManagerEntry. This one has an expire time and login ID in the 
>object and both are stored.
>2. SessionID. This one does not have an expire time or login ID value. 
>So I just save the object itself.
>
>If I get anything else passed to me, I just store it as a blob. In that 
>case, it won't have a value in the session ID column.
>
>>From memory, I think Shib stores the session under three different 
>>index
>values. At least if you have the SLO stuff installed (the original from 
>Hungary).
>
>I'm thinking the algorithm would be to delete those that are blank and 
>the create date is in the past, longer than your session time setting.
>Overall, the worst you can do is cause the user to have to login again.
>
>Paul
>
>On 1/6/14 3:42 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:
>
>>Paul,
>>
>>I've been doing some further experimenting with this, and hopefully 
>>it'll help explain something.
>>
>>First, seems to do no harm to delete the rows with no 
>>session_expire_time while the session is still valid. The other IDP 
>>node still recognizes the session.
>>
>>As for why they're being created, I still can't grasp that. They have 
>>th same session_id from the IDP as the other row that has a valid 
>>session_expire_time. But in addition to missing a session_expire_time, 
>>they're also missing a login_id. I seem to get two of these odd rows 
>>in addition to the valid row when a user logs in and creates a new session.
>>Then, each time the user hits the IDP while the session is still 
>>valid, I get another of these odd rows.
>>
>>Any thoughts?
>>
>>Keith
>>
>>
>>-----Original Message-----
>>From: users-bounces at shibboleth.net 
>>[mailto:users-bounces at shibboleth.net]
>>On Behalf Of Wessel, Keith
>>Sent: Thursday, January 02, 2014 3:14 PM
>>To: Shib Users
>>Subject: RE: Announce: Database Backed Storage Service
>>
>>Paul,
>>
>>We're finally getting ready to put the database stored session code in 
>>production next week, insufficient load testing held us up longer than 
>>we'd hoped.
>>
>>I do need to reserect this old thread once more, though. I ran into 
>>one little issue. Looking back at our database, I see a hand full of 
>>rows where the session_expire_time is null. Seems these are perhaps 
>>insignificant. But before I jump to conclusions, have you seen this? 
>>Is it a sign of a problem? And if it isn't, can we add to our stored 
>>procedure that deletes orphaned rows? Right now, it deletes orphaned 
>>rows for sessions that have expired. Can it also delete orphaned rows 
>>where the session_expire_time is null? Or do we need to be smarter and 
>>delete rows where the expire time is null and the create date is 
>>significantly in the past?
>>
>>Thanks,
>>Keith
>>
>>
>>-----Original Message-----
>>From: Wessel, Keith
>>Sent: Monday, October 21, 2013 10:15 AM
>>To: Shib Users
>>Subject: RE: Announce: Database Backed Storage Service
>>
>>Perfect. Thanks.
>>
>>Keith
>>
>>
>>-----Original Message-----
>>From: users-bounces at shibboleth.net 
>>[mailto:users-bounces at shibboleth.net]
>>On Behalf Of Paul Hethmon
>>Sent: Monday, October 21, 2013 10:06 AM
>>To: Shib Users
>>Subject: Re: Announce: Database Backed Storage Service
>>
>>Yep, that's all it does. The table has a column for session expire 
>>time, so it's just delete any where that time has passed, padding it a 
>>bit. So something like delete all rows where expire time is more than 
>>an hour old.
>>
>>Paul
>>
>>On 10/21/13 10:56 AM, "Wessel, Keith" <kwessel at illinois.edu> wrote:
>>
>>>Does your cleanup job just delete rows with a modify date older than 
>>>the max IDP session lifetime or something along those lines?
>>>
>>
>>--
>>To unsubscribe from this list send an email to 
>>users-unsubscribe at shibboleth.net
>>--
>>To unsubscribe from this list send an email to 
>>users-unsubscribe at shibboleth.net
>>--
>>To unsubscribe from this list send an email to 
>>users-unsubscribe at shibboleth.net
>
>--
>To unsubscribe from this list send an email to 
>users-unsubscribe at shibboleth.net
>--
>To unsubscribe from this list send an email to 
>users-unsubscribe at shibboleth.net

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net