jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@day.com>
Subject Re: Modified externally exception due to eviction from shared ism cache
Date Mon, 17 May 2010 19:46:13 GMT

I just stumbled over the method
AbstractBundlePersistenceManager.load(PropertyId), which I think might
be related to this issue.

what if the items states in the SISM indeed get cleared because the
local item states go into the change log? I guess this is more likely
the bigger the change set is, right?

usually, this is not a problem because the item states are reconnected
with possibly new ones loaded from the persistence manager. now the
problem with above mentioned method could be the way it loads the
jcr:mixinTypes property. the property is not stored as a regular
property. the names are serialized with the node and the property is
created on the fly and always with modCount 0 (I think).


I think there is also another issue with that method. the
jcr:mixinTypes property always seems to exist from the persistence
manager POV. IIUC, it will create a property with an empty value array
even if there is no mixin types set.


On Mon, May 10, 2010 at 10:29 AM, Stefan Guggisberg
<stefan.guggisberg@day.com> wrote:
> 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.
> cheers
> stefan
>> With kind regards,
>> Berry van Halderen

View raw message