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 on channel #asftest: testing date fix Build Source Stamp: HEAD Blamelist: Build succeeded! sincerely, -The Buildbot
[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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=13406637#comment-13406637
]
Jukka Zitting commented on OAK-114:
---
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
Re: Notes from the Oakathon
2012/7/4 Jukka Zitting : > 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] [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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=13406611#comment-13406611 ] Stefan Guggisberg commented on OAK-114: --- > there is a race for example between MicroKernel.getRevisionHistory and > MicroKernel.getNodes: whatever the fixed retention time might be, when the > garbage collector runs after the first but before the second call, the latter > will fail. 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. > 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-tabpanel&focusedCommentId=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] [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
Re: Notes from the Oakathon
Hi, On Wed, Jul 4, 2012 at 5:35 PM, Stefan Guggisberg wrote: > On Wed, Jul 4, 2012 at 2:37 PM, Michael Dürig 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
Re: Notes from the Oakathon
On Wed, Jul 4, 2012 at 2:37 PM, Michael Dürig 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
[jira] [Commented] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[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] [Resolved] (OAK-164) Replace Tree.remove(String) with Tree.remove()
[ https://issues.apache.org/jira/browse/OAK-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig resolved OAK-164. --- Resolution: Fixed Fix Version/s: 0.4 Fixed at revision 1357275 > 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 > Fix For: 0.4 > > > 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] [Resolved] (OAK-166) Add Tree.isRoot() method instead of relying on Tree.getParent() == null
[
https://issues.apache.org/jira/browse/OAK-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-166.
---
Resolution: Fixed
Fix Version/s: 0.4
Fixed at revision 1357271
> Add Tree.isRoot() method instead of relying on Tree.getParent() == null
> ---
>
> Key: OAK-166
> URL: https://issues.apache.org/jira/browse/OAK-166
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Fix For: 0.4
>
>
> Access to through the parent node is problematic wrt. to access control. So
> instead of relying on {{Tree.getParent() == null}} to check for root, we
> should rather have a method {{Tree.isRoot()}}.
--
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-166) Add Tree.isRoot() method instead of relying on Tree.getParent() == null
Michael Dürig created OAK-166:
-
Summary: Add Tree.isRoot() method instead of relying on
Tree.getParent() == null
Key: OAK-166
URL: https://issues.apache.org/jira/browse/OAK-166
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 relying on {{Tree.getParent() == null}} to check for root, we should
rather have a method {{Tree.isRoot()}}.
--
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-tabpanel&focusedCommentId=13406536#comment-13406536 ] Jukka Zitting commented on OAK-114: --- The "last access" amendment would solve also Michael's concern if we define "access" as the revision id being returned from or passed to one of the MK methods. > 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-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-tabpanel&focusedCommentId=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] [Resolved] (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:all-tabpanel
]
Michael Dürig resolved OAK-165.
---
Resolution: Fixed
Fix Version/s: 0.4
Fixed at revision 1357267
> 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] [Resolved] (OAK-153) Split the CommitHook interface
[
https://issues.apache.org/jira/browse/OAK-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting resolved OAK-153.
---
Resolution: Fixed
Fix Version/s: 0.4
The missing bits are back in place as of revision 1357240. Resolving as fixed.
> Split the CommitHook interface
> --
>
> Key: OAK-153
> URL: https://issues.apache.org/jira/browse/OAK-153
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
> Fix For: 0.4
>
>
> The {{CommitHook}} interface has two methods, {{beforeCommit()}} and
> {{afterCommit()}}, since the symmetry originally seemed like a good idea.
> However, in practice these methods are not really so symmetric after all.
> For example, unlike {{afterCommit()}} the {{beforeCommit()}} method may end
> up being called multiple times for a given changeset if it needs to be
> repeatedly rebased or otherwise revised before it can be committed. There
> isn't even any guarantee that a particular changeset on which
> {{beforeCommit()}} has been called ever gets committed. And on the other hand
> there are good reasons to avoid calling {{afterCommit()}} on each and every
> commit that has been made. Instead it could be called only every now and then
> to cover larger sets of changes.
> Thus I'd like to split the {{CommitHook}} interface to two parts that I'd
> tentatively call {{CommitEditor}} and {{Observer}}.
--
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-tabpanel&focusedCommentId=13406516#comment-13406516 ] Jukka Zitting commented on OAK-114: --- Would it be possible to change "for at least 10 minutes" to "for at least 10 minutes since last access"? That would make life easier for things like large export processes that may want to stream out potentially gigabytes of data from the repository. > 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] [Updated] (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:all-tabpanel ] Stefan Guggisberg updated OAK-114: -- Attachment: OAK-114.patch patch with a first proposal (10-minutes guaranteed retention period for head revisions) > 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] [Created] (OAK-165) NodeDelegate should not use Tree.getChild() but rather Root.getTree()
Michael Dürig created OAK-165:
-
Summary: 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
--
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-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
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] [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-tabpanel&focusedCommentId=13406438#comment-13406438 ] Jukka Zitting commented on OAK-163: --- bq. http://ci.apache.org/builders/oak-trunk fails since quite a while now and no one bothers to have a look. Not true. I caught that one right after the CI build stated failing: http://markmail.org/message/zhg7ilg7a2dg7s4z. Of course the issue with Buildbot still isn't resolved, but we have the Travis build as a backup. > 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-tabpanel&focusedCommentId=13406436#comment-13406436 ] Jukka Zitting commented on OAK-163: --- bq. Hasn't been always reliable. People are still expected to run the TCK before committing new stuff, so the CI build is just a failsafe for cases when that didn't happen. And if the CI build also fails to catch the problem, other committers will soon enough encounter the build failure. A test failure won't last long before being detected. bq. Developer might not see it in time (end-of-day, vacation) or not paying attention. We manage the codebase collectively, so anyone who sees a build failure is free to revert the commit that broke the build. Personally I much rather spend a few extra minutes reverting the occasional breaking change than having all my builds take longer. I'd also be fine with a solution that I can selectively enable only on my machine to keep only fast tests in the default build, but I don't know a clean way of doing that. It's easier to selectively add bits to the build than to take them away. See also OAK-53 where we already discussed the "long build" problem earlier. > 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-tabpanel&focusedCommentId=13406432#comment-13406432 ] Michael Dürig 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. In my experience this is not only a risk but common practice. And the CI server doesn't seem to help either. http://ci.apache.org/builders/oak-trunk fails since quite a while now and no one bothers to have a look. Having long build times is inconvenient agreed. But failing the build for all others is a very bad trade off. Optimally: * everyone runs the integration tests before checkin unless there is very good reasons to believe nothing will break * the CI infrastructure would be reliable * everyone watches the CI server and fixes broken builds caused by self. Until we have that, I suggest we'd turn the process around and add an option to smoke test like we had it in OAK-53 before it was reverted. > 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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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
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] [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
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)
Re: [VOTE] Release Apache Jackrabbit Oak 0.3
Please vote on releasing this package as Apache Jackrabbit Oak 0.3. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 0.3 [ ] -1 Do not release this package because... +1 Michael
[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-tabpanel&focusedCommentId=13406377#comment-13406377
]
Jukka Zitting commented on OAK-163:
---
I'd like to change that in Jackrabbit trunk as well, there the default build
already takes >10 minutes for me. That's enough time for a coffee break for
each build of the codebase.
A long build time is a drain on productivity as to get a deployable build
artifact (runnable jar, OSGi bundle, etc.) you need to run the build. When
working on some non-trivial issue, I typically have to build the codebase at
least a half a dozen times before the changes are ready to be committed.
There's little point having long-running tests included in such intermediate
builds, but it would still be useful to have a basic set of fast and simple
sanity checks run on the code to catch any obvious mistakes beyond just compile
failures.
Currently I'm using {{mvn clean install -DskipTests}} for such intermediate
builds, which is hardly ideal as a) that disables all tests, and b) requires
more typing than the default build.
Instead I'd like the default build (that's executed most often) to be lean and
fast (with unit tests ideally not taking much more time than it took to compile
the relevant code), and have a separate integration test build ({{mvn clean
install -PintegrationTesting}}) for more complete verification of changes
before committing them.
If people prefer to have all tests run on each build, we could still support
that use case on a per-user basis by having the {{integrationTesting}} profile
be automatically activated on something like the presence of an
{{OAK_INTEGRATION_TESTING}} environment variable.
> 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
>
> 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
