ConcurrentModificationException during gc run
Hi, I got a ConcurrentModificationException while checking the 0.3 release. This didn't cause any test case to fail but was printed to the console. Michael Running org.apache.jackrabbit.oak.jcr.JcrTckTest java.util.ConcurrentModificationException at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131) at org.apache.jackrabbit.mk.store.DefaultRevisionStore.markBranches(DefaultRevisionStore.java:561) at org.apache.jackrabbit.mk.store.DefaultRevisionStore.gc(DefaultRevisionStore.java:497) at org.apache.jackrabbit.mk.store.DefaultRevisionStore$2.run(DefaultRevisionStore.java:159) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680)
[jira] [Updated] (OAK-163) Move the JCR TCK back to the integrationTesting profile
[
https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated OAK-163:
--
Attachment: 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch
The attached patch implements the proposed change.
Relevant build times (on my computer) after the patch is applied:
* 1:22 for {{mvn clean install -DskipTests}}
* 2:01 for {{mvn clean install}}
* 6:01 for {{mvn clean install -PintegrationTesting}}
Build time without the patch:
* 5:01 for {{mvn clean install}}
Move the JCR TCK back to the integrationTesting profile
---
Key: OAK-163
URL: https://issues.apache.org/jira/browse/OAK-163
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Priority: Minor
Labels: tck
Attachments:
0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch
In revision 1325811 the JCR TCK tests were moved from the integrationTesting
profile to a normal build. However, since then the execution time of the TCK
has grown to 3+ minutes, which is more than the rest of the Oak build
combined. To keep the build time down to at most a couple of minutes, I'd
like to move the TCK run back to the integrationTesting profile where it will
get executed only when explicitly requested (typically manually before a
commit or after one in a CI build).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ConcurrentModificationException during gc run
Hi Michi, Yes, Tom experienced the same issue yesterday. I'm gonna have a look. Thanks Dominique On Jul 4, 2012, at 11:23 AM, Michael Dürig wrote: Hi, I got a ConcurrentModificationException while checking the 0.3 release. This didn't cause any test case to fail but was printed to the console. Michael Running org.apache.jackrabbit.oak.jcr.JcrTckTest java.util.ConcurrentModificationException at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136) at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131) at org.apache.jackrabbit.mk.store.DefaultRevisionStore.markBranches(DefaultRevisionStore.java:561) at org.apache.jackrabbit.mk.store.DefaultRevisionStore.gc(DefaultRevisionStore.java:497) at org.apache.jackrabbit.mk.store.DefaultRevisionStore$2.run(DefaultRevisionStore.java:159) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680)
[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile
[ https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406398#comment-13406398 ] Julian Reschke commented on OAK-163: There's a risk that people *won't* run the TCK before checking in, causing loss of cycles for somebody else later on. Also, running with integrationTesting is so slow for jackrabbit that most people won't wait for it to finish before checking in. So what may be right for OAK definitively is not right for Jackrabbit. Move the JCR TCK back to the integrationTesting profile --- Key: OAK-163 URL: https://issues.apache.org/jira/browse/OAK-163 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Jukka Zitting Priority: Minor Labels: tck Attachments: 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch In revision 1325811 the JCR TCK tests were moved from the integrationTesting profile to a normal build. However, since then the execution time of the TCK has grown to 3+ minutes, which is more than the rest of the Oak build combined. To keep the build time down to at most a couple of minutes, I'd like to move the TCK run back to the integrationTesting profile where it will get executed only when explicitly requested (typically manually before a commit or after one in a CI build). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile
[ https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406401#comment-13406401 ] Jukka Zitting commented on OAK-163: --- bq. There's a risk that people won't run the TCK before checking in, causing loss of cycles for somebody else later on. That's what we have the CI build for. Move the JCR TCK back to the integrationTesting profile --- Key: OAK-163 URL: https://issues.apache.org/jira/browse/OAK-163 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Jukka Zitting Priority: Minor Labels: tck Attachments: 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch In revision 1325811 the JCR TCK tests were moved from the integrationTesting profile to a normal build. However, since then the execution time of the TCK has grown to 3+ minutes, which is more than the rest of the Oak build combined. To keep the build time down to at most a couple of minutes, I'd like to move the TCK run back to the integrationTesting profile where it will get executed only when explicitly requested (typically manually before a commit or after one in a CI build). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-163) Move the JCR TCK back to the integrationTesting profile
[ https://issues.apache.org/jira/browse/OAK-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406419#comment-13406419 ] Julian Reschke commented on OAK-163: bq. That's what we have the CI build for. Downsides: Hasn't been always reliable. Problem is found only after checkin. Developer might not see it in time (end-of-day, vacation) or not paying attention. Etc. Move the JCR TCK back to the integrationTesting profile --- Key: OAK-163 URL: https://issues.apache.org/jira/browse/OAK-163 Project: Jackrabbit Oak Issue Type: Improvement Components: jcr Reporter: Jukka Zitting Priority: Minor Labels: tck Attachments: 0001-OAK-163-Move-the-JCR-TCK-back-to-the-integrationTest.patch In revision 1325811 the JCR TCK tests were moved from the integrationTesting profile to a normal build. However, since then the execution time of the TCK has grown to 3+ minutes, which is more than the rest of the Oak build combined. To keep the build time down to at most a couple of minutes, I'd like to move the TCK run back to the integrationTesting profile where it will get executed only when explicitly requested (typically manually before a commit or after one in a CI build). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Notes from the Oakathon
Hi, Last week some of us met for another small Oakathon in Basel. Below is a list of topics that where touched and worked on and the related Jira issues. Any additional input is appreciated. - Observation (OAK-144): * Observation events don't report every single event but rather a consolidated view at a given time (basically a a diff). Rational: performance on heavy write systems, (order of) individual events not clear/different for different cluster nodes in clustered setup. * Implement user data support on a best effort basis. In a clustered setup this can't be supported. See also http://markmail.org/message/osxupy3twc3pyild * oak-core should provide lightweight mechanism for clients to discover changes. oak-jcr can use this to implement JCR observation on top and trade off performance implications as needed. - Internal value handling * To reduce GC overhead we should try to keep the number of small objects down * Possibly merge CoreValue into PropertyState * Use flyweight instances for common values/properties - HTTP bindings (OAK-103, OAK-104) * Provide extension points for Sling to hook into. (See also the discussion on @oak-dev: http://markmail.org/message/tzpbxf5zduybezya.) - Full text index (OAK-154) * Added an initial Lucene index stored under /jcr:system/oak:lucene in the repository (final location(s) TBD) * Index updates in a CommitEditor hook, so the index is always up to date with latest content changes + TODO: How to postpone time-consuming indexing operations like full text extraction + TODO: How to merge conflicts in the search index? * Basic QueryIndexProvider allows the existing query engine to leverage the Lucene index + TODO: Integrate with the rest of the build - Merge/rebase logic handling (OAK-157) * The Lucene index work encountered some issues with the way we handle the merge/rebase operations * Need to look deeper into that over the next few weeks Michael
[jira] [Created] (OAK-164) Replace Tree.remove(String) with Tree.remove()
Michael Dürig created OAK-164: - Summary: Replace Tree.remove(String) with Tree.remove() Key: OAK-164 URL: https://issues.apache.org/jira/browse/OAK-164 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Michael Dürig Assignee: Michael Dürig Access to through the parent node is problematic wrt. to access control. So instead of removing a child node from a parent, a node should be removed directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-165) NodeDelegate should not use Tree.getChild() but rather Root.getTree()
[
https://issues.apache.org/jira/browse/OAK-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406535#comment-13406535
]
Jukka Zitting commented on OAK-165:
---
I understand where this is coming from (access control), but I'm concerned that
as a result we now have to repeatedly resolve the full path every time we want
to access something. In practice all the relevant information will already be
cached in memory, so it may not be that much of a problem, but we're still
adding path parsing and resolution steps to a place where they wouldn't really
be necessary.
NodeDelegate should not use Tree.getChild() but rather Root.getTree()
-
Key: OAK-165
URL: https://issues.apache.org/jira/browse/OAK-165
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Environment: {{Tree.getChild()}} is problematic wrt. to access
control. {{Root.getTree()}} should be used instead.
Reporter: Michael Dürig
Assignee: Michael Dürig
Fix For: 0.4
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-167) Caching NodeStore implementation
Jukka Zitting created OAK-167: - Summary: Caching NodeStore implementation Key: OAK-167 URL: https://issues.apache.org/jira/browse/OAK-167 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting For remote MicroKernel implementations and other cases where local caching of content is needed it would be useful to have a NodeStore implementation that maintains a simple in-memory or on-disk cache of frequently accessed content. Such a NodeStore implementation could also be used to better isolate the current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406581#comment-13406581 ] Stefan Guggisberg commented on OAK-167: --- Such a NodeStore implementation could also be used to better isolate the current caching logic behind uncommitted changes. wouldn't that ideally the transient space, i.e. oak-jcr? Caching NodeStore implementation Key: OAK-167 URL: https://issues.apache.org/jira/browse/OAK-167 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Jukka Zitting For remote MicroKernel implementations and other cases where local caching of content is needed it would be useful to have a NodeStore implementation that maintains a simple in-memory or on-disk cache of frequently accessed content. Such a NodeStore implementation could also be used to better isolate the current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Notes from the Oakathon
On Wed, Jul 4, 2012 at 2:37 PM, Michael Dürig mdue...@apache.org wrote: Hi, Last week some of us met for another small Oakathon in Basel. Below is a list of topics that where touched and worked on and the related Jira issues. Any additional input is appreciated. - Observation (OAK-144): * Observation events don't report every single event but rather a consolidated view at a given time (basically a a diff). Rational: performance on heavy write systems, (order of) individual events not clear/different for different cluster nodes in clustered setup. * Implement user data support on a best effort basis. In a clustered setup this can't be supported. See also http://markmail.org/message/osxupy3twc3pyild * oak-core should provide lightweight mechanism for clients to discover changes. oak-jcr can use this to implement JCR observation on top and trade off performance implications as needed. - Internal value handling * To reduce GC overhead we should try to keep the number of small objects down * Possibly merge CoreValue into PropertyState * Use flyweight instances for common values/properties - HTTP bindings (OAK-103, OAK-104) * Provide extension points for Sling to hook into. (See also the i don't remember any discussions that sling should be using an alternative interface to access the repository. IMO sling should only use the jcr api. cheers stefan discussion on @oak-dev: http://markmail.org/message/tzpbxf5zduybezya.) - Full text index (OAK-154) * Added an initial Lucene index stored under /jcr:system/oak:lucene in the repository (final location(s) TBD) * Index updates in a CommitEditor hook, so the index is always up to date with latest content changes + TODO: How to postpone time-consuming indexing operations like full text extraction + TODO: How to merge conflicts in the search index? * Basic QueryIndexProvider allows the existing query engine to leverage the Lucene index + TODO: Integrate with the rest of the build - Merge/rebase logic handling (OAK-157) * The Lucene index work encountered some issues with the way we handle the merge/rebase operations * Need to look deeper into that over the next few weeks Michael
Re: Notes from the Oakathon
Hi, On Wed, Jul 4, 2012 at 5:35 PM, Stefan Guggisberg stefan.guggisb...@gmail.com wrote: On Wed, Jul 4, 2012 at 2:37 PM, Michael Dürig mdue...@apache.org wrote: - HTTP bindings (OAK-103, OAK-104) * Provide extension points for Sling to hook into. (See also the i don't remember any discussions that sling should be using an alternative interface to access the repository. IMO sling should only use the jcr api. It came up as a potential option that Sling might be interested in. For example, many Sling components are currently having a hard time with the JCR observation feature, and giving them access to lower level features in Oak (or alternatively implementing the relevant Sling features directly as an Oak plugin) could simplify things a lot. Another potential Sling extension would be a custom Oak index provider for optimizing the kinds of queries Sling uses. BR, Jukka Zitting
[jira] [Resolved] (OAK-161) Refactor Tree#getChildStatus
[ https://issues.apache.org/jira/browse/OAK-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-161. --- Resolution: Fixed Fix Version/s: 0.4 Fixed at revision 1357314 Refactor Tree#getChildStatus Key: OAK-161 URL: https://issues.apache.org/jira/browse/OAK-161 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: Michael Dürig Fix For: 0.4 as discussed today Tree#getChildStatus is a bit problematic from my point of view as it requires the parent Tree to be always accessible. as discussed and stated multiple times in the past that may not be always the case. a part from the drawback it offers once we have access control in place it doesn't work for the root node, which doesn't have a parent by definition. therefore i would suggest to refactor the method to Tree#getStatus and make it an implementation detail if the status is stored with the parent or the tree itself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406609#comment-13406609 ] Stefan Guggisberg commented on OAK-114: --- Would it be possible to change for at least 10 minutes to for at least 10 minutes since last access? the 'extend lease model', apart from introducing complex state management requirements in the microkernel, would e.g. allow misbehaved clients to compromise the stability of the mk. a client could force the mk to keep old revisions for ever and prevent vital gc cycles. i therefore don't think that we should allow clients to (explicitly or implicitly) extend the life span of a specific revision. MicroKernel API: specify retention policy for old revisions --- Key: OAK-114 URL: https://issues.apache.org/jira/browse/OAK-114 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Attachments: OAK-114.patch the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406619#comment-13406619 ] Michael Dürig commented on OAK-114: --- bq. i can't follow this argument. with my proposal a client is minimally guaranteed to be able to read revisions no older than N minutes. Yes and that guarantee is IMO too weak. MicroKernel API: specify retention policy for old revisions --- Key: OAK-114 URL: https://issues.apache.org/jira/browse/OAK-114 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Attachments: OAK-114.patch the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406622#comment-13406622 ] Michael Dürig commented on OAK-114: --- BTW: why is 10 minutes the correct value? MicroKernel API: specify retention policy for old revisions --- Key: OAK-114 URL: https://issues.apache.org/jira/browse/OAK-114 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Attachments: OAK-114.patch the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Notes from the Oakathon
2012/7/4 Jukka Zitting jukka.zitt...@gmail.com: Hi, It came up as a potential option that Sling might be interested in. For example, many Sling components are currently having a hard time with the JCR observation feature, and giving them access to lower level features in Oak (or alternatively implementing the relevant Sling features directly as an Oak plugin) could simplify things a lot. From the peanut gallery: I'm not aware of problems with the JCR API in Sling Another potential Sling extension would be a custom Oak index provider for optimizing the kinds of queries Sling uses. While this might make sense, that wouldn't be tied to Sling but any client of OAK. Carsten -- Carsten Ziegeler cziege...@apache.org
[jira] [Comment Edited] (OAK-114) MicroKernel API: specify retention policy for old revisions
[
https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406637#comment-13406637
]
Jukka Zitting edited comment on OAK-114 at 7/4/12 5:53 PM:
---
bq. i can't follow this argument
Here's a snippet of code that illustrates Michael's point:
{code}
String revision = mk.getHeadRevision();
mk.commit(...); // Could occur in another thread
TimeUnit.MINUTES.sleep(5); // Could be any delay 10mins, or no delay at
all
mk.getNodes(/, revision, ...);
{code}
Say the {{revision}} returned from the first call was committed something like
an hour ago. Then by the time the {{getNodes}} call is reached it can be that
the garbage collector has already removed that revision since it's already
older than 10 minutes and it isn't anymore the latest revision in the
repository.
If that problem isn't fixed, a client can't make any reasonable assumptions
about how long it can expect a particular revision to stay alive. The only way
for a client to guarantee that it can see a given revision for at least the
next 10 minutes would be for it to directly commit that revision, but that's
definitely not something we want read-only clients to be doing.
was (Author: jukkaz):
bq. i can't follow this argument
Here's a snippet of code that illustrates Michael's point:
{code}
String revision = mk.getHeadRevision();
mk.commit(...); // Could occur in another thread
TimeUnit.MINUTES.sleep(5); // Could be any delay 10mins, or no delay at
all
mk.getNodes(/, revision, ...);
{code}
Say the {{revision}} returned from the first call was committed something like
an hour ago. Then by the time the {{getNodes}} call is reached it can be that
the garbage collector has already removed that revision since it's already
older than 10ms and it isn't the latest revision in the repository.
If that problem isn't fixed, a client can't make any reasonable assumptions
about how long it can expect a particular revision to stay alive. The only way
for a client to guarantee that it can see a given revision for at least the
next 10 minutes would be for it to directly commit that revision, but that's
definitely not something we want read-only clients to be doing.
MicroKernel API: specify retention policy for old revisions
---
Key: OAK-114
URL: https://issues.apache.org/jira/browse/OAK-114
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Attachments: OAK-114.patch
the MicroKernel API javadoc should specify the minimal guaranteed retention
period for old revisions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/80 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: forced: by IRC user gmcdonald on channel #asftest: testing date fix Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
