jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: ItemManager warning
Date Thu, 02 Nov 2006 10:06:38 GMT
hi josh,

On 11/2/06, Joshua Levy <levy@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.
>
>

Mime
View raw message