You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Philippe Laflamme <tw...@gmail.com> on 2010/01/28 03:56:44 UTC
Shutting down Shiro
Hi all,
I'm using Shiro for a command line application. I'm instantiating the
SecurityManager exactly how it is specified on the wiki:
Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);
After authenticating a user, a new thread is spawned. Seems to be related to
the default session management code. The problem I have is that this thread
is never stopped, and so my command line never exists.
I've found that the solution is to invoke destroy on the SecurityManager
instance. Since the method isn't part of the SecurityManager hierarchy, I've
delegated the call to the LifecycleUtils class:
LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
This works fine, but I'm wondering if this is the suggested/correct pattern.
It wasn't obvious, I had to inspect Shiro code. What's the recommended
approach?
Thanks,
Philippe
--
View this message in context: http://n2.nabble.com/Shutting-down-Shiro-tp4471207p4471207.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shutting down Shiro
Posted by Les Hazlewood <lh...@apache.org>.
I know this is a little late, but it looks good to me!
Cheers,
Les
On Fri, Jan 29, 2010 at 4:54 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Fixed in the trunk, but there's no test for it. Les, you might want to
> look over it. It's not technically difficult to write a test for it
> but I didn't want to write it as part of this core module since it
> would require changing the unit test execution model to spawn a new
> process for each test. Added a TODO instead to implement the test as
> part of the standalone sample.
>
> Kalle
>
>
> On Fri, Jan 29, 2010 at 6:21 AM, Les Hazlewood <lh...@apache.org> wrote:
>> That should would work too :)
>>
>> On Thu, Jan 28, 2010 at 7:49 PM, Jason Eacott <ja...@hardlight.com.au> wrote:
>>> why not just mark the thread as daemon and fix it that way?
>>>
>>> Les Hazlewood wrote:
>>>>
>>>> Hi Phillipe,
>>>>
>>>> Ideally this should shut down without any problems. When Shiro
>>>> discovers that you need Sessions, it automatically kicks off a thread
>>>> to perform session validation at a regular interval to prevent
>>>> orphaned sessions from eating up memory.
>>>>
>>>> So yes, the LifecycleUtils.destroy method will definitely work and is
>>>> a good solution, but I think a more elegant solution might be to apply
>>>> a Runtime hook to shut down the thread automatically. Could you
>>>> please open a Jira issue for this?
>>>>
>>>> Thanks,
>>>>
>>>> Les
>>>>
>>>> On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <tw...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi all, I'm using Shiro for a command line application. I'm instantiating
>>>>> the SecurityManager exactly how it is specified on the wiki:
>>>>>
>>>>> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
>>>>> SecurityManager securityManager = factory.getInstance();
>>>>> SecurityUtils.setSecurityManager(securityManager);
>>>>>
>>>>> After authenticating a user, a new thread is spawned. Seems to be related
>>>>> to
>>>>> the default session management code. The problem I have is that this
>>>>> thread
>>>>> is never stopped, and so my command line never exists. I've found that
>>>>> the
>>>>> solution is to invoke destroy on the SecurityManager instance. Since the
>>>>> method isn't part of the SecurityManager hierarchy, I've delegated the
>>>>> call
>>>>> to the LifecycleUtils class:
>>>>>
>>>>> LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
>>>>>
>>>>> This works fine, but I'm wondering if this is the suggested/correct
>>>>> pattern.
>>>>> It wasn't obvious, I had to inspect Shiro code. What's the recommended
>>>>> approach? Thanks, Philippe
>>>>> ________________________________
>>>>> View this message in context: Shutting down Shiro
>>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>>
>>>>
>>>
>>
>
Re: Shutting down Shiro
Posted by Kalle Korhonen <ka...@gmail.com>.
Fixed in the trunk, but there's no test for it. Les, you might want to
look over it. It's not technically difficult to write a test for it
but I didn't want to write it as part of this core module since it
would require changing the unit test execution model to spawn a new
process for each test. Added a TODO instead to implement the test as
part of the standalone sample.
Kalle
On Fri, Jan 29, 2010 at 6:21 AM, Les Hazlewood <lh...@apache.org> wrote:
> That should would work too :)
>
> On Thu, Jan 28, 2010 at 7:49 PM, Jason Eacott <ja...@hardlight.com.au> wrote:
>> why not just mark the thread as daemon and fix it that way?
>>
>> Les Hazlewood wrote:
>>>
>>> Hi Phillipe,
>>>
>>> Ideally this should shut down without any problems. When Shiro
>>> discovers that you need Sessions, it automatically kicks off a thread
>>> to perform session validation at a regular interval to prevent
>>> orphaned sessions from eating up memory.
>>>
>>> So yes, the LifecycleUtils.destroy method will definitely work and is
>>> a good solution, but I think a more elegant solution might be to apply
>>> a Runtime hook to shut down the thread automatically. Could you
>>> please open a Jira issue for this?
>>>
>>> Thanks,
>>>
>>> Les
>>>
>>> On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <tw...@gmail.com>
>>> wrote:
>>>>
>>>> Hi all, I'm using Shiro for a command line application. I'm instantiating
>>>> the SecurityManager exactly how it is specified on the wiki:
>>>>
>>>> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
>>>> SecurityManager securityManager = factory.getInstance();
>>>> SecurityUtils.setSecurityManager(securityManager);
>>>>
>>>> After authenticating a user, a new thread is spawned. Seems to be related
>>>> to
>>>> the default session management code. The problem I have is that this
>>>> thread
>>>> is never stopped, and so my command line never exists. I've found that
>>>> the
>>>> solution is to invoke destroy on the SecurityManager instance. Since the
>>>> method isn't part of the SecurityManager hierarchy, I've delegated the
>>>> call
>>>> to the LifecycleUtils class:
>>>>
>>>> LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
>>>>
>>>> This works fine, but I'm wondering if this is the suggested/correct
>>>> pattern.
>>>> It wasn't obvious, I had to inspect Shiro code. What's the recommended
>>>> approach? Thanks, Philippe
>>>> ________________________________
>>>> View this message in context: Shutting down Shiro
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>
>>>
>>
>
Re: Shutting down Shiro
Posted by Les Hazlewood <lh...@apache.org>.
That should would work too :)
On Thu, Jan 28, 2010 at 7:49 PM, Jason Eacott <ja...@hardlight.com.au> wrote:
> why not just mark the thread as daemon and fix it that way?
>
> Les Hazlewood wrote:
>>
>> Hi Phillipe,
>>
>> Ideally this should shut down without any problems. When Shiro
>> discovers that you need Sessions, it automatically kicks off a thread
>> to perform session validation at a regular interval to prevent
>> orphaned sessions from eating up memory.
>>
>> So yes, the LifecycleUtils.destroy method will definitely work and is
>> a good solution, but I think a more elegant solution might be to apply
>> a Runtime hook to shut down the thread automatically. Could you
>> please open a Jira issue for this?
>>
>> Thanks,
>>
>> Les
>>
>> On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <tw...@gmail.com>
>> wrote:
>>>
>>> Hi all, I'm using Shiro for a command line application. I'm instantiating
>>> the SecurityManager exactly how it is specified on the wiki:
>>>
>>> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
>>> SecurityManager securityManager = factory.getInstance();
>>> SecurityUtils.setSecurityManager(securityManager);
>>>
>>> After authenticating a user, a new thread is spawned. Seems to be related
>>> to
>>> the default session management code. The problem I have is that this
>>> thread
>>> is never stopped, and so my command line never exists. I've found that
>>> the
>>> solution is to invoke destroy on the SecurityManager instance. Since the
>>> method isn't part of the SecurityManager hierarchy, I've delegated the
>>> call
>>> to the LifecycleUtils class:
>>>
>>> LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
>>>
>>> This works fine, but I'm wondering if this is the suggested/correct
>>> pattern.
>>> It wasn't obvious, I had to inspect Shiro code. What's the recommended
>>> approach? Thanks, Philippe
>>> ________________________________
>>> View this message in context: Shutting down Shiro
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>
Re: Shutting down Shiro
Posted by Jason Eacott <ja...@hardlight.com.au>.
why not just mark the thread as daemon and fix it that way?
Les Hazlewood wrote:
> Hi Phillipe,
>
> Ideally this should shut down without any problems. When Shiro
> discovers that you need Sessions, it automatically kicks off a thread
> to perform session validation at a regular interval to prevent
> orphaned sessions from eating up memory.
>
> So yes, the LifecycleUtils.destroy method will definitely work and is
> a good solution, but I think a more elegant solution might be to apply
> a Runtime hook to shut down the thread automatically. Could you
> please open a Jira issue for this?
>
> Thanks,
>
> Les
>
> On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <tw...@gmail.com> wrote:
>> Hi all, I'm using Shiro for a command line application. I'm instantiating
>> the SecurityManager exactly how it is specified on the wiki:
>>
>> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
>> SecurityManager securityManager = factory.getInstance();
>> SecurityUtils.setSecurityManager(securityManager);
>>
>> After authenticating a user, a new thread is spawned. Seems to be related to
>> the default session management code. The problem I have is that this thread
>> is never stopped, and so my command line never exists. I've found that the
>> solution is to invoke destroy on the SecurityManager instance. Since the
>> method isn't part of the SecurityManager hierarchy, I've delegated the call
>> to the LifecycleUtils class:
>>
>> LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
>>
>> This works fine, but I'm wondering if this is the suggested/correct pattern.
>> It wasn't obvious, I had to inspect Shiro code. What's the recommended
>> approach? Thanks, Philippe
>> ________________________________
>> View this message in context: Shutting down Shiro
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
Re: Shutting down Shiro
Posted by Les Hazlewood <lh...@apache.org>.
Thank you!
On Thu, Jan 28, 2010 at 12:22 PM, Philippe Laflamme <tw...@gmail.com> wrote:
>
> Done: https://issues.apache.org/jira/browse/SHIRO-133
>
> Thanks!
> Philippe
> --
> View this message in context: http://n2.nabble.com/Shutting-down-Shiro-tp4471207p4474600.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
Re: Shutting down Shiro
Posted by Philippe Laflamme <tw...@gmail.com>.
Done: https://issues.apache.org/jira/browse/SHIRO-133
Thanks!
Philippe
--
View this message in context: http://n2.nabble.com/Shutting-down-Shiro-tp4471207p4474600.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Shutting down Shiro
Posted by Les Hazlewood <lh...@apache.org>.
Hi Phillipe,
Ideally this should shut down without any problems. When Shiro
discovers that you need Sessions, it automatically kicks off a thread
to perform session validation at a regular interval to prevent
orphaned sessions from eating up memory.
So yes, the LifecycleUtils.destroy method will definitely work and is
a good solution, but I think a more elegant solution might be to apply
a Runtime hook to shut down the thread automatically. Could you
please open a Jira issue for this?
Thanks,
Les
On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <tw...@gmail.com> wrote:
> Hi all, I'm using Shiro for a command line application. I'm instantiating
> the SecurityManager exactly how it is specified on the wiki:
>
> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini");
> SecurityManager securityManager = factory.getInstance();
> SecurityUtils.setSecurityManager(securityManager);
>
> After authenticating a user, a new thread is spawned. Seems to be related to
> the default session management code. The problem I have is that this thread
> is never stopped, and so my command line never exists. I've found that the
> solution is to invoke destroy on the SecurityManager instance. Since the
> method isn't part of the SecurityManager hierarchy, I've delegated the call
> to the LifecycleUtils class:
>
> LifecycleUtils.destroy(SecurityUtils.getSecurityManager());
>
> This works fine, but I'm wondering if this is the suggested/correct pattern.
> It wasn't obvious, I had to inspect Shiro code. What's the recommended
> approach? Thanks, Philippe
> ________________________________
> View this message in context: Shutting down Shiro
> Sent from the Shiro User mailing list archive at Nabble.com.
>