You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Stefan Guggisberg <st...@gmail.com> on 2006/11/01 17:50:07 UTC
Re: ItemManager warning
hi joshua
On 10/30/06, Joshua Levy <le...@csl.sri.com> wrote:
>
> I just got around to upgrading from 1.0.1 to 1.1, and am
> now seeing many "overwriting cached item" warnings.
> With debugging on,
>
> DEBUG org.apache.jackrabbit.core.ItemManager: created item
> 1211f27e-e83e-4fa6-a0bf-4323e5b89d5d
> DEBUG org.apache.jackrabbit.core.ItemManager: caching item
> 1211f27e-e83e-4fa6-a0bf-4323e5b89d5d
> ...
> DEBUG org.apache.jackrabbit.core.ItemManager: created item
> 1211f27e-e83e-4fa6-a0bf-4323e5b89d5d
> WARN org.apache.jackrabbit.core.ItemManager: overwriting cached item
> 1211f27e-e83e-4fa6-a0bf-4323e5b89d5d
> DEBUG org.apache.jackrabbit.core.ItemManager: caching item
> 1211f27e-e83e-4fa6-a0bf-4323e5b89d5d
>
> It seems to be related to the fact that we use the slightly
> messy trick of a custom-extended AccessManager that
> actually accesses permission properties stored on nodes.
> However, it was working fine with v. 1.0.1. (Then, the
> ItemManager logged only one item creation for each node id.)
>
> Is this logged at warning level for a reason, and worth
> worrying about? And any quick thoughts on what might have
> changed?
it's logged as warning because normally it shouldn't happen.
i'd say it's definitely something worth to further investigate.
i can't find the warning in my logs therefore i guess it's
related to your custom AccessManager code.
do you share the same session with multiple threads?
cheers
stefan
>
> Many thanks!
>
> Joshua
> --
> View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7080795
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: ItemManager warning
Posted by Joshua Levy <le...@csl.sri.com>.
Hi Stefan,
Stefan Guggisberg wrote:
>
>> Previously (v. 1.0.1), this method called the AccessManager
>> first, then checked the cache, then created the node if necessary.
>> Now it seems an optimization has been made where it checks
>> the cache first, and skips the access check if it is cached.
>> In our case, the node actually gets pulled into the cache
>> by a custom access manager, in between the cache check
>> and the creation of the item, hence the warning. But
>> more seriously, the access check might not even be
>> enforced later, since the node was added to the cache.
>>
>> It may not be a common need, but does it seems the old version
>> was much preferable for us. Also, if I understand it correctly, it
>> is a little risky using the cache to enforce the access
>> check, and this might affect others... For instance, couldn't
>> some access manager implementations revoke read access
>> even after an item has been read once previously in a
>> (perhaps long-lived) session? (In fact, the old implementation
>> seemed to accomodate this explicitly, as it evicted the node
>> from cache on access failure.)
>
> i checked the log, it was me committing the change in
> svn rev. 423448 ('avoid excessive privilege checking').
>
> the modification was a deliberate compromise between
> improved performance and somehow weakend access control.
>
> i agree with you that there could be an issue with revoked access.
> however, i don't think that it's a serious one since cached
> entries will be automatically flushed once they're gc'ed.
>
> unless an application keeps a hard reference to an Item instance
> the session's privileges will be reevaluated after the item got evicted
> via gc.
>
> feel free to create a jira issue if you don't agree.
>
I see, thanks. It seems like a good optimization for many
situations, but not certain ones, such as access managers
that wish to restrict based on quotas, time of day, or keep
audit trails, and where the access manager might affect
the cache.
I'll look for a workaround (suggestions are welcome ;), but
might also file the issue. Maybe there could be a config option,
off by default, for "aggresive" access checks.
Cheers,
Joshua
--
View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7141566
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: ItemManager warning
Posted by Stefan Guggisberg <st...@gmail.com>.
hi josh,
On 11/2/06, Joshua Levy <le...@csl.sri.com> wrote:
>
> Hi Stefan,
>
>
> Stefan Guggisberg wrote:
> >
> >> Is this logged at warning level for a reason, and worth
> >> worrying about? And any quick thoughts on what might have
> >> changed?
> >
> > it's logged as warning because normally it shouldn't happen.
> > i'd say it's definitely something worth to further investigate.
> > i can't find the warning in my logs therefore i guess it's
> > related to your custom AccessManager code.
> >
> > do you share the same session with multiple threads?
> >
>
> On closer inspection, it seems the issue is in
> ItemManager.getItem(ItemId).
>
> Previously (v. 1.0.1), this method called the AccessManager
> first, then checked the cache, then created the node if necessary.
> Now it seems an optimization has been made where it checks
> the cache first, and skips the access check if it is cached.
> In our case, the node actually gets pulled into the cache
> by a custom access manager, in between the cache check
> and the creation of the item, hence the warning. But
> more seriously, the access check might not even be
> enforced later, since the node was added to the cache.
>
> It may not be a common need, but does it seems the old version
> was much preferable for us. Also, if I understand it correctly, it
> is a little risky using the cache to enforce the access
> check, and this might affect others... For instance, couldn't
> some access manager implementations revoke read access
> even after an item has been read once previously in a
> (perhaps long-lived) session? (In fact, the old implementation
> seemed to accomodate this explicitly, as it evicted the node
> from cache on access failure.)
i checked the log, it was me committing the change in
svn rev. 423448 ('avoid excessive privilege checking').
the modification was a deliberate compromise between
improved performance and somehow weakend access control.
i agree with you that there could be an issue with revoked access.
however, i don't think that it's a serious one since cached
entries will be automatically flushed once they're gc'ed.
unless an application keeps a hard reference to an Item instance
the session's privileges will be reevaluated after the item got evicted
via gc.
feel free to create a jira issue if you don't agree.
cheers
stefan
>
> Thanks again.
>
> Cheers,
> Joshua
>
> --
> View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7128759
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>
Re: ItemManager warning
Posted by Joshua Levy <le...@csl.sri.com>.
Hi Stefan,
Stefan Guggisberg wrote:
>
>> Is this logged at warning level for a reason, and worth
>> worrying about? And any quick thoughts on what might have
>> changed?
>
> it's logged as warning because normally it shouldn't happen.
> i'd say it's definitely something worth to further investigate.
> i can't find the warning in my logs therefore i guess it's
> related to your custom AccessManager code.
>
> do you share the same session with multiple threads?
>
On closer inspection, it seems the issue is in
ItemManager.getItem(ItemId).
Previously (v. 1.0.1), this method called the AccessManager
first, then checked the cache, then created the node if necessary.
Now it seems an optimization has been made where it checks
the cache first, and skips the access check if it is cached.
In our case, the node actually gets pulled into the cache
by a custom access manager, in between the cache check
and the creation of the item, hence the warning. But
more seriously, the access check might not even be
enforced later, since the node was added to the cache.
It may not be a common need, but does it seems the old version
was much preferable for us. Also, if I understand it correctly, it
is a little risky using the cache to enforce the access
check, and this might affect others... For instance, couldn't
some access manager implementations revoke read access
even after an item has been read once previously in a
(perhaps long-lived) session? (In fact, the old implementation
seemed to accomodate this explicitly, as it evicted the node
from cache on access failure.)
Thanks again.
Cheers,
Joshua
--
View this message in context: http://www.nabble.com/ItemManager-warning-tf2541411.html#a7128759
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.