Apparently my commit for the orphan/validation fix caused hudson to fail so there is no recent snapshot with that fix yet.
The hudson build farm is pretty unreliable so I just kicked off another build. If it succeeds, the fix will be in the snapshot repository shortly. Cheers, Les On Wed, Oct 13, 2010 at 3:22 PM, Kalle Korhonen <[email protected]> wrote: > http://repository.apache.org/snapshots/org/apache/shiro/ > > Kalle > > On Wed, Oct 13, 2010 at 3:04 PM, Jim Newsham <[email protected]> wrote: >> >> Hi Les, >> >> Thanks for looking into that for me. So assuming I'm using a recent >> snapshot build, I understand that get a session listener callback on >> expiration. >> >> Are nightly snapshot builds available, or do I need to build from svn? >> >> Thanks, >> Jim >> >> >> On 10/13/2010 9:14 AM, Les Hazlewood wrote: >>> >>> I have committed a fix for the orphan problem to trunk (and added a >>> test case to ensure this won't happen again). Issue is here: >>> https://issues.apache.org/jira/browse/SHIRO-199 >>> >>> Please use 1.1-SNAPSHOT builds until 1.1 is released. >>> >>> Cheers, >>> >>> Les >>> >>> On Wed, Oct 13, 2010 at 11:27 AM, Les Hazlewood<[email protected]> >>> wrote: >>>> >>>> Shiro has two ways of expiring sessions. First, it lazily checks each >>>> session the session is accessed. Second, it checks actively all >>>> sessions with a session validation thread (the >>>> AbstractValidatingSessionManager accepts a SessionValidationScheduler >>>> property. By default, that instance is an >>>> ExecutorServiceSessionValidationScheduler). >>>> >>>> By default, this thread runs only once an hour - you can customize it >>>> based on your needs and your application's performance profile >>>> (running too often could affect application performance, running too >>>> infrequently could cause too many orphans and incur a long validation >>>> phase). >>>> >>>> Its primary purpose is to clean up any session orphans that might >>>> exist so there isn't a data/memory leak (if a user doesn't log out >>>> explicitly, something has to clean up the orphans left behind). >>>> >>>> However, by looking at the code, I think there may be a bug - the >>>> validation scheduler will indeed validate the sessions, but it looks >>>> as if it might not be removing orphans! I'll open an issue in trunk >>>> and verify this right away with a test case. >>>> >>>> Anyway, to answer your question, if you want to set a different >>>> validation interval, you can do it by setting the >>>> 'sessionValidationInterval' property on an >>>> AbstractValidatingSessionManager instance. >>>> >>>> For example, if using shiro.ini (assuming native sessions are already >>>> turned on): >>>> >>>> securityManager.sessionManager.sessionValidationInterval = >>>> millisecondsValue >>>> >>>> HTH, >>>> >>>> -- >>>> Les Hazlewood >>>> Founder, Katasoft, Inc. >>>> Application Security Products& Professional Apache Shiro Support and >>>> Training: >>>> http://www.katasoft.com >>>> >>>> On Tue, Oct 12, 2010 at 7:25 PM, Jim Newsham<[email protected]> >>>> wrote: >>>>> >>>>> I'm using shiro on the server side of a client/server app. The sessions >>>>> on >>>>> the server side are managed by shiro. I have some resources which live >>>>> outside of the session object, which I'd like to clean up when the >>>>> client is >>>>> gone. I was hoping to add a SessionListener to shiro, so that I could >>>>> rely >>>>> on shiro to tell me when the session is expired. However, I see that >>>>> shiro >>>>> expires the session lazily -- if I'm not accessing the session, I don't >>>>> get >>>>> an expiration event. >>>>> >>>>> - Does shiro *ever* actively check for session expiration, and if so, >>>>> how >>>>> can I configure the interval? >>>>> - Or is that something I would have to do? If so, how? Where is the >>>>> SessionManager.expireSessions() method? :) >>>>> >>>>> Thanks, >>>>> Jim >>>>> >>>>> >> >> >
