[jira] [Reopened] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela reopened OAK-3761: - i think LATER would be the appropriate resolution then > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch, OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-3761. - Resolution: Later > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch, OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4476) Option to check datastore consistency in oak-run
[ https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362005#comment-15362005 ] Amit Jain commented on OAK-4476: [~julian.resc...@gmx.de] Thanks for flagging. The failure was on windows and could reproduce it on a win setup. Fixed with - http://svn.apache.org/viewvc?rev=1751396&view=rev > Option to check datastore consistency in oak-run > > > Key: OAK-4476 > URL: https://issues.apache.org/jira/browse/OAK-4476 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: run >Reporter: Amit Jain >Assignee: Amit Jain > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.5.5 > > > Add an option to check data store consistency in oak-run. Along with the > consistency check it makes sense to have the option to dump all blob ids > and/or all the blob references available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4476) Option to check datastore consistency in oak-run
[ https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain resolved OAK-4476. Resolution: Fixed > Option to check datastore consistency in oak-run > > > Key: OAK-4476 > URL: https://issues.apache.org/jira/browse/OAK-4476 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: run >Reporter: Amit Jain >Assignee: Amit Jain > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.5.5 > > > Add an option to check data store consistency in oak-run. Along with the > consistency check it makes sense to have the option to dump all blob ids > and/or all the blob references available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (OAK-4476) Option to check datastore consistency in oak-run
[ https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain reopened OAK-4476: re-opening due to failed tests > Option to check datastore consistency in oak-run > > > Key: OAK-4476 > URL: https://issues.apache.org/jira/browse/OAK-4476 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: run >Reporter: Amit Jain >Assignee: Amit Jain > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.5.5 > > > Add an option to check data store consistency in oak-run. Along with the > consistency check it makes sense to have the option to dump all blob ids > and/or all the blob references available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4516) Configurable option to lucene index defs to index original (unanalyzed value as well)
[
https://issues.apache.org/jira/browse/OAK-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-4516.
Resolution: Fixed
Fix Version/s: 1.5.5
1.6
Fixed in trunk at [r1751376|https://svn.apache.org/1751376]. Updated doc at
[r1751377|https://svn.apache.org/1751377].
The configuration would be needed on {{analyzers}} node.
> Configurable option to lucene index defs to index original (unanalyzed value
> as well)
> -
>
> Key: OAK-4516
> URL: https://issues.apache.org/jira/browse/OAK-4516
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.6, 1.5.5
>
> Attachments: OAK-4516.patch
>
>
> It's sometimes useful to have original value being indexed to be stored as a
> term. One use-case could be like:
> * consider a couple of values to be indexed as {{abc_def}}, {{abcdef}}
> * On query, it seems reasonable to get both values for a query for {{abc*}}
> * On query, at times, it might be useful to expect {{abc_def}} for
> {{abc_d\*}} or {{abc_\*}}
> Currently, the values would get indexed like:
> * {{abc_def}} -> {{\[abc], \[def]}}
> * {{abcdef}} -> {{\[abcdef]}}
> So, the query {{abc*}} would only fetch {{abcdef}}, while {{abc_d\*}} or
> {{abc_\*}} won't fetch anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361765#comment-15361765 ] Vikas Saurabh commented on OAK-4529: I meant that oak-run should take the responsibility to tell DocumentNodeStore that it shouldn't write to old repos. End user (of AEM, oak, oak-run, any other tool) shouldn't have to worry about such flag (at least on the best effort basis). > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361577#comment-15361577 ] Ian Boston commented on OAK-4529: - The default behavior should be safe and do no damage, as a user of oak-run or other utilities will not know they are about to corrupt the repository, and when they do, it will be too late. ie safe by default. It should be possible to override the default behaviour to allow an upgrade to be performed. > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4512) Detect and log commits to the read-only stores
[ https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361492#comment-15361492 ] Florin Iordache commented on OAK-4512: -- Integrated the feedback and updated the patch. > Detect and log commits to the read-only stores > -- > > Key: OAK-4512 > URL: https://issues.apache.org/jira/browse/OAK-4512 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4512-patch.diff > > > Since the read-only stores will be immutable we should be able to detect > commits made against them and log an error message via a commit validation > provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4513) Detect and log references across stores
[ https://issues.apache.org/jira/browse/OAK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4513: - Attachment: OAK-4513-patch.diff > Detect and log references across stores > --- > > Key: OAK-4513 > URL: https://issues.apache.org/jira/browse/OAK-4513 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4513-patch.diff > > > References across different stores will not be allowed at runtime, we need a > commit validator to detect and log such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4512) Detect and log commits to the read-only stores
[ https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4512: - Attachment: OAK-4512-patch.diff > Detect and log commits to the read-only stores > -- > > Key: OAK-4512 > URL: https://issues.apache.org/jira/browse/OAK-4512 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4512-patch.diff > > > Since the read-only stores will be immutable we should be able to detect > commits made against them and log an error message via a commit validation > provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4512) Detect and log commits to the read-only stores
[ https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4512: - Attachment: (was: OAK-4512-patch.diff) > Detect and log commits to the read-only stores > -- > > Key: OAK-4512 > URL: https://issues.apache.org/jira/browse/OAK-4512 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4512-patch.diff > > > Since the read-only stores will be immutable we should be able to detect > commits made against them and log an error message via a commit validation > provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4532) race-condition in commit-rate-limiter
[
https://issues.apache.org/jira/browse/OAK-4532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361489#comment-15361489
]
Stefan Egli commented on OAK-4532:
--
/cc [~mduerig]
> race-condition in commit-rate-limiter
> -
>
> Key: OAK-4532
> URL: https://issues.apache.org/jira/browse/OAK-4532
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.5.4
>Reporter: Stefan Egli
>
> [CommitRateLimiter.delay|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.5.4/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/CommitRateLimiter.java#L81]
> has a race-condition when the queue length drops below thres-hold right when
> {{delay()}} is called. Consider the following steps:
> * thread T1 enters {{delay()}} with a positive value for {{delay}} but gets
> paused right after the check for {{delay>0}}
> * thread T2 enters {{setDelay(0)}}, thus goes into the synchronized block and
> does a notifyAll
> * thread T1 continues in {{delay()}} after above mentioned check, thus now
> goes into the synchronized block - at this stage {{delay}} is {{0}} (as it's
> volatile) - thus it sets {{dt=0}}.
> * thread T1 then goes and calls {{wait(0)}} - which is an infinite wait,
> until it gets notified. This can be forever if the threshold is never ever
> hit again.
> Would suggest to do a {{while}} loop rather than a {{do-while}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-4532) race-condition in commit-rate-limiter
Stefan Egli created OAK-4532:
Summary: race-condition in commit-rate-limiter
Key: OAK-4532
URL: https://issues.apache.org/jira/browse/OAK-4532
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.5.4
Reporter: Stefan Egli
[CommitRateLimiter.delay|https://github.com/apache/jackrabbit-oak/blob/jackrabbit-oak-1.5.4/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/observation/CommitRateLimiter.java#L81]
has a race-condition when the queue length drops below thres-hold right when
{{delay()}} is called. Consider the following steps:
* thread T1 enters {{delay()}} with a positive value for {{delay}} but gets
paused right after the check for {{delay>0}}
* thread T2 enters {{setDelay(0)}}, thus goes into the synchronized block and
does a notifyAll
* thread T1 continues in {{delay()}} after above mentioned check, thus now goes
into the synchronized block - at this stage {{delay}} is {{0}} (as it's
volatile) - thus it sets {{dt=0}}.
* thread T1 then goes and calls {{wait(0)}} - which is an infinite wait, until
it gets notified. This can be forever if the threshold is never ever hit again.
Would suggest to do a {{while}} loop rather than a {{do-while}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4513) Detect and log references across stores
[ https://issues.apache.org/jira/browse/OAK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4513: - Attachment: (was: OAK-4513-patch.diff) > Detect and log references across stores > --- > > Key: OAK-4513 > URL: https://issues.apache.org/jira/browse/OAK-4513 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4513-patch.diff > > > References across different stores will not be allowed at runtime, we need a > commit validator to detect and log such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4530) Session modification discarded when repository closed too soon
[
https://issues.apache.org/jira/browse/OAK-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361471#comment-15361471
]
Marco Piovesana commented on OAK-4530:
--
I was writing the test and i found what the problem was. I was using a
FileStore without closing it before shutting down the repository.
Here how i was creating the repository:
{code:borderStyle=solid}
FileStore repositoryStore = null;
File rootPath = new File("/tmp/testoak");
File driveFile = new File(rootPath, DRIVE);
File repositoryFile = new File(driveFile, REPOSITORY);
File dataStoreFile = new File(driveFile, DATASTORE);
BlobStore blobStore = new FileBlobStore(dataStoreFile.getAbsolutePath());
repositoryStore =
FileStore.newFileStore(repositoryFile).withBlobStore(blobStore).create();
repositoryStore.flush();
NodeStore nodeStore =
SegmentNodeStore.newSegmentNodeStore(repositoryStore).create();
Jcr jcr = new Jcr(nodeStore).with(new InitialContent()).with(new
SecurityProviderImpl());
Repository repository = jcr.createRepository();
{code}
And what I was missing (i believe) was _repositoryStore.close()_ before
_((JackrabbitRepository) repository).shutdown()_.
No error message was thrown during the shutdown so i did not see it before.
thanks, Marco.
> Session modification discarded when repository closed too soon
> --
>
> Key: OAK-4530
> URL: https://issues.apache.org/jira/browse/OAK-4530
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.4
>Reporter: Marco Piovesana
>
> If I close the repository right after creating a new group (and saving the
> session) the modification is not persisted.
> {code: borderStyle=solid}
> UserManager userManager = ((SessionImpl)adminSession).getUserManager();
> Group group = userManager.createGroup("myGroup");
> adminSession.save();
> adminSession.logout();
> ((JackrabbitRepository) repository).shutdown();
> {code}
> When i restart the repository the group "myGroup" does not exist but no error
> is logged anywhere. However, if i put a _Thread.sleep(3000l)_ before shutting
> down the repository, the group is persisted.
> Am I doing something wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4476) Option to check datastore consistency in oak-run
[
https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361469#comment-15361469
]
Julian Reschke commented on OAK-4476:
-
The new test consistently fails for me:
{noformat}
testConsistency(org.apache.jackrabbit.oak.run.DataStoreCheckTest) Time
elapsed: 0.3 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.assertFileEquals(DataStoreCheckTest.java:218)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.testConsistency(DataStoreCheckTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Option to check datastore consistency in oak-run
>
>
> Key: OAK-4476
> URL: https://issues.apache.org/jira/browse/OAK-4476
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run
>Reporter: Amit Jain
>Assignee: Amit Jain
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.5
>
>
> Add an option to check data store consistency in oak-run. Along with the
> consistency check it makes sense to have the option to dump all blob ids
> and/or all the blob references available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4476) Option to check datastore consistency in oak-run
[
https://issues.apache.org/jira/browse/OAK-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361469#comment-15361469
]
Julian Reschke edited comment on OAK-4476 at 7/4/16 3:30 PM:
-
The new test consistently fails for me:
{noformat}
testConsistency(org.apache.jackrabbit.oak.run.DataStoreCheckTest) Time
elapsed: 0.3 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.assertFileEquals(DataStoreCheckTest.java:218)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.testConsistency(DataStoreCheckTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
was (Author: reschke):
The new test consistently fails for me:
{noformat}
testConsistency(org.apache.jackrabbit.oak.run.DataStoreCheckTest) Time
elapsed: 0.3 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.assertFileEquals(DataStoreCheckTest.java:218)
at
org.apache.jackrabbit.oak.run.DataStoreCheckTest.testConsistency(DataStoreCheckTest.java:153)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> Option to check datastore consistency in oak-run
>
>
> Key: OAK-4476
> URL: https://issues.apache.org/jira/browse/OAK-4476
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: run
>Reporter: Amit Jain
>Assignee: Amit Jain
> Labels: candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.5.5
>
>
> Add an option to check data store consistency in oak-run. Along with the
> consistency check it makes sense to have the option to dump all blob ids
> and/or all the blob references available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3404) Path to logical store mapping
[
https://issues.apache.org/jira/browse/OAK-3404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361451#comment-15361451
]
Chetan Mehrotra commented on OAK-3404:
--
Thanks Davide. Main API class is MountInfoProvider which has some javadoc.
Would improve that further
> Path to logical store mapping
> -
>
> Key: OAK-3404
> URL: https://issues.apache.org/jira/browse/OAK-3404
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: core
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Attachments: OAK-3404-v1.patch
>
>
> Need to provide an API {{MountInfoProvider}} which would be responsible for
> mapping a given path to logical store name
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (OAK-3403) Multiplexing store support in Property indexes
[
https://issues.apache.org/jira/browse/OAK-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3403:
-
Comment: was deleted
(was: Uniqueness constraint can be safely enforced if in a 2 store setup
(private and shared) the private one is immutable. As current logic check the
presence of given uuid in all the stores and only when none is found it
proceeds to create one. So if one of them is immutable this would work fine.
Problem would come if both allow writes as in that case its not possible to
atomically ensure the given node does not exist in both easily. I would update
the approach to fail if both default and other mount allow writes at same time.
Also can add a tooling which would check when a system with the new private
repo is joined to a shared repo checks if the uuid it has are all unique)
> Multiplexing store support in Property indexes
> --
>
> Key: OAK-3403
> URL: https://issues.apache.org/jira/browse/OAK-3403
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Attachments: OAK-3403-v1.patch
>
>
> In Oak one can define an index anywhere in the repository under a special
> node name {{oak:index}}. For e.g. if you want a property index for
> {{sling:resourceType}} at root level then you can create the index at
> /oak:index/resourceType and this index would store the index content at
> /oak:index/resourceType/:index.
> # Writing - At time of commit the IndexEditor would need to decide where the
> indexed content for a given path should be stored. To start with it can make
> use of PathToStoreMapper to decide which node to use the indexed content. For
> e.g. for /libs the indexed content is stored under :index-pr and for /content
> :index-sr is used. This is simpler for PropertyIndex where IndexStoreStrategy
> can be passed the right node
> # Reading - At time of reading the QueryIndex implementation would need to
> provide a union cursor which can perform lookup from all such store
> directories for a given index.
> *Open Items*
> # Supporting unique indexes
> # Introducing new oak:index - Node under oak:index node are special.
> Depending on parent path it might be possible that they would have to be
> created in both repositories. For e.g. /oak:index would have to be present in
> both PR and SR. While /content/foo/oak:index can live only in SR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret resolved OAK-3761. - Resolution: Won't Fix Closing for now. Let's reopen it if business motivates this addition. > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch, OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4512) Detect and log commits to the read-only stores
[
https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361395#comment-15361395
]
Chetan Mehrotra commented on OAK-4512:
--
Some quick comments
{noformat}
+if (mountInfoProvider != null
+&& mountInfoProvider.hasNonDefaultMounts()) {
+if (serviceRegistration == null) {
+serviceRegistration =
bundleContext.registerService(PrivateStoreValidatorProvider.class.getName(),
this, null);
+}
+} else {
+unregisterValidatorProvider();
+}
{noformat}
For above flow
* mountInfoProvider would always be non null. So you can do away null checks.
If no mountInforProvider is present your component would not get activated
* Instance should be registered against
{{org.apache.jackrabbit.oak.spi.commit.EditorProvider}} otherwise it would not
get picked up by Oak
* No need to invoke unregisterValidatorProvider - If mountInfoProvider gets
changed/disabled then your component would get deactivate call which takes care
of deactivation
{noformat}
+private String getCommitPath(String changeNodeName) {
+String parentNodePath = path;
+
+String commitPath = ROOT_PATH.equals(parentNodePath)
+? parentNodePath + changeNodeName
+: parentNodePath + "/" + changeNodeName;
+
+return commitPath;
{noformat}
You can use {{PathUtils.conact}} for that (from oak-commons) which take care of
root path handling also.
> Detect and log commits to the read-only stores
> --
>
> Key: OAK-4512
> URL: https://issues.apache.org/jira/browse/OAK-4512
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Florin Iordache
> Attachments: OAK-4512-patch.diff
>
>
> Since the read-only stores will be immutable we should be able to detect
> commits made against them and log an error message via a commit validation
> provider.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4516) Configurable option to lucene index defs to index original (unanalyzed value as well)
[
https://issues.apache.org/jira/browse/OAK-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361389#comment-15361389
]
Vikas Saurabh commented on OAK-4516:
I was thinking of {{analyzers}}. {{analyzers/default}} sort of seems like
configuring a custom analyzer (class or composed).
Would do that change (put in {{analyzers/@indexOriginalTerm}})
> Configurable option to lucene index defs to index original (unanalyzed value
> as well)
> -
>
> Key: OAK-4516
> URL: https://issues.apache.org/jira/browse/OAK-4516
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-4516.patch
>
>
> It's sometimes useful to have original value being indexed to be stored as a
> term. One use-case could be like:
> * consider a couple of values to be indexed as {{abc_def}}, {{abcdef}}
> * On query, it seems reasonable to get both values for a query for {{abc*}}
> * On query, at times, it might be useful to expect {{abc_def}} for
> {{abc_d\*}} or {{abc_\*}}
> Currently, the values would get indexed like:
> * {{abc_def}} -> {{\[abc], \[def]}}
> * {{abcdef}} -> {{\[abcdef]}}
> So, the query {{abc*}} would only fetch {{abcdef}}, while {{abc_d\*}} or
> {{abc_\*}} won't fetch anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4516) Configurable option to lucene index defs to index original (unanalyzed value as well)
[
https://issues.apache.org/jira/browse/OAK-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361382#comment-15361382
]
Chetan Mehrotra commented on OAK-4516:
--
Looks good. Not sure on where to expose the config option. Should we expose it
at {{analyzers/default/@indexOriginalTerm}} or we can keep it at main level
> Configurable option to lucene index defs to index original (unanalyzed value
> as well)
> -
>
> Key: OAK-4516
> URL: https://issues.apache.org/jira/browse/OAK-4516
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Attachments: OAK-4516.patch
>
>
> It's sometimes useful to have original value being indexed to be stored as a
> term. One use-case could be like:
> * consider a couple of values to be indexed as {{abc_def}}, {{abcdef}}
> * On query, it seems reasonable to get both values for a query for {{abc*}}
> * On query, at times, it might be useful to expect {{abc_def}} for
> {{abc_d\*}} or {{abc_\*}}
> Currently, the values would get indexed like:
> * {{abc_def}} -> {{\[abc], \[def]}}
> * {{abcdef}} -> {{\[abcdef]}}
> So, the query {{abc*}} would only fetch {{abcdef}}, while {{abc_d\*}} or
> {{abc_\*}} won't fetch anything.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3305) Self recovering instance may not see all changes
[ https://issues.apache.org/jira/browse/OAK-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3305: -- Labels: resilience (was: candidate_oak_1_0 candidate_oak_1_2 resilience) Fix Version/s: 1.2.17 1.0.32 Merged into branches: - 1.2: http://svn.apache.org/r1751259 - 1.0: http://svn.apache.org/r1751290 > Self recovering instance may not see all changes > > > Key: OAK-3305 > URL: https://issues.apache.org/jira/browse/OAK-3305 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.0, 1.2, 1.3.4 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.4, 1.3.6, 1.0.32, 1.2.17 > > > When a DocumentNodeStore instance is killed and restarted, the _lastRev > recovery mechanism is triggered on startup. It may happen that the restarted > instance does not see all changes that were recovered. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4262) Provide a way to abort an async indexing run
[
https://issues.apache.org/jira/browse/OAK-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361325#comment-15361325
]
Chetan Mehrotra edited comment on OAK-4262 at 7/4/16 1:36 PM:
--
Also merged fixes for OAK-1648 , OAK-2363, OAK-2311 (both required by OAK-1648)
to 1.0 branch for this issue. Thanks [~alex.parvulescu] for reviewing the merge
work and bringing this change to notice!
was (Author: chetanm):
Also merged fixes for OAK-1648 , OAK-2363, OAK-2311 (both required by OAK-1648)
to 1.0 branch for this issue
> Provide a way to abort an async indexing run
>
>
> Key: OAK-4262
> URL: https://issues.apache.org/jira/browse/OAK-4262
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3, 1.0.32
>
>
> In some cases where a user is tweaking the indexing config it can happen that
> he saves the config mid way which triggers a long indexing run. Currently
> there is no easy way to abort such a run and only way to avoid wasting time
> in the long indexing cycle is to shut down the system.
> For such cases it would be good to provide an "abort" operation as part of
> {{IndexStatsMBean}} which user can invoke to abort any run safely and cleanly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4262) Provide a way to abort an async indexing run
[
https://issues.apache.org/jira/browse/OAK-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361325#comment-15361325
]
Chetan Mehrotra commented on OAK-4262:
--
Also merged fixes for OAK-1648 , OAK-2363, OAK-2311 (both required by OAK-1648)
to 1.0 branch for this issue
> Provide a way to abort an async indexing run
>
>
> Key: OAK-4262
> URL: https://issues.apache.org/jira/browse/OAK-4262
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3, 1.0.32
>
>
> In some cases where a user is tweaking the indexing config it can happen that
> he saves the config mid way which triggers a long indexing run. Currently
> there is no easy way to abort such a run and only way to avoid wasting time
> in the long indexing cycle is to shut down the system.
> For such cases it would be good to provide an "abort" operation as part of
> {{IndexStatsMBean}} which user can invoke to abort any run safely and cleanly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1648) Creating multiple checkpoint on same head revision overwrites previous entries
[ https://issues.apache.org/jira/browse/OAK-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-1648: - Labels: resilience (was: candidate_oak_1_0 resilience) Fix Version/s: 1.0.32 Merged to 1.0 with 1751284. This was required for tests of OAK-3436 to pass on Mongo > Creating multiple checkpoint on same head revision overwrites previous entries > -- > > Key: OAK-1648 > URL: https://issues.apache.org/jira/browse/OAK-1648 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Marcel Reutegger >Priority: Minor > Labels: resilience > Fix For: 1.4, 1.3.8, 1.2.10, 1.0.32 > > > Currently when a checkpoint is created in DocumentNodeStore then it is saved > in form of currentHeadRev=>expiryTime. Now if multiple checkpoints are > created where head revision has not changed then only the last one would be > saved and previous entries would be overridden as revision is used as key > One fix would be to change the expiry time only if the new expiry time is > greater than previous entry. However doing that safely in a cluster (check > then save) is currently not possible with DocumentStore API as the modCount > check if only supported for Nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4530) Session modification discarded when repository closed too soon
[
https://issues.apache.org/jira/browse/OAK-4530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361299#comment-15361299
]
Marcel Reutegger commented on OAK-4530:
---
Can you please attach a full test that also includes how you create the
repository? Thanks.
> Session modification discarded when repository closed too soon
> --
>
> Key: OAK-4530
> URL: https://issues.apache.org/jira/browse/OAK-4530
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4.4
>Reporter: Marco Piovesana
>
> If I close the repository right after creating a new group (and saving the
> session) the modification is not persisted.
> {code: borderStyle=solid}
> UserManager userManager = ((SessionImpl)adminSession).getUserManager();
> Group group = userManager.createGroup("myGroup");
> adminSession.save();
> adminSession.logout();
> ((JackrabbitRepository) repository).shutdown();
> {code}
> When i restart the repository the group "myGroup" does not exist but no error
> is logged anywhere. However, if i put a _Thread.sleep(3000l)_ before shutting
> down the repository, the group is persisted.
> Am I doing something wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2363) NPE in DocumentNodeStore#retrieve for non existing checkpoint
[ https://issues.apache.org/jira/browse/OAK-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361296#comment-15361296 ] Chetan Mehrotra commented on OAK-2363: -- Merged to 1.0 1751274 > NPE in DocumentNodeStore#retrieve for non existing checkpoint > - > > Key: OAK-2363 > URL: https://issues.apache.org/jira/browse/OAK-2363 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Michael Dürig >Assignee: Michael Dürig > Fix For: 1.1.4, 1.0.32 > > > Said method throws a NPE when passing it a valid revision identifier from a > non existing checkpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2363) NPE in DocumentNodeStore#retrieve for non existing checkpoint
[ https://issues.apache.org/jira/browse/OAK-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-2363: - Fix Version/s: 1.0.32 > NPE in DocumentNodeStore#retrieve for non existing checkpoint > - > > Key: OAK-2363 > URL: https://issues.apache.org/jira/browse/OAK-2363 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mongomk >Reporter: Michael Dürig >Assignee: Michael Dürig > Fix For: 1.1.4, 1.0.32 > > > Said method throws a NPE when passing it a valid revision identifier from a > non existing checkpoint. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2311) Released checkpoint can still be retrieved
[
https://issues.apache.org/jira/browse/OAK-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361291#comment-15361291
]
Chetan Mehrotra commented on OAK-2311:
--
Merged to 1.0 with with 1751272
> Released checkpoint can still be retrieved
> ---
>
> Key: OAK-2311
> URL: https://issues.apache.org/jira/browse/OAK-2311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.1.3, 1.0.32
>
>
> The following fails on the 2nd assertion on the MongoMK
> {code}
> assertTrue(store.release(cp));
> assertNull(store.retrieve(cp));
> {code}
> The JavaDoc on the {{release}} method is a bit vague, but I assume it is safe
> to assume that when it returns {{true}} the checkpoint should be gone. If
> not, we should update the JavaDoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2311) Released checkpoint can still be retrieved
[
https://issues.apache.org/jira/browse/OAK-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-2311:
-
Fix Version/s: 1.0.32
> Released checkpoint can still be retrieved
> ---
>
> Key: OAK-2311
> URL: https://issues.apache.org/jira/browse/OAK-2311
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.1.3, 1.0.32
>
>
> The following fails on the 2nd assertion on the MongoMK
> {code}
> assertTrue(store.release(cp));
> assertNull(store.retrieve(cp));
> {code}
> The JavaDoc on the {{release}} method is a bit vague, but I assume it is safe
> to assume that when it returns {{true}} the checkpoint should be gone. If
> not, we should update the JavaDoc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4254) CLONE - BackgroundThread should log and re-throw instances of Error
[
https://issues.apache.org/jira/browse/OAK-4254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4254:
-
Labels: resilience (was: candidate_oak_1_0 candidate_oak_1_2
candidate_oak_1_4 resilience)
> CLONE - BackgroundThread should log and re-throw instances of Error
> ---
>
> Key: OAK-4254
> URL: https://issues.apache.org/jira/browse/OAK-4254
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.6, Segment Tar 0.0.2
>
>
> If the run method of a {{BackgroundThread}} instance hits an {{Error}} it
> dies silently. Instead it should log an re-throw the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3702) More resilient BackgroundThread implementation
[
https://issues.apache.org/jira/browse/OAK-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-3702:
-
Fix Version/s: 1.2.17
1.0.32
> More resilient BackgroundThread implementation
> --
>
> Key: OAK-3702
> URL: https://issues.apache.org/jira/browse/OAK-3702
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.4, 1.3.12, 1.0.32, 1.2.17
>
> Attachments: OAK-3702.1.0.patch, OAK-3702.1.2.patch
>
>
> Currently {{BackgroundThread}} dies silently when hit by an uncaught
> exception. We should log a warning.
> Also calling {{Thread#start}} from within the constructor is an anti-pattern
> as it exposes {{this}} before fully initialised. This is potentially causing
> OAK-3303.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3702) More resilient BackgroundThread implementation
[
https://issues.apache.org/jira/browse/OAK-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361278#comment-15361278
]
Alex Parvulescu commented on OAK-3702:
--
thanks a lot [~catholicon] for the patches! I have taken the liberty to apply
them directly.
* merged to 1.0 with r1751271
* merged to 1.2 with r1751268
> More resilient BackgroundThread implementation
> --
>
> Key: OAK-3702
> URL: https://issues.apache.org/jira/browse/OAK-3702
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.4, 1.3.12, 1.0.32, 1.2.17
>
> Attachments: OAK-3702.1.0.patch, OAK-3702.1.2.patch
>
>
> Currently {{BackgroundThread}} dies silently when hit by an uncaught
> exception. We should log a warning.
> Also calling {{Thread#start}} from within the constructor is an anti-pattern
> as it exposes {{this}} before fully initialised. This is potentially causing
> OAK-3303.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3702) More resilient BackgroundThread implementation
[
https://issues.apache.org/jira/browse/OAK-3702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-3702:
-
Labels: resilience (was: candidate_oak_1_0 candidate_oak_1_2 resilience)
> More resilient BackgroundThread implementation
> --
>
> Key: OAK-3702
> URL: https://issues.apache.org/jira/browse/OAK-3702
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.4, 1.3.12, 1.0.32, 1.2.17
>
> Attachments: OAK-3702.1.0.patch, OAK-3702.1.2.patch
>
>
> Currently {{BackgroundThread}} dies silently when hit by an uncaught
> exception. We should log a warning.
> Also calling {{Thread#start}} from within the constructor is an anti-pattern
> as it exposes {{this}} before fully initialised. This is potentially causing
> OAK-3303.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361122#comment-15361122 ] Vikas Saurabh edited comment on OAK-4529 at 7/4/16 12:30 PM: - bq. check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. I think utilities like oak-run are always able to read an old format. The issue, of course is that once they write out some data using a potentially new format then the oak version (presumably old) which was using the repo might get confused (e.g. oak-run at trunk would write out revision vectors for checkpoints which would confuse old oak at 1.0 or 1.2). So, I think what's more important is for -DNS- DocumentNodeStore instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. was (Author: catholicon): bq. check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. I think utilities like oak-run are always able to read an old format. The issue, of course is that once they write out some data using a potentially new format then the oak version (presumably old) which was using the repo might get confused (e.g. oak-run at trunk would write out revision vectors for checkpoints which would confuse old oak at 1.0 or 1.2). So, I think what's more important is for DNS instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[
https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361244#comment-15361244
]
Vikas Saurabh commented on OAK-4529:
What I meant earlier was that sure, DocumentNodeStore should allow a flag to
NOT write to a repo with older version - but the usage of flag should be due to
the fact of intent while DocumentNodeStore is being initialized.
e.g. oak-run must always initialize DocumentNodeStore with this
{{cautionDontWriteToOld=true}} flag. Otoh, default remains the same (i.e it's
ok to read the repo if you can -- may be we can check based on version too
whether we can read the repo.. but that would probably be just a side-use-case
of stored written versions)
I think it's surely useful to know which version (versions??? why?) wrote to
repo. But, the usage of that persisted version is an act of courtesy from later
version of oak (since it 'can' read... but it chooses not to do so).
Afaics, the argument is about what should be the default value of
{{cautionDontWriteToOld}} be? Imho, it should derived from the intent with
default being allowed to read if it can - oak-run should instruct
DocumentNodeStore accordingly while other initializers remain oblivious to the
fact. Moreover, I think upgrades shouldn't require explicit flag ... handling
inconsistencies, if any, should be oak (default initialization or oak-run)
internal detail.
> DocumentNodeStore does not have a repository software version range check.
> --
>
> Key: OAK-4529
> URL: https://issues.apache.org/jira/browse/OAK-4529
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4
>Reporter: Ian Boston
>
> DocumentNodeStore does not currently check which software version the
> persisted repository it is connecting to was created with or last updated.
> There is a risk that if the versions are incompatible the repository may be
> damaged.
> Somewhere in the repository, the version of the software that created it, and
> the versions that written to it should be stored. In the case of TarMK this
> information could be on local disk near the TarMK files. In the case of a
> DocumentMK implementation, the information should be stored in the "database"
> itself.
> When a DocumentNodeStore instance connects it should: check the versions
> stored in the repository then check the versions are within a compatible
> range and refuse to start if not.
> When a DocumentNodeStore writes to a repository, it should add its version to
> the list of versions that have updated the repository.
> This check behaviour should be active in full Oak or any utilities (eg
> oak-run).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-4262) Provide a way to abort an async indexing run
[
https://issues.apache.org/jira/browse/OAK-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276267#comment-15276267
]
Chetan Mehrotra edited comment on OAK-4262 at 7/4/16 12:00 PM:
---
Merged to branches
* 1.4 - [1742930|http://svn.apache.org/r1742930]
* 1.2 - [1742928|http://svn.apache.org/r1742928]
* 1.0 - [1751257|http://svn.apache.org/r1751257]
was (Author: chetanm):
Merged to branches
* 1.4 - [1742930|http://svn.apache.org/r1742930]
* 1.2 - [1742928|http://svn.apache.org/r1742928]
> Provide a way to abort an async indexing run
>
>
> Key: OAK-4262
> URL: https://issues.apache.org/jira/browse/OAK-4262
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3, 1.0.32
>
>
> In some cases where a user is tweaking the indexing config it can happen that
> he saves the config mid way which triggers a long indexing run. Currently
> there is no easy way to abort such a run and only way to avoid wasting time
> in the long indexing cycle is to shut down the system.
> For such cases it would be good to provide an "abort" operation as part of
> {{IndexStatsMBean}} which user can invoke to abort any run safely and cleanly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4262) Provide a way to abort an async indexing run
[
https://issues.apache.org/jira/browse/OAK-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4262:
-
Fix Version/s: 1.0.32
> Provide a way to abort an async indexing run
>
>
> Key: OAK-4262
> URL: https://issues.apache.org/jira/browse/OAK-4262
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Labels: docs-impacting
> Fix For: 1.6, 1.5.2, 1.2.15, 1.4.3, 1.0.32
>
>
> In some cases where a user is tweaking the indexing config it can happen that
> he saves the config mid way which triggers a long indexing run. Currently
> there is no easy way to abort such a run and only way to avoid wasting time
> in the long indexing cycle is to shut down the system.
> For such cases it would be good to provide an "abort" operation as part of
> {{IndexStatsMBean}} which user can invoke to abort any run safely and cleanly
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4512) Detect and log commits to the read-only stores
[ https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4512: - Attachment: OAK-4512-patch.diff Simplified the OSGi part and updated patch. > Detect and log commits to the read-only stores > -- > > Key: OAK-4512 > URL: https://issues.apache.org/jira/browse/OAK-4512 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4512-patch.diff > > > Since the read-only stores will be immutable we should be able to detect > commits made against them and log an error message via a commit validation > provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4513) Detect and log references across stores
[ https://issues.apache.org/jira/browse/OAK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4513: - Attachment: (was: OAK-4513-patch.diff) > Detect and log references across stores > --- > > Key: OAK-4513 > URL: https://issues.apache.org/jira/browse/OAK-4513 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4513-patch.diff > > > References across different stores will not be allowed at runtime, we need a > commit validator to detect and log such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4513) Detect and log references across stores
[ https://issues.apache.org/jira/browse/OAK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4513: - Attachment: OAK-4513-patch.diff Simplified the OSGi part and updated patch. > Detect and log references across stores > --- > > Key: OAK-4513 > URL: https://issues.apache.org/jira/browse/OAK-4513 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > Attachments: OAK-4513-patch.diff > > > References across different stores will not be allowed at runtime, we need a > commit validator to detect and log such cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4512) Detect and log commits to the read-only stores
[ https://issues.apache.org/jira/browse/OAK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florin Iordache updated OAK-4512: - Attachment: (was: OAK-4512-patch.diff) > Detect and log commits to the read-only stores > -- > > Key: OAK-4512 > URL: https://issues.apache.org/jira/browse/OAK-4512 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Florin Iordache > > Since the read-only stores will be immutable we should be able to detect > commits made against them and log an error message via a commit validation > provider. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4525) Unreferenced node records are not marked as root records in the segment
[ https://issues.apache.org/jira/browse/OAK-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-4525. - Resolution: Fixed The problem mentioned above has been fixed at r1751254. > Unreferenced node records are not marked as root records in the segment > --- > > Key: OAK-4525 > URL: https://issues.apache.org/jira/browse/OAK-4525 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: Segment Tar 0.0.4 > > > When a new node record is written, if that record is not referenced by any > other record in the segment, it should be marked as a root record in the > segment header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4035) AsyncIndexUpdate should not log exception when its forcibly stopped
[ https://issues.apache.org/jira/browse/OAK-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-4035: - Fix Version/s: 1.0.32 > AsyncIndexUpdate should not log exception when its forcibly stopped > --- > > Key: OAK-4035 > URL: https://issues.apache.org/jira/browse/OAK-4035 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.4, 1.4.0, 1.2.15, 1.0.32 > > > While shutdown when an index is forced to stop then it logs a exception > message indicating that indexing has been stopped. This is done at warn level. > As this is an expected scenario the exception should not be logged at warn > level and just a info level message indicating that indexing is interrupted > should be logged -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4035) AsyncIndexUpdate should not log exception when its forcibly stopped
[ https://issues.apache.org/jira/browse/OAK-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276271#comment-15276271 ] Chetan Mehrotra edited comment on OAK-4035 at 7/4/16 11:42 AM: --- Merged back * 1.2 - [1742928|http://svn.apache.org/r1742928] * 1.0 - [1751252|http://svn.apache.org/r1751252] was (Author: chetanm): Merged back * 1.2 - [1742928|http://svn.apache.org/r1742928] > AsyncIndexUpdate should not log exception when its forcibly stopped > --- > > Key: OAK-4035 > URL: https://issues.apache.org/jira/browse/OAK-4035 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.4, 1.4.0, 1.2.15, 1.0.32 > > > While shutdown when an index is forced to stop then it logs a exception > message indicating that indexing has been stopped. This is done at warn level. > As this is an expected scenario the exception should not be logged at warn > level and just a info level message indicating that indexing is interrupted > should be logged -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3923) Async indexing delayed by 30 minutes because stop order is incorrect
[
https://issues.apache.org/jira/browse/OAK-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3923:
-
Labels: (was: candidate_oak_1_0)
Fix Version/s: 1.0.32
Merged to 1.0 with 1751250
> Async indexing delayed by 30 minutes because stop order is incorrect
>
>
> Key: OAK-3923
> URL: https://issues.apache.org/jira/browse/OAK-3923
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Thomas Mueller
>Assignee: Chetan Mehrotra
> Fix For: 1.4, 1.2.11, 1.3.15, 1.0.32
>
> Attachments: OAK-3923-v1.patch
>
>
> The stop order of Oak components is incorrect, and this can lead to an async
> indexing delay of 30 minutes, because the indexing lease is not removed. The
> problem is that the node store is stopped before the async index is stopped,
> so that async indexing can still be in progress, and then when async indexing
> is done, the lease can not be removed because the node store is not available.
> From the log file:
> {noformat}
> error.log:
> 21.01.2016 11:53:56.898 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-tarmk-standby BundleEvent STOPPED
> 21.01.2016 11:53:56.900 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-solr-osgi Service
> [org.apache.jackrabbit.oak.plugins.index.solr.osgi.SolrIndexEditorProviderService,571,
> [org.apache.jackrabbit.oak.plugins.index.IndexEditorProvider]] ServiceEvent
> UNREGISTERING
> ...
> 21.01.2016 11:53:56.930 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-lucene BundleEvent STOPPING
> 21.01.2016 11:53:56.930 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-lucene BundleEvent STOPPED
> 21.01.2016 11:53:56.931 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-core Service
> [org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexProvider,405,
> [org.apache.jackrabbit.oak.spi.query.QueryIndexProvider]] ServiceEvent
> UNREGISTERING
> ...
> 21.01.2016 11:53:56.936 *INFO* [FelixStartLevel]
> com.adobe.granite.repository.impl.SlingRepositoryManager stop: Repository
> still running, forcing shutdown
> ...
> 21.01.2016 11:53:56.960 *WARN* [FelixStartLevel]
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard Error unregistering service:
> com.adobe.granite.repository.impl.SlingRepositoryManager$1@7c052458 of type
> java.util.concurrent.Executor
> java.lang.IllegalStateException: Service already unregistered.
> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:136)
> at
> org.apache.jackrabbit.oak.osgi.OsgiWhiteboard$1.unregister(OsgiWhiteboard.java:81)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.CompositeRegistration.unregister(CompositeRegistration.java:43)
> at org.apache.jackrabbit.oak.Oak$6.close(Oak.java:592)
> ...
> 21.01.2016 11:56:50.985 *INFO* [FelixStartLevel]
> org.apache.jackrabbit.oak-core Service [763,
> [org.apache.jackrabbit.oak.plugins.segment.SegmentStoreProvider]]
> ServiceEvent UNREGISTERING
>
> debug.log:
> 21.01.2016 11:56:51.964 *WARN* [sling-default-4]
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate [async] The index
> update failed
> java.lang.IllegalStateException: service must be activated when used
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:150)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:233)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:92)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.getRoot(ProxyNodeStore.java:36)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate$AsyncUpdateCallback.close(AsyncIndexUpdate.java:266)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:451)
> at
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:351)
>
> error.log:
> 21.01.2016 11:56:51.965 *ERROR* [sling-default-4]
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
> execution of
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@1706b18c : service
> must be activated when used
> java.lang.IllegalStateException: service must be activated when used
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:150)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:233)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeStoreService.getNodeStore(SegmentNodeStoreService.java:92)
> at
> org.apache.jackrabbit.oak.spi.state.ProxyNodeStore.release(ProxyNodeStore.java:
[jira] [Reopened] (OAK-4525) Unreferenced node records are not marked as root records in the segment
[ https://issues.apache.org/jira/browse/OAK-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari reopened OAK-4525: - Reopening this issue because the fix introduces a regression. The record ID used as a stable ID should not create a reference only when the written node record is new, but it should create one when a stable ID is copied from an existing node record. > Unreferenced node records are not marked as root records in the segment > --- > > Key: OAK-4525 > URL: https://issues.apache.org/jira/browse/OAK-4525 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segment-tar >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: Segment Tar 0.0.4 > > > When a new node record is written, if that record is not referenced by any > other record in the segment, it should be marked as a root record in the > segment header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3436) Prevent missing checkpoint due to unstable topology from causing complete reindexing
[
https://issues.apache.org/jira/browse/OAK-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3436:
-
Labels: resilience (was: candidate_oak_1_0 resilience)
Fix Version/s: 1.0.32
Merged to 1.0 with
* [1751245|http://svn.apache.org/r1751245]
* [1751246|http://svn.apache.org/r1751246]
* [1751247|http://svn.apache.org/r1751247]
> Prevent missing checkpoint due to unstable topology from causing complete
> reindexing
>
>
> Key: OAK-3436
> URL: https://issues.apache.org/jira/browse/OAK-3436
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Chetan Mehrotra
>Assignee: Alex Parvulescu
> Labels: resilience
> Fix For: 1.4, 1.3.13, 1.2.10, 1.0.32
>
> Attachments: AsyncIndexUpdateClusterTest.java, OAK-3436-0.patch,
> OAK-3436-part2-v2.patch, OAK-3436-part2.patch, OAK-3436-tests.patch,
> OAK-3436-v2.patch
>
>
> Async indexing logic relies on embedding application to ensure that async
> indexing job is run as a singleton in a cluster. For Sling based apps it
> depends on Sling Discovery support. At times it is being seen that if
> topology is not stable then different cluster nodes can consider them as
> leader and execute the async indexing job concurrently.
> This can cause problem as both cluster node might not see same repository
> state (due to write skew and eventual consistency) and might remove the
> checkpoint which other cluster node is still relying upon. For e.g. consider
> a 2 node cluster N1 and N2 where both are performing async indexing.
> # Base state - CP1 is the checkpoint for "async" job
> # N2 starts indexing and removes changes CP1 to CP2. For Mongo the
> checkpoints are saved in {{settings}} collection
> # N1 also decides to execute indexing but has yet not seen the latest
> repository state so still thinks that CP1 is the base checkpoint and tries to
> read it. However CP1 is already removed from {{settings}} and this makes N1
> think that checkpoint is missing and it decides to reindex everything!
> To avoid this topology must be stable but at Oak level we should still handle
> such a case and avoid doing a full reindexing. So we would need to have a
> {{MissingCheckpointStrategy}} similar to {{MissingIndexEditorStrategy}} as
> done in OAK-2203
> Possible approaches
> # A1 - Fail the indexing run if checkpoint is missing - Checkpoint being
> missing can have valid reason and invalid reason. Need to see what are valid
> scenarios where a checkpoint can go missing
> # A2 - When a checkpoint is created also store the creation time. When a
> checkpoint is found to be missing and its a *recent* checkpoint then fail the
> run. For e.g. we would fail the run till checkpoint found to be missing is
> less than an hour old (for just started take startup time into account)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361159#comment-15361159 ] Ian Boston commented on OAK-4529: - The situation that this issue is trying to protect against is something like this: 1. Oak production running at 1.0.x 2. Production JVM stopped 3. oak-run 1.4 mistakenly used to perform some maintenance. (should have been oak-run 1.0.x) 4. Production JVM wont start. bq. So, I think what's more important is for DNS instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. I think that will cause the issue, not prevent it ? imho, Oak should refuse to write to an older repository, where those writes would break that repository for older versions of Oak listed as in use in the repository, unless some form of override is provided eg (eg -Doak.allowRepositoryUpgrade=true), or the versions are removed from the active list in the repository. If later versions of Oak cant read older repositories, they should refuse to start, hence the suggestion that DocumentNodeStore should use a range of version to determine what is safe. BTW. Perhaps its best not to use DNS when talking about DocumentNodeStore as DNS is widely accepted to mean https://en.wikipedia.org/wiki/Domain_Name_System and could cause confusion in without context. > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4531) Release Oak 1.5.5
Davide Giannella created OAK-4531: - Summary: Release Oak 1.5.5 Key: OAK-4531 URL: https://issues.apache.org/jira/browse/OAK-4531 Project: Jackrabbit Oak Issue Type: Task Reporter: Davide Giannella Assignee: Davide Giannella -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3753) Test failure: HeavyWriteIT
[
https://issues.apache.org/jira/browse/OAK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361125#comment-15361125
]
Davide Giannella edited comment on OAK-3753 at 7/4/16 10:26 AM:
re-opening and making a blocker as it consistently fails on my local while
performing pre-release checks. Full [maven build logs|^build-1467624994.log.gz]
/cc [~alex.parvulescu]
was (Author: edivad):
re-opening and making a blocker as it consistently fails on my local while
performing pre-release checks. Full [maven build logs|^build-1467624994.log.gz]
> Test failure: HeavyWriteIT
> --
>
> Key: OAK-3753
> URL: https://issues.apache.org/jira/browse/OAK-3753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: ci, jenkins
> Fix For: 1.6, 1.5.5
>
> Attachments: build-1467624994.log.gz
>
>
> {{org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT}} failed on Jenkins:
> {noformat}
> heavyWrite[usePersistedMap:
> false](org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT) Time elapsed:
> 106.519 sec <<< ERROR!
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:214)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:198)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1177)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:224)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.RecordId.getSegment(RecordId.java:88)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readTemplate(Segment.java:506)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:381)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:651)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.access$300(MemoryNodeBuilder.java:88)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:650)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:273)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createProperties(HeavyWriteIT.java:156)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite(HeavyWriteIT.java:129)
> {noformat}
> Seen at build 597
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2343) Wrong handling of InterruptedException in BackgroundThread
[
https://issues.apache.org/jira/browse/OAK-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361137#comment-15361137
]
Alex Parvulescu commented on OAK-2343:
--
merged to 1.0 with r1751243
> Wrong handling of InterruptedException in BackgroundThread
> --
>
> Key: OAK-2343
> URL: https://issues.apache.org/jira/browse/OAK-2343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.1.4, 1.0.32
>
>
> {{BackgroundThread}} catches {{InterruptedException}} but doesn't set the
> thread's interrupted status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2343) Wrong handling of InterruptedException in BackgroundThread
[
https://issues.apache.org/jira/browse/OAK-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2343:
-
Fix Version/s: 1.0.32
> Wrong handling of InterruptedException in BackgroundThread
> --
>
> Key: OAK-2343
> URL: https://issues.apache.org/jira/browse/OAK-2343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.1.4, 1.0.32
>
>
> {{BackgroundThread}} catches {{InterruptedException}} but doesn't set the
> thread's interrupted status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2343) Wrong handling of InterruptedException in BackgroundThread
[
https://issues.apache.org/jira/browse/OAK-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-2343:
-
Labels: resilience (was: )
> Wrong handling of InterruptedException in BackgroundThread
> --
>
> Key: OAK-2343
> URL: https://issues.apache.org/jira/browse/OAK-2343
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience
> Fix For: 1.1.4
>
>
> {{BackgroundThread}} catches {{InterruptedException}} but doesn't set the
> thread's interrupted status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4137) BackgroundThread should log and re-throw instances of Error
[
https://issues.apache.org/jira/browse/OAK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4137:
-
Fix Version/s: (was: 1.6)
> BackgroundThread should log and re-throw instances of Error
> ---
>
> Key: OAK-4137
> URL: https://issues.apache.org/jira/browse/OAK-4137
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
> Labels: resilience
>
> If the run method of a {{BackgroundThread}} instance hits an {{Error}} it
> dies silently. Instead it should log an re-throw the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-4137) BackgroundThread should log and re-throw instances of Error
[
https://issues.apache.org/jira/browse/OAK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-4137:
-
Labels: resilience (was: candidate_oak_1_0 candidate_oak_1_2
candidate_oak_1_4 resilience)
> BackgroundThread should log and re-throw instances of Error
> ---
>
> Key: OAK-4137
> URL: https://issues.apache.org/jira/browse/OAK-4137
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segmentmk
>Reporter: Michael Dürig
> Labels: resilience
>
> If the run method of a {{BackgroundThread}} instance hits an {{Error}} it
> dies silently. Instead it should log an re-throw the error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361131#comment-15361131 ] Marcel Reutegger commented on OAK-3079: --- Partially merged into 1.0 branch with: http://svn.apache.org/r1751239 (test only). This issue does not affect 1.0 branch, hence no fix is needed there. > LastRevRecoveryAgent can update _lastRev of children but not the root > - > > Key: OAK-3079 > URL: https://issues.apache.org/jira/browse/OAK-3079 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.2, 1.3.2 >Reporter: Stefan Egli >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.4, 1.3.5, 1.2.17 > > Attachments: NonRootUpdatingLastRevRecoveryTest.java > > > As mentioned in > [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] > there can be a situation wherein the LastRevRecoveryAgent updates some nodes > in the tree but not the root. This seems to happen due to OAK-2131's change > in the Commit.applyToCache (where paths to update are collected via > tracker.track): in that code, paths which are non-root and for which no > content has changed (and mind you, a content change includes adding _deleted, > which happens by default for nodes with children) are not 'tracked', ie for > those the _lastRev is not update by subsequent backgroundUpdate operations - > leaving them 'old/out-of-date'. This seems correct as per > description/intention of OAK-2131 where the last revision can be determined > via the commitRoot of the parent. But it has the effect that the > LastRevRecoveryAgent then finds those intermittent nodes to be updated while > as the root has already been updated (which is at first glance non-intuitive). > I'll attach a test case to reproduce this. > Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3079) LastRevRecoveryAgent can update _lastRev of children but not the root
[ https://issues.apache.org/jira/browse/OAK-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3079: -- Labels: resilience (was: candidate_oak_1_2 resilience) Fix Version/s: 1.2.17 Merged into 1.2 branch: http://svn.apache.org/r1751238 > LastRevRecoveryAgent can update _lastRev of children but not the root > - > > Key: OAK-3079 > URL: https://issues.apache.org/jira/browse/OAK-3079 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, mongomk >Affects Versions: 1.2, 1.3.2 >Reporter: Stefan Egli >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.4, 1.3.5, 1.2.17 > > Attachments: NonRootUpdatingLastRevRecoveryTest.java > > > As mentioned in > [OAK-2131|https://issues.apache.org/jira/browse/OAK-2131?focusedCommentId=14616391&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14616391] > there can be a situation wherein the LastRevRecoveryAgent updates some nodes > in the tree but not the root. This seems to happen due to OAK-2131's change > in the Commit.applyToCache (where paths to update are collected via > tracker.track): in that code, paths which are non-root and for which no > content has changed (and mind you, a content change includes adding _deleted, > which happens by default for nodes with children) are not 'tracked', ie for > those the _lastRev is not update by subsequent backgroundUpdate operations - > leaving them 'old/out-of-date'. This seems correct as per > description/intention of OAK-2131 where the last revision can be determined > via the commitRoot of the parent. But it has the effect that the > LastRevRecoveryAgent then finds those intermittent nodes to be updated while > as the root has already been updated (which is at first glance non-intuitive). > I'll attach a test case to reproduce this. > Perhaps this is a bug, perhaps it's ok. [~mreutegg] wdyt? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3753) Test failure: HeavyWriteIT
[
https://issues.apache.org/jira/browse/OAK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3753:
--
Attachment: build-1467624994.log.gz
re-opening and making a blocker as it consistently fails on my local while
performing pre-release checks. Full [maven build logs|^build-1467624994.log.gz]
> Test failure: HeavyWriteIT
> --
>
> Key: OAK-3753
> URL: https://issues.apache.org/jira/browse/OAK-3753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: ci, jenkins
> Fix For: 1.6, 1.5.5
>
> Attachments: build-1467624994.log.gz
>
>
> {{org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT}} failed on Jenkins:
> {noformat}
> heavyWrite[usePersistedMap:
> false](org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT) Time elapsed:
> 106.519 sec <<< ERROR!
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:214)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:198)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1177)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:224)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.RecordId.getSegment(RecordId.java:88)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readTemplate(Segment.java:506)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:381)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:651)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.access$300(MemoryNodeBuilder.java:88)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:650)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:273)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createProperties(HeavyWriteIT.java:156)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite(HeavyWriteIT.java:129)
> {noformat}
> Seen at build 597
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3753) Test failure: HeavyWriteIT
[
https://issues.apache.org/jira/browse/OAK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3753:
--
Priority: Blocker (was: Critical)
> Test failure: HeavyWriteIT
> --
>
> Key: OAK-3753
> URL: https://issues.apache.org/jira/browse/OAK-3753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: ci, jenkins
> Fix For: 1.6, 1.5.5
>
>
> {{org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT}} failed on Jenkins:
> {noformat}
> heavyWrite[usePersistedMap:
> false](org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT) Time elapsed:
> 106.519 sec <<< ERROR!
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:214)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:198)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1177)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:224)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.RecordId.getSegment(RecordId.java:88)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readTemplate(Segment.java:506)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:381)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:651)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.access$300(MemoryNodeBuilder.java:88)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:650)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:273)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createProperties(HeavyWriteIT.java:156)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite(HeavyWriteIT.java:129)
> {noformat}
> Seen at build 597
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3753) Test failure: HeavyWriteIT
[
https://issues.apache.org/jira/browse/OAK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-3753:
--
Fix Version/s: 1.5.5
1.6
> Test failure: HeavyWriteIT
> --
>
> Key: OAK-3753
> URL: https://issues.apache.org/jira/browse/OAK-3753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: ci, jenkins
> Fix For: 1.6, 1.5.5
>
>
> {{org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT}} failed on Jenkins:
> {noformat}
> heavyWrite[usePersistedMap:
> false](org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT) Time elapsed:
> 106.519 sec <<< ERROR!
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:214)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:198)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1177)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:224)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.RecordId.getSegment(RecordId.java:88)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readTemplate(Segment.java:506)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:381)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:651)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.access$300(MemoryNodeBuilder.java:88)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:650)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:273)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createProperties(HeavyWriteIT.java:156)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite(HeavyWriteIT.java:129)
> {noformat}
> Seen at build 597
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (OAK-3753) Test failure: HeavyWriteIT
[
https://issues.apache.org/jira/browse/OAK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella reopened OAK-3753:
---
> Test failure: HeavyWriteIT
> --
>
> Key: OAK-3753
> URL: https://issues.apache.org/jira/browse/OAK-3753
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: ci, jenkins
>
> {{org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT}} failed on Jenkins:
> {noformat}
> heavyWrite[usePersistedMap:
> false](org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT) Time elapsed:
> 106.519 sec <<< ERROR!
> java.lang.IllegalStateException
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:134)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:214)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.(Segment.java:198)
> at
> org.apache.jackrabbit.oak.plugins.segment.file.FileStore.readSegment(FileStore.java:1177)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentTracker.readSegment(SegmentTracker.java:224)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentId.getSegment(SegmentId.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.RecordId.getSegment(RecordId.java:88)
> at
> org.apache.jackrabbit.oak.plugins.segment.Segment.readTemplate(Segment.java:506)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getTemplate(SegmentNodeState.java:79)
> at
> org.apache.jackrabbit.oak.plugins.segment.SegmentNodeState.getChildNode(SegmentNodeState.java:381)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:651)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.access$300(MemoryNodeBuilder.java:88)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$UnconnectedHead.update(MemoryNodeBuilder.java:650)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder$ConnectedHead.update(MemoryNodeBuilder.java:729)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.head(MemoryNodeBuilder.java:171)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.exists(MemoryNodeBuilder.java:273)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createProperties(HeavyWriteIT.java:156)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:148)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.createNodes(HeavyWriteIT.java:149)
> at
> org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite(HeavyWriteIT.java:129)
> {noformat}
> Seen at build 597
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361122#comment-15361122 ] Vikas Saurabh commented on OAK-4529: bq. check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. I think utilities like oak-run are always able to read and old format. The issue, of course is that once they write out some data using a potentially new format then the oak version (presumably old) which was using the repo might get confused (e.g. oak-run at trunk would write out revision vectors for checkpoints which would confuse old oak at 1.0 or 1.2). So, I think what's more important is for DNS instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
[ https://issues.apache.org/jira/browse/OAK-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361122#comment-15361122 ] Vikas Saurabh edited comment on OAK-4529 at 7/4/16 10:08 AM: - bq. check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. I think utilities like oak-run are always able to read an old format. The issue, of course is that once they write out some data using a potentially new format then the oak version (presumably old) which was using the repo might get confused (e.g. oak-run at trunk would write out revision vectors for checkpoints which would confuse old oak at 1.0 or 1.2). So, I think what's more important is for DNS instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. was (Author: catholicon): bq. check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. I think utilities like oak-run are always able to read and old format. The issue, of course is that once they write out some data using a potentially new format then the oak version (presumably old) which was using the repo might get confused (e.g. oak-run at trunk would write out revision vectors for checkpoints which would confuse old oak at 1.0 or 1.2). So, I think what's more important is for DNS instance to be initialized with the fact that the repository needs to be accessible by an older version of oak after any writes that this one does. > DocumentNodeStore does not have a repository software version range check. > -- > > Key: OAK-4529 > URL: https://issues.apache.org/jira/browse/OAK-4529 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.2.14, 1.0.31, 1.5.4, 1.4.4 >Reporter: Ian Boston > > DocumentNodeStore does not currently check which software version the > persisted repository it is connecting to was created with or last updated. > There is a risk that if the versions are incompatible the repository may be > damaged. > Somewhere in the repository, the version of the software that created it, and > the versions that written to it should be stored. In the case of TarMK this > information could be on local disk near the TarMK files. In the case of a > DocumentMK implementation, the information should be stored in the "database" > itself. > When a DocumentNodeStore instance connects it should: check the versions > stored in the repository then check the versions are within a compatible > range and refuse to start if not. > When a DocumentNodeStore writes to a repository, it should add its version to > the list of versions that have updated the repository. > This check behaviour should be active in full Oak or any utilities (eg > oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-4530) Session modification discarded when repository closed too soon
Marco Piovesana created OAK-4530:
Summary: Session modification discarded when repository closed too
soon
Key: OAK-4530
URL: https://issues.apache.org/jira/browse/OAK-4530
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.4.4
Reporter: Marco Piovesana
If I close the repository right after creating a new group (and saving the
session) the modification is not persisted.
{code: borderStyle=solid}
UserManager userManager = ((SessionImpl)adminSession).getUserManager();
Group group = userManager.createGroup("myGroup");
adminSession.save();
adminSession.logout();
((JackrabbitRepository) repository).shutdown();
{code}
When i restart the repository the group "myGroup" does not exist but no error
is logged anywhere. However, if i put a _Thread.sleep(3000l)_ before shutting
down the repository, the group is persisted.
Am I doing something wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
[
https://issues.apache.org/jira/browse/OAK-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-3629:
-
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was: )
> Index corruption seen with CopyOnRead when index defnition is recreated
> ---
>
> Key: OAK-3629
> URL: https://issues.apache.org/jira/browse/OAK-3629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.6, 1.5.5
>
>
> CopyOnRead logic relies on {{reindexCount}} to determine the name of
> directory in which index files would be copied. In normal flow if the index
> is reindexed then this count would get increased and newer index files would
> get copied to a new directory.
> However if the index definition node gets recreated due to some deployment
> process then this count gets reset to 0. Due to which newly created index
> files from reindexing would start getting copied to already existing
> directory and that can lead to corruption.
> So what happened here was
> # System started with index definition I1 and indexing got complete with
> index files saved under index/hash(indexpath)/1 (where 1 is current reindex
> count)
> # A new index definition package was deployed which reset the index count.
> Now reindex happened again and the CopyOnRead logic per current design reused
> the existing index directory. And it so happens that Lucene create file with
> same name and same size but different content. This trips the CopyOnRead
> defense of length based index corruption check and thus cause new lucene
> index to corrupt
> *Note that here corruption is transient i.e. persisted index is not
> corrupted*. Just that locally copied index gets corrupted. Cleaning up the
> index directory would fix the issue and that can be used as a workaround.
> *Fix*
> After discussing with [~tmueller] following approach can be used.
> Instead of relying on reindex count we can maintain a hidden randomly
> generated uuid and store it in the index config. This would be used to derive
> the name of directory on filesystem. If the index definition gets reset then
> the uuid can be regenerated.
> *Workaround*
> Clean the directory used by CopyOnRead which is /index before
> restart
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
[
https://issues.apache.org/jira/browse/OAK-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3629.
--
Resolution: Fixed
Fix Version/s: 1.5.5
> Index corruption seen with CopyOnRead when index defnition is recreated
> ---
>
> Key: OAK-3629
> URL: https://issues.apache.org/jira/browse/OAK-3629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Fix For: 1.6, 1.5.5
>
>
> CopyOnRead logic relies on {{reindexCount}} to determine the name of
> directory in which index files would be copied. In normal flow if the index
> is reindexed then this count would get increased and newer index files would
> get copied to a new directory.
> However if the index definition node gets recreated due to some deployment
> process then this count gets reset to 0. Due to which newly created index
> files from reindexing would start getting copied to already existing
> directory and that can lead to corruption.
> So what happened here was
> # System started with index definition I1 and indexing got complete with
> index files saved under index/hash(indexpath)/1 (where 1 is current reindex
> count)
> # A new index definition package was deployed which reset the index count.
> Now reindex happened again and the CopyOnRead logic per current design reused
> the existing index directory. And it so happens that Lucene create file with
> same name and same size but different content. This trips the CopyOnRead
> defense of length based index corruption check and thus cause new lucene
> index to corrupt
> *Note that here corruption is transient i.e. persisted index is not
> corrupted*. Just that locally copied index gets corrupted. Cleaning up the
> index directory would fix the issue and that can be used as a workaround.
> *Fix*
> After discussing with [~tmueller] following approach can be used.
> Instead of relying on reindex count we can maintain a hidden randomly
> generated uuid and store it in the index config. This would be used to derive
> the name of directory on filesystem. If the index definition gets reset then
> the uuid can be regenerated.
> *Workaround*
> Clean the directory used by CopyOnRead which is /index before
> restart
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3629) Index corruption seen with CopyOnRead when index defnition is recreated
[
https://issues.apache.org/jira/browse/OAK-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356914#comment-15356914
]
Chetan Mehrotra edited comment on OAK-3629 at 7/4/16 9:35 AM:
--
*Implementation Details*
To fix this issue we have changed the directory structure which is used for
local storage. Now for each reindex of index at given JCR path a new directory
would be created
{noformat}
lucene-1467282418224
├── default
│ ├── ...
│ ├── segments_2
│ └── segments.gen
└── index-details.txt
{noformat}
* Top level dir -
** index path - This would consist of max last 2 elements of indexpath
excluding oak:index and only having safe chars a-zA-Z0-9_. All other chars
would be removed. Using the actual index name simplifies mapping the index dir
on filesystem with actual index path in JCR
** uid - Unique id as set in index config (details below)
* {{default}} - The top dir is a container. For a Oak Lucene index at any path
there can be multiple actual Lucene directory. Currently we have a "default"
which maps to ":data". Later we can also store suggest index etc (OAK-3916)
* {{index-details.txt}} - This contains certain metadata like timestamp when
index directory was created on the filesystem, index JCR path
*Unique Id*
{{LuceneIndexEditorContext}} would generate and store a unique id which per
current impl is timestamp (always increasing via Clock API). Once generated
this would be stored under /:status/uid. In case of reindex all
such hidden nodes get removed and this would cause regenration of the unique
id. This id would then be combined with index name (derived from path).
if index gets reindexed then it would lead to newer directory name. This would
ensure that directory names do not collide for given cluster node
*Garbage Collection*
Garbage collection i.e. removing old index directory in case of reindex logic
has been changed. Now it has 2 modes
On each start of system it would scan the indexRootDirectory and check if there
are multiple container folder for same JCR index then only the latest folder
would be retained and rest all would be deleted. Its safe to remove on start as
its ensured that no other logic is accessing the indexes
Further upon each reindex once the previous directory is closed it would delete
the default index directory in older folder and then check if the container
folder is empty. If empty then such folders would also be removed
This would ensure that even for reindex case older directories are removed with
time
* trunk
** 1750769 - Base implementation
** 1751236 - Garbage collection
was (Author: chetanm):
*Implementation Details*
To fix this issue we have changed the directory structure which is used for
local storage. Now for each reindex of index at given JCR path a new directory
would be created
{noformat}
lucene-1467282418224
├── default
│ ├── ...
│ ├── segments_2
│ └── segments.gen
└── index-details.txt
{noformat}
* Top level dir -
** index path - This would consist of max last 2 elements of indexpath
excluding oak:index and only having safe chars a-zA-Z0-9_. All other chars
would be removed. Using the actual index name simplifies mapping the index dir
on filesystem with actual index path in JCR
** uid - Unique id as set in index config (details below)
* {{default}} - The top dir is a container. For a Oak Lucene index at any path
there can be multiple actual Lucene directory. Currently we have a "default"
which maps to ":data". Later we can also store suggest index etc (OAK-3916)
* {{index-details.txt}} - This contains certain metadata like timestamp when
index directory was created on the filesystem, index JCR path
*Unique Id*
{{LuceneIndexEditorContext}} would generate and store a unique id which per
current impl is timestamp (always increasing via Clock API). Once generated
this would be stored under /:status/uid. In case of reindex all
such hidden nodes get removed and this would cause regenration of the unique
id. This id would then be combined with index name (derived from path).
if index gets reindexed then it would lead to newer directory name. This would
ensure that directory names do not collide for given cluster node
* trunk
** 1750769 - Base implementation
*Pending Stuff*
* Support index dir with current node name and parent
* Support for garbage collection of empty dir as index updates with reindexing
> Index corruption seen with CopyOnRead when index defnition is recreated
> ---
>
> Key: OAK-3629
> URL: https://issues.apache.org/jira/browse/OAK-3629
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Blocker
> Fix For: 1.6
>
>
> CopyOn
[jira] [Created] (OAK-4529) DocumentNodeStore does not have a repository software version range check.
Ian Boston created OAK-4529: --- Summary: DocumentNodeStore does not have a repository software version range check. Key: OAK-4529 URL: https://issues.apache.org/jira/browse/OAK-4529 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.4.4, 1.5.4, 1.0.31, 1.2.14 Reporter: Ian Boston DocumentNodeStore does not currently check which software version the persisted repository it is connecting to was created with or last updated. There is a risk that if the versions are incompatible the repository may be damaged. Somewhere in the repository, the version of the software that created it, and the versions that written to it should be stored. In the case of TarMK this information could be on local disk near the TarMK files. In the case of a DocumentMK implementation, the information should be stored in the "database" itself. When a DocumentNodeStore instance connects it should: check the versions stored in the repository then check the versions are within a compatible range and refuse to start if not. When a DocumentNodeStore writes to a repository, it should add its version to the list of versions that have updated the repository. This check behaviour should be active in full Oak or any utilities (eg oak-run). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3306) Create a copy of MemoryDocumentStore
[ https://issues.apache.org/jira/browse/OAK-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3306: -- Fix Version/s: 1.2.17 1.0.32 Merged into branches: - 1.2: http://svn.apache.org/r1751229 - 1.0: http://svn.apache.org/r1751234 > Create a copy of MemoryDocumentStore > > > Key: OAK-3306 > URL: https://issues.apache.org/jira/browse/OAK-3306 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.4, 1.3.5, 1.0.32, 1.2.17 > > > For testing purposes it would be good to have a way to copy an existing > MemoryDocumentStore. This allows to perform checks on a snapshot of the > document store or create common test data for various tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3903) Commit fails even though change made it to the DocumentStore
[ https://issues.apache.org/jira/browse/OAK-3903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3903: -- Labels: resilience (was: candidate_oak_1_0 candidate_oak_1_2 resilience) Fix Version/s: 1.2.17 1.0.32 Merged into branches: - 1.2: http://svn.apache.org/r1751227 - 1.0: http://svn.apache.org/r1751232 > Commit fails even though change made it to the DocumentStore > > > Key: OAK-3903 > URL: https://issues.apache.org/jira/browse/OAK-3903 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: resilience > Fix For: 1.4, 1.3.15, 1.0.32, 1.2.17 > > > In some rare cases it may happen that the DocumentNodeStore considers a > commit as failed even though the changes were applied entirely to the > DocumentStore. The issue happens when the update of the commit root is > applied to the storage of a DocumentStore but then shortly after the > communication between Oak the the storage system fails. On the Oak side the > call will be considered as failed, but the change was actually applied. > The issue can be reproduced with the test attached to OAK-1641 and a > replica-set with 3 nodes. Killing the primary node and restarting it a after > a while in a loop will eventually lead to a commit that conflicts itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-4098) Implementation of clone function for shareable nodes
[ https://issues.apache.org/jira/browse/OAK-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15361021#comment-15361021 ] Marcel Reutegger commented on OAK-4098: --- There is no plan right now to support shareable nodes in the near future. The feature was not considered a primary goal when Oak was designed. I think the consensus was that the complexity of the feature outweighs the benefits and anticipated usage. If you have a strong need, I'd suggest you propose a patch. > Implementation of clone function for shareable nodes > > > Key: OAK-4098 > URL: https://issues.apache.org/jira/browse/OAK-4098 > Project: Jackrabbit Oak > Issue Type: Wish > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > is there any plan to support the _shareable node_ feature of JCR? > I'm working on a multiple users repository and this feature fits well the > idea of sharing the same node in different areas of the file system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3903) Commit fails even though change made it to the DocumentStore
[ https://issues.apache.org/jira/browse/OAK-3903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3903: -- Labels: candidate_oak_1_0 candidate_oak_1_2 resilience (was: resilience) > Commit fails even though change made it to the DocumentStore > > > Key: OAK-3903 > URL: https://issues.apache.org/jira/browse/OAK-3903 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Labels: candidate_oak_1_0, candidate_oak_1_2, resilience > Fix For: 1.4, 1.3.15 > > > In some rare cases it may happen that the DocumentNodeStore considers a > commit as failed even though the changes were applied entirely to the > DocumentStore. The issue happens when the update of the commit root is > applied to the storage of a DocumentStore but then shortly after the > communication between Oak the the storage system fails. On the Oak side the > call will be considered as failed, but the change was actually applied. > The issue can be reproduced with the test attached to OAK-1641 and a > replica-set with 3 nodes. Killing the primary node and restarting it a after > a while in a loop will eventually lead to a commit that conflicts itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-4454) Create consistent API in ExternalSort to write and read escaped line breaks
[
https://issues.apache.org/jira/browse/OAK-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain resolved OAK-4454.
Resolution: Fixed
> Create consistent API in ExternalSort to write and read escaped line breaks
> ---
>
> Key: OAK-4454
> URL: https://issues.apache.org/jira/browse/OAK-4454
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Labels: candidate_oak_1_4
> Fix For: 1.5.5
>
>
> ExternalSort while sorting uses {{EscapeUtils.unescapeLineBreaks}} to read
> lines. It is better if a new API is created with explicit expectations
> documented that the File being sorted has been properly escaped with
> {{EscapeUtils.escapeLineBreak}}.
> Otherwise, it will lead to situations like OAK-4441 where File is not escaped
> while writing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-4098) Implementation of clone function for shareable nodes
[ https://issues.apache.org/jira/browse/OAK-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360947#comment-15360947 ] Marco Piovesana commented on OAK-4098: -- Any news about the implementation of this functionality? Will it be supported again? Marco. > Implementation of clone function for shareable nodes > > > Key: OAK-4098 > URL: https://issues.apache.org/jira/browse/OAK-4098 > Project: Jackrabbit Oak > Issue Type: Wish > Components: jcr >Affects Versions: 1.3.16 >Reporter: Marco Piovesana > > is there any plan to support the _shareable node_ feature of JCR? > I'm working on a multiple users repository and this feature fits well the > idea of sharing the same node in different areas of the file system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
