[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
 ] 

Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:34 PM:
---

Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
Fixed in 2.8 with r1721216


was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
 ] 

Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:35 PM:
---

Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.


was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205
Fixed in 2.8 with r1721216

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
 ] 

Manfred Baedke edited comment on JCR-2633 at 12/21/15 6:49 PM:
---

Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.
Fixed in 2.6 with r1721233.


was (Author: baedke):
Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205.
Fixed in 2.8 with r1721216.

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Baedke updated JCR-2633:

Fix Version/s: 2.6.7

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.6.7, 2.8.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 638 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#638)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/638/ to view 
the results.

Changes:
[reschke] OAK-3662: add bulk createOrUpdate method to the DocumentStore API

[chetanm] OAK-301 : oak docu

[reschke] OAK-3816: RDBBlobStoreTest should use named parameters

 

Test results:
12 tests failed.
FAILED:  org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV

Error Message:
expected: but was:

Stack Trace:
junit.framework.ComparisonFailure: expected: but was:
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at 
org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV(FacetTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


FAILED:  
org.apache.jackrabbit.oak.jcr.query.FacetTest.testMultipleFacetsRetrieval

Error Message:
expected: but 
was:

Stack Trace:
junit.framework.ComparisonFailure: expected: but was:
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at 
org.apache.jackrabbit.oak.jcr.query.FacetTest.testMultipleFacetsRetrieval(FacetTest.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 640 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#640)

Status: Still Failing

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/640/ to view 
the results.

Changes:
[reschke] OAK-3816: RDBBlobStoreTest should use named parameters (ported to 1.0)

 

Test results:
All tests passed

Fwd: new atomicCounter support (OAK-2220)

[Torgeir Veimo]

Can someone confirm if the atomic counter support code is suitable for
sequences?

https://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditor.html

If my reading of the spec is correct, separate sessions will see their
results from the increment immediately and isolated from other sessions
incrementing the same counter, so using the results from an increment can
safely be used as a sequence number as long as the counter is ever
incremented in any code?

On 13 November 2015 at 14:40, Torgeir Veimo  wrote:

> Am trying to use the new atomicSupport feature, and am wondering if I'm
> using it the correct way;
>
> My counter is initialised with
>
> Node counter = JcrUtils.getOrCreateByPath("/testCounter",
> "oak:Unstructured", session);
> if (counter.isNew()) {
>   counter.addMixin("mix:atomicCounter");
>   session.save();
> }
>
> then when fetching a new value
>
> counter.setProperty("oak:increment", 1);
> session.save();
> long value = counter.getProperty("oak:counter").getLong();
>
> What happens if the same code is called from a different thread / session
> after the session.save() but before the getProperty() call? Will the value
> remain unchanged in this thread / session?
>
> --
> -Tor
>



-- 
-Tor



-- 
-Tor

jackrabbit-oak build #7093: Errored

[Travis CI]

Build Update for apache/jackrabbit-oak
-

Build: #7093
Status: Errored

Duration: 1943 seconds
Commit: 4d5b5b2b10a18666f3a02d9ad982e087fdb56a3c (trunk)
Author: Julian Reschke
Message: OAK-3816: RDBBlobStoreTest should use named parameters

git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1721172 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/f778f1365d46...4d5b5b2b10a1

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/98139970

--
sent by Jukka's Travis notification gateway

Jackrabbit-trunk - Build # 2340 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2340)

Status: Failure

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2340/ to 
view the results.

[jira] [Commented] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
 ] 

Manfred Baedke commented on JCR-2633:
-

Fixed in trunk with r1721196.

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Baedke resolved JCR-2633.
-
   Resolution: Fixed
Fix Version/s: 2.10.2

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

jackrabbit-oak build #7090: Fixed

[Travis CI]

Build Update for apache/jackrabbit-oak
-

Build: #7090
Status: Fixed

Duration: 2232 seconds
Commit: 7594b930964e56014e377b73e42672f9cf2384ab (1.2)
Author: Julian Reschke
Message: OAK-3662: add bulk createOrUpdate method to the DocumentStore API 
(ported to 1.2)

(applied tomekr's patch with minor Javadoc improvements)

git-svn-id: 
https://svn.apache.org/repos/asf/jackrabbit/oak/branches/1.2@1721167 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/fb0ddd0a11c1...7594b930964e

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/98129016

--
sent by Jukka's Travis notification gateway

[jira] [Comment Edited] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15066582#comment-15066582
 ] 

Manfred Baedke edited comment on JCR-2633 at 12/21/15 4:16 PM:
---

Fixed in trunk with r1721196.
Fixed in 2.10 with r1721205


was (Author: baedke):
Fixed in trunk with r1721196.

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-2633) Modified externally exception when modifying mixinTypes with single session

[Manfred Baedke (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Baedke updated JCR-2633:

Fix Version/s: 2.11.4

> Modified externally exception when modifying mixinTypes with single session
> ---
>
> Key: JCR-2633
> URL: https://issues.apache.org/jira/browse/JCR-2633
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Affects Versions: 1.5.7, 2.0, 2.1
> Environment: Bundle persistency manager based storage, Jackrabbit 
> 1.5.7 but issue also present in newer versions
>Reporter: Berry van Halderen
>Assignee: Manfred Baedke
>Priority: Critical
> Fix For: 2.10.2, 2.11.4
>
> Attachments: holdrefs.patch, issue.patch, persistMixinTypes.patch
>
>
> When first adding mixins and later removing all mixins, a system under heavy 
> stress might experience a modified externally exception even though there is 
> only a single session into the repository.
> The unit test with forced GC and shrinking of caches indicates the problem.
> The unit test itself is mostly trivial, the problem arrises when you add a
> mixin to a node, save it, do this again with another mixin and then remove
> both mixins and in the following save the shared item state cache is shrunk,
> and the garbage collectors hits at exactly the right time.  In the unit test a
> reference to the jcr:mixinTypes property must have been held.
> What will happen is that the ItemState of the jcr:mixinTypes property will get
> a modification count higher than 0 when addin the mixins.  Because a reference
> to the property is kept, it will not be evicted from the primary cache in the
> local item state manager.  When removing all mixins, an overlayed state will
> be created of this ItemState.  Because the state and overlayed state are
> linked, the ItemState won't be dropped from the primary cache of the shared
> item state manager.
> But is MAY be evicted from the secondary cache implementing the LRU/FIFO
> functionality.  If this is the case when while persisting the changes there is
> a small window where the overlayed state will be disconnected from the state.
> This happens just before collecting the changelog at:
>   o.a.j.c.state.ItemState.disconnect():211
>   o.a.j.c.state.SessionItemStateManager.disconnectTransientItemState():674
>   o.a.j.c.PropertyImpl.makePersistent():143
>   o.a.j.c.ItemImpl.persistTransientItems():609
>   o.a.j.c.ItemImpl.save():1087
>   o.a.j.c.SessionImpl.save():858
> Or in the when actually collecting the changelog in one of the methods
> Changelog.{modified(),deleted() or both.  I think the latter, but not really
> sure.
> In any case, this breaks the bondage that prevents the cached state in the
> shared item state manager.
> Now if the shared item state cache has been shrunk enough and the GC hits
> before o.a.j.c.state.SharedItemStateManager.Update.begin():650 when the
> disconnected state will be purged from the shared item state cache.  Just
> below line 650 the check for stale items will then cause a re-retrieval from
> the persisted store of the property.  Because that state will have a
> modification count of 0, it will conflict with the modification count of the
> mixin property type that is being persisted.
> It is true that the GC needs to go off at exactly the right time and the
> secondary cache needs to have shrunk to be able to evict the item.  This can
> however happen in extreme cases.  The patch that contains the unit test
> contains code that will force the purging of the item.
> There is still the matter why the modcount comes back at 0 when retrieving the
> property from the persistence manager, basically the assumption made in the
> code between session, local, and shared item state managers, their caches,
> etcetera is that the modification count in the shared item state is always
> incremented, and never reset.
> There is an apparent contract (partially documented) that the modification
> count is to be persisted.  Which is in fact the case for the InMemPersistence-
> Manager, but all bundle derived persistence managers do not persist the
> jcr:mixinType property at all, but just the mixintypes as part of the
> nodedefinition information.  This means that the jcr:mixinTypes property will
> always be re-created with modcount of 0, which leads to clashes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)