jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@day.com>
Subject Re: Modified externally exception due to eviction from shared ism cache
Date Mon, 10 May 2010 08:29:03 GMT
hi berry

On Mon, May 10, 2010 at 9:43 AM, Berry van Halderen
<b.vanhalderen@1hippo.com> wrote:
> With some specifc data sets we've been experiencing some modified
> externally exceptions in Jackrabbit 1.5.7.  I know that these are
> valid exception in cases, but now I've experiencing them in a single
> threaded, no observation, just one writing session (other dorment).
> The modified externally exceptions all happen on a save at the
> jcr:mixinTypes property, but it's not very deterministic.  With
> multiple runs it only happens between 25% to 5% of the runs (the more
> logging one puts in, the less frequent it occurs.  After checking my
> own code I've turned to the jackrabbit code to see it there might be
> an issue there.
> My first attempt to resolve the issue was to alight the
> o.a.j.c.NodeImpl.setMixinTypesProperty with the regular setProperty
> code as that seems to be out of sync, but without success.  Therefore
> I no longer think it is directly related to the jcr:mixinTypes
> property, just that I'm doing a lot (thousands) of addMixin,
> removeMixin.  There are other operations (copy nodes, properties set
> and intermediate save to flush state). Digging deeper I stumbled on
> the following thing that seems to be happening:
> - A property A gets retrieved.  It will be cached by both shared Item
> State Manager (ISM) and Local ISM.
> - Property A gets modified and saved, the modcount in the ItemState
> will be upped from the initial valie 0 to 1.
> - Now a lot of other operations occur, Property A will get older and
> older and will be evicted from local and shared ISM.
> - Now it does look like it that A can get evicted from the shared ISM,
> but not the local ISM.  This is unlikely, but this is what is in my
> logs.
> - Property A gets retrieved again from the same session, it is on the
> local ISM cache, with modcount 1.  It gets modified.
> - Now the session state is saved, to persist the state, the shared ISM
> retrieved the state from the persistence manager.
> - the initial modcount of this state will be 0 as it is re-retrieved.
> - the conflict now is that the changelog sent from the Local ISM
> contains a modcount of 1 for property A, while the related state for
> property A from the shared ISM has a modcount 0.  The verification to
> connect the two states will fail with a slate item state exception.
> Now I can probably fix it or discuss this, but before going into
> changing this, I'd like to verify with you all I've I'm not completely
> in the wrong on what is happening here.  Is there a crutial step or
> mechanism in place that I'm overlooking?

the SISM cache is reference-based, i.e. items are not evicted as long as they're
currently being referenced. items managed by the LISM do keep a reference
to the underlying (shared) item state.

from the top of my head... the only situation where a local item state
clears its
reference to the underlying shared state is when it is added to the change log.

if there's any chance to reproduce the issue with a junit case using
plain jackrabbit
i'll further investigate.


> With kind regards,
> Berry van Halderen

View raw message