You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by domfarr <do...@gmail.com> on 2014/09/25 09:28:08 UTC
CacheExceptions
I have a question about handling org.apache.shiro.cache.CacheException.
What is shiro's responsibility when a cache exception occurs? This RTE
ripples through the whole stack, but I'm unclear where it is handled and in
what manner. Can a shiro enabled web application recover? Is the cache
manager reinitialised? Do I have to restart?
For example, a timeout exception or a failed to connect to node exception
occurs on cache.get(key). What's the expected outcome apart from bubble to
the stop and die?
Thanks
--
View this message in context: http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: CacheExceptions
Posted by Dominic Farr <do...@gmail.com>.
sticky this one...as you said, Caching isn't a security feature, so why
would shiro do anything.
shiro wants to retrieve something; if that data comes via a cache or from
the underlying data store, perhaps because of a cache error, the retrieval
should be opaque to shiro, no?
-d
On 26 September 2014 22:10, Les Hazlewood <lh...@apache.org> wrote:
> I'm thinking that the Realm level should catch CacheExceptions (and log
> them to warn or something). This is because a Cache is not a critical part
> of the framework - i.e. if it doesn't work, you just access the underlying
> data store. This isn't great for performance, but at least things would
> function. Thoughts?
>
> In general, Shiro's philosophy is that all exceptions are Runtime to allow
> you to catch exceptions when you want so you're not forced to do so all the
> time.
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
> On Fri, Sep 26, 2014 at 2:01 PM, Dominic Farr <do...@gmail.com>
> wrote:
>
>> The CacheException is RTE, so no call stack methods are required to
>> catch and some calls are far from the actual throw code and might not be
>> fully aware of this RTE.
>>
>> What this means is if an operation fails, and you haven't correctly
>> protected your top level web from uncaught exceptions, the fail hits the
>> browser and ugly error. (this was the die part - a little melodramatic
>> perhaps)
>>
>> If the operations is say, node unavailable, then your cache
>> implementation is unhealthy and no amount of retry is going to help.
>>
>> Shiro doesn't handle any ShiroCache Exceptions from what I can tell, so
>> it is left to the developer to figure out a strategy.
>>
>> What is the community consensus on handling CacheExceptions?
>>
>> Thanks
>> Dom
>>
>>
>> On 26 September 2014 18:47, Les Hazlewood <lh...@apache.org> wrote:
>>
>>> What do you mean 'die'? Wouldn't that particular operation just fail?
>>>
>>> I'd be happy to hear what people want the behavior to be - we can always
>>> improve.
>>>
>>> --
>>> Les Hazlewood | @lhazlewood
>>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>>>
>>> On Thu, Sep 25, 2014 at 12:28 AM, domfarr <do...@gmail.com> wrote:
>>>
>>>> I have a question about handling org.apache.shiro.cache.CacheException.
>>>>
>>>> What is shiro's responsibility when a cache exception occurs? This RTE
>>>> ripples through the whole stack, but I'm unclear where it is handled
>>>> and in
>>>> what manner. Can a shiro enabled web application recover? Is the cache
>>>> manager reinitialised? Do I have to restart?
>>>>
>>>> For example, a timeout exception or a failed to connect to node
>>>> exception
>>>> occurs on cache.get(key). What's the expected outcome apart from bubble
>>>> to
>>>> the stop and die?
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html
>>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>
>
Re: CacheExceptions
Posted by Les Hazlewood <lh...@apache.org>.
I'm thinking that the Realm level should catch CacheExceptions (and log
them to warn or something). This is because a Cache is not a critical part
of the framework - i.e. if it doesn't work, you just access the underlying
data store. This isn't great for performance, but at least things would
function. Thoughts?
In general, Shiro's philosophy is that all exceptions are Runtime to allow
you to catch exceptions when you want so you're not forced to do so all the
time.
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Fri, Sep 26, 2014 at 2:01 PM, Dominic Farr <do...@gmail.com> wrote:
> The CacheException is RTE, so no call stack methods are required to catch
> and some calls are far from the actual throw code and might not be fully
> aware of this RTE.
>
> What this means is if an operation fails, and you haven't correctly
> protected your top level web from uncaught exceptions, the fail hits the
> browser and ugly error. (this was the die part - a little melodramatic
> perhaps)
>
> If the operations is say, node unavailable, then your cache implementation
> is unhealthy and no amount of retry is going to help.
>
> Shiro doesn't handle any ShiroCache Exceptions from what I can tell, so it
> is left to the developer to figure out a strategy.
>
> What is the community consensus on handling CacheExceptions?
>
> Thanks
> Dom
>
>
> On 26 September 2014 18:47, Les Hazlewood <lh...@apache.org> wrote:
>
>> What do you mean 'die'? Wouldn't that particular operation just fail?
>>
>> I'd be happy to hear what people want the behavior to be - we can always
>> improve.
>>
>> --
>> Les Hazlewood | @lhazlewood
>> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>>
>> On Thu, Sep 25, 2014 at 12:28 AM, domfarr <do...@gmail.com> wrote:
>>
>>> I have a question about handling org.apache.shiro.cache.CacheException.
>>>
>>> What is shiro's responsibility when a cache exception occurs? This RTE
>>> ripples through the whole stack, but I'm unclear where it is handled and
>>> in
>>> what manner. Can a shiro enabled web application recover? Is the cache
>>> manager reinitialised? Do I have to restart?
>>>
>>> For example, a timeout exception or a failed to connect to node exception
>>> occurs on cache.get(key). What's the expected outcome apart from bubble
>>> to
>>> the stop and die?
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html
>>> Sent from the Shiro User mailing list archive at Nabble.com.
>>>
>>
>>
>
Re: CacheExceptions
Posted by Dominic Farr <do...@gmail.com>.
The CacheException is RTE, so no call stack methods are required to catch
and some calls are far from the actual throw code and might not be fully
aware of this RTE.
What this means is if an operation fails, and you haven't correctly
protected your top level web from uncaught exceptions, the fail hits the
browser and ugly error. (this was the die part - a little melodramatic
perhaps)
If the operations is say, node unavailable, then your cache implementation
is unhealthy and no amount of retry is going to help.
Shiro doesn't handle any ShiroCache Exceptions from what I can tell, so it
is left to the developer to figure out a strategy.
What is the community consensus on handling CacheExceptions?
Thanks
Dom
On 26 September 2014 18:47, Les Hazlewood <lh...@apache.org> wrote:
> What do you mean 'die'? Wouldn't that particular operation just fail?
>
> I'd be happy to hear what people want the behavior to be - we can always
> improve.
>
> --
> Les Hazlewood | @lhazlewood
> CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
>
> On Thu, Sep 25, 2014 at 12:28 AM, domfarr <do...@gmail.com> wrote:
>
>> I have a question about handling org.apache.shiro.cache.CacheException.
>>
>> What is shiro's responsibility when a cache exception occurs? This RTE
>> ripples through the whole stack, but I'm unclear where it is handled and
>> in
>> what manner. Can a shiro enabled web application recover? Is the cache
>> manager reinitialised? Do I have to restart?
>>
>> For example, a timeout exception or a failed to connect to node exception
>> occurs on cache.get(key). What's the expected outcome apart from bubble to
>> the stop and die?
>>
>> Thanks
>>
>>
>>
>> --
>> View this message in context:
>> http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html
>> Sent from the Shiro User mailing list archive at Nabble.com.
>>
>
>
Re: CacheExceptions
Posted by Les Hazlewood <lh...@apache.org>.
What do you mean 'die'? Wouldn't that particular operation just fail?
I'd be happy to hear what people want the behavior to be - we can always
improve.
--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
On Thu, Sep 25, 2014 at 12:28 AM, domfarr <do...@gmail.com> wrote:
> I have a question about handling org.apache.shiro.cache.CacheException.
>
> What is shiro's responsibility when a cache exception occurs? This RTE
> ripples through the whole stack, but I'm unclear where it is handled and in
> what manner. Can a shiro enabled web application recover? Is the cache
> manager reinitialised? Do I have to restart?
>
> For example, a timeout exception or a failed to connect to node exception
> occurs on cache.get(key). What's the expected outcome apart from bubble to
> the stop and die?
>
> Thanks
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/CacheExceptions-tp7580255.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>