[jira] [Created] (OAK-3679) Rollback to timestamp
Thomas Mueller created OAK-3679: --- Summary: Rollback to timestamp Key: OAK-3679 URL: https://issues.apache.org/jira/browse/OAK-3679 Project: Jackrabbit Oak Issue Type: New Feature Components: core, documentmk, segmentmk Reporter: Thomas Mueller We should have a feature to roll back to a certain point in time. The use case are: * undo a failed, large operation (for example upgrade, migration, installing a package), * on a copy of the repository, switch to an old state for reading old content * recover from a corruption (for example corruption due to incorrect "discovery" state, such as concurrent async index updates). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2037) Define standards for plan output
[ https://issues.apache.org/jira/browse/OAK-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2037: Fix Version/s: 1.4 > Define standards for plan output > > > Key: OAK-2037 > URL: https://issues.apache.org/jira/browse/OAK-2037 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Justin Edelson >Assignee: Thomas Mueller >Priority: Minor > Labels: tooling > Fix For: 1.4 > > > Currently, the syntax for the plan output is chaotic as it varies > significantly from index to index. Whereas some of this is expected - each > index type will have different data to output, Oak should provide some > standards about how a plan will appear. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3407) Configuration to pass suggestion fields through analyzer
[
https://issues.apache.org/jira/browse/OAK-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili updated OAK-3407:
-
Attachment: OAK-3407.0.patch
attached first draft patch
> Configuration to pass suggestion fields through analyzer
>
>
> Key: OAK-3407
> URL: https://issues.apache.org/jira/browse/OAK-3407
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: 1.3.12
>
> Attachments: OAK-3407.0.patch
>
>
> Currently, suggested phrases are fairly long. e.g. form {{SuggestTest}} with
> nodes containing {{in 2015 my fox is red, like mike's fox and john's fox}}
> and {{in 2015 a red fox is still a fox}} a suggest query for {{in 201}} the
> result would contain 2 suggestions (both the phrase independently).
> We should probably allow passing suggestion field thorough analyzer so that
> word level suggestions are possible. Moreover, that would also for suggestion
> to be available from middle of phrases e.g. suggestions for {{ite}} should
> give suggestion as {{item}} which, in turn, can search documents containing
> {{this is the most important item in the whole agenda}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-1828) Improved SegmentWriter
[
https://issues.apache.org/jira/browse/OAK-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15027079#comment-15027079
]
Michael Dürig commented on OAK-1828:
I just committed a pretty comprehensive refactoring of the {{SegmentWriter}}:
http://svn.apache.org/r1716466 Encapsulate the state of the segment being
written and its coordination wrt. concurrent access in a separate class
http://svn.apache.org/r1716467 Better encapsulate records cache
http://svn.apache.org/r1716468 Simplify flushing of segments
http://svn.apache.org/r1716469 Factor out duplicate align methods
http://svn.apache.org/r1716470 Eliminate passing the SegmentTracker into the
SegmentWriter
http://svn.apache.org/r1716471 Remove SegmentWriter.getTracker
http://svn.apache.org/r1716472 Move anonymous record writers to top level
http://svn.apache.org/r1716473 Some JavaDoc
As an immediate follow up we should come up with a better name for
{{SegmentBuilder}}. [~frm] came up with {{SegmentBufferWriter}} and I like the
idea as it writes segments and buffer implies the low level aspects it actually
handles. [~alex.parvulescu] WDYT?
> Improved SegmentWriter
> --
>
> Key: OAK-1828
> URL: https://issues.apache.org/jira/browse/OAK-1828
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: segmentmk
>Reporter: Jukka Zitting
>Assignee: Alex Parvulescu
>Priority: Minor
> Labels: technical_debt
> Fix For: 1.3.12
>
> Attachments: record-writers-v0.patch, record-writers-v1.patch,
> record-writers-v2.patch
>
>
> At about 1kLOC and dozens of methods, the SegmentWriter class currently a bit
> too complex for one of the key components of the TarMK. It also uses a
> somewhat non-obvious mix of synchronized and unsynchronized code to
> coordinate multiple concurrent threads that may be writing content at the
> same time. The synchronization blocks are also broader than what really would
> be needed, which in some cases causes unnecessary lock contention in
> concurrent write loads.
> To improve the readability and maintainability of the code, and to increase
> performance of concurrent writes, it would be useful to split part of the
> SegmentWriter functionality to a separate RecordWriter class that would be
> responsible for writing individual records into a segment. The
> SegmentWriter.prepare() method would return a new RecordWriter instance, and
> the higher-level SegmentWriter methods would use the returned instance for
> all the work that's currently guarded in synchronization blocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3646) Inconsistent read of hierarchy
[ https://issues.apache.org/jira/browse/OAK-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15028280#comment-15028280 ] Thomas Mueller commented on OAK-3646: - That sounds good to me. The RevisionComparator was my idea, and it was a bad idea. > It simply compares the revision with the revision vector to decide if the > revision is visible or not. Correct me if I'm wrong, the algorithm would be: for each revision in the document, get the upper bound revision from the RevisionVector, and compare it. Class name: what about RevisionHorizon? If it defines the line of what is visible. > Inconsistent read of hierarchy > --- > > Key: OAK-3646 > URL: https://issues.apache.org/jira/browse/OAK-3646 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is similar to OAK-3388, but about hierarchy information like which child > nodes exist at a given revision of the parent node. This issue only occurs in > a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3675) Create a logger for failed RDB queries
[ https://issues.apache.org/jira/browse/OAK-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026455#comment-15026455 ] Tomek Rękawek commented on OAK-3675: [~chetanm], thanks for the tip, I didn't know that. In this case I think the logger can be attached as a separate bundle and added to the DataSource OSGi configuration. Oak doesn't have to know about it at all, so I'll close this issue. > Create a logger for failed RDB queries > -- > > Key: OAK-3675 > URL: https://issues.apache.org/jira/browse/OAK-3675 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: rdbmk >Reporter: Tomek Rękawek >Priority: Minor > > For debugging and profiling purposes it could be useful to log all failed RDB > queries (in the same way the SlowQueryReport logs underperforming calls). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3612) The string/template cache of the SegmentWriter should be cleared before cleanup
[ https://issues.apache.org/jira/browse/OAK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari resolved OAK-3612. - Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.12 Fixed in r1716337. > The string/template cache of the SegmentWriter should be cleared before > cleanup > --- > > Key: OAK-3612 > URL: https://issues.apache.org/jira/browse/OAK-3612 > Project: Jackrabbit Oak > Issue Type: Bug > Components: segmentmk >Reporter: Francesco Mari >Assignee: Francesco Mari > Fix For: 1.3.12 > > Attachments: OAK-3612-01.patch > > > The string/template cache of the SegmentWriter > (org.apache.jackrabbit.oak.plugins.segment.SegmentWriter#records) is not > cleared before the cleanup phase. This might maintain in-memory references to > segments, thus preventing them to be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3672) SegmentDiscoveryLiteService does not persist clusterView.id
[
https://issues.apache.org/jira/browse/OAK-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026459#comment-15026459
]
Stefan Egli commented on OAK-3672:
--
[~asanso], from your point of view though we no longer need the stable
clusterId for the cookies, right?
> SegmentDiscoveryLiteService does not persist clusterView.id
> ---
>
> Key: OAK-3672
> URL: https://issues.apache.org/jira/browse/OAK-3672
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Affects Versions: 1.3.10
>Reporter: Stefan Egli
> Fix For: 1.4
>
>
> The discovery-lite-descriptor introduced with OAK-2844 has a property {{id}}
> that uniquely and persistently identifies a cluster. However, the
> {{SegmentDiscoveryLiteService}} creates this id upon each instance restart
> (by setting {{runtimeClusterId}}).
> This should be fixed to have this {{id}} persisted somehow.
> Note that the consequences of this id changing upon each restart is that the
> corresponding presumed-to-be-persistent {{ClusterView.id}} of the
> discovery.oak will also change upon restart. Which is a violation of the
> discovery API and upper level applications might thus misbehave in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1828) Improved SegmentWriter
[ https://issues.apache.org/jira/browse/OAK-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Parvulescu updated OAK-1828: - Attachment: record-writers-v2.patch final version of record writers patch :) fixed a bug, added some javadocs, cleaned the code up a bit > Improved SegmentWriter > -- > > Key: OAK-1828 > URL: https://issues.apache.org/jira/browse/OAK-1828 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: segmentmk >Reporter: Jukka Zitting >Assignee: Alex Parvulescu >Priority: Minor > Labels: technical_debt > Fix For: 1.3.12 > > Attachments: record-writers-v0.patch, record-writers-v1.patch, > record-writers-v2.patch > > > At about 1kLOC and dozens of methods, the SegmentWriter class currently a bit > too complex for one of the key components of the TarMK. It also uses a > somewhat non-obvious mix of synchronized and unsynchronized code to > coordinate multiple concurrent threads that may be writing content at the > same time. The synchronization blocks are also broader than what really would > be needed, which in some cases causes unnecessary lock contention in > concurrent write loads. > To improve the readability and maintainability of the code, and to increase > performance of concurrent writes, it would be useful to split part of the > SegmentWriter functionality to a separate RecordWriter class that would be > responsible for writing individual records into a segment. The > SegmentWriter.prepare() method would return a new RecordWriter instance, and > the higher-level SegmentWriter methods would use the returned instance for > all the work that's currently guarded in synchronization blocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3672) SegmentDiscoveryLiteService does not persist clusterView.id
[
https://issues.apache.org/jira/browse/OAK-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026564#comment-15026564
]
Stefan Egli commented on OAK-3672:
--
Discussed offline: higher level code does indeed rely on this clusterView.id to
be persisted
> SegmentDiscoveryLiteService does not persist clusterView.id
> ---
>
> Key: OAK-3672
> URL: https://issues.apache.org/jira/browse/OAK-3672
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Affects Versions: 1.3.10
>Reporter: Stefan Egli
> Fix For: 1.4
>
>
> The discovery-lite-descriptor introduced with OAK-2844 has a property {{id}}
> that uniquely and persistently identifies a cluster. However, the
> {{SegmentDiscoveryLiteService}} creates this id upon each instance restart
> (by setting {{runtimeClusterId}}).
> This should be fixed to have this {{id}} persisted somehow.
> Note that the consequences of this id changing upon each restart is that the
> corresponding presumed-to-be-persistent {{ClusterView.id}} of the
> discovery.oak will also change upon restart. Which is a violation of the
> discovery API and upper level applications might thus misbehave in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3645) RDBDocumentStore: server time detection for DB2 fails due to timezone/dst differences
[
https://issues.apache.org/jira/browse/OAK-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3645:
Assignee: Tomek Rękawek (was: Julian Reschke)
> RDBDocumentStore: server time detection for DB2 fails due to timezone/dst
> differences
> -
>
> Key: OAK-3645
> URL: https://issues.apache.org/jira/browse/OAK-3645
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.10, 1.2.8, 1.0.24
>Reporter: Julian Reschke
>Assignee: Tomek Rękawek
>
> We use {{CURRENT_TIMESTAMP(4)}} to ask the DB for it's system time.
> Apparently, at least with DB2, this might return a value that is off by a
> multiple of one hour (3600 * 1000ms) depending on whether the OAK instance
> and the DB run in different timezones.
> Known to work: both on the same machine.
> Known to fail: OAK in CET, DB2 in UTC, in which case we're getting a
> timestamp one hour in the past.
> At this time it's not clear whether the same problem occurs for other
> databases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3645) RDBDocumentStore: server time detection for DB2 fails due to timezone/dst differences
[
https://issues.apache.org/jira/browse/OAK-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026418#comment-15026418
]
Julian Reschke commented on OAK-3645:
-
IMHO the best way to address this would be to make a query that returns a
numerical value, optimally the ms-since-epoch. If that would work, we wouldn't
need to worry about TZ issues.
(Hopefully leap seconds do not creep in instead)
[~tomek.rekawek] can you look into this? The other tricky part is that we need
solutions for Oracle, DB2, SQLServer, MySQL, Postgres, Derby and H2...
> RDBDocumentStore: server time detection for DB2 fails due to timezone/dst
> differences
> -
>
> Key: OAK-3645
> URL: https://issues.apache.org/jira/browse/OAK-3645
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.10, 1.2.8, 1.0.24
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>
> We use {{CURRENT_TIMESTAMP(4)}} to ask the DB for it's system time.
> Apparently, at least with DB2, this might return a value that is off by a
> multiple of one hour (3600 * 1000ms) depending on whether the OAK instance
> and the DB run in different timezones.
> Known to work: both on the same machine.
> Known to fail: OAK in CET, DB2 in UTC, in which case we're getting a
> timestamp one hour in the past.
> At this time it's not clear whether the same problem occurs for other
> databases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3659) Stale document in RDBDocumentStore cache
[ https://issues.apache.org/jira/browse/OAK-3659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3659: Attachment: RDBCacheConsistencyIT.java After tuning the test (expectations and diagnostics) it seems that a failed findAndUpdate will cause the cached entry to go back in time. > Stale document in RDBDocumentStore cache > > > Key: OAK-3659 > URL: https://issues.apache.org/jira/browse/OAK-3659 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.7, 1.3.10, 1.0.23 >Reporter: Julian Reschke >Assignee: Julian Reschke > Attachments: RDBCacheConsistencyIT.java > > > The problem described in OAK-3103 applies to the RDBDocumentStore as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3595) Repository fails to start after definition of lucene property index with nullCheckEnabled on nt:base
[
https://issues.apache.org/jira/browse/OAK-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3595.
--
Resolution: Won't Fix
Resolving as Wont Fix for now as current behaviour is fail fast. For recovery
the user can use oak-run to modify the config or disable Lucene index provider.
So far only one such incident is seen. If the problem becomes frequent then we
can relook into better way for such cases
> Repository fails to start after definition of lucene property index with
> nullCheckEnabled on nt:base
>
>
> Key: OAK-3595
> URL: https://issues.apache.org/jira/browse/OAK-3595
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.2.4
>Reporter: Tom Blackford
>Assignee: Chetan Mehrotra
>Priority: Minor
>
> * Set up a Lucene property index beneath /oak:index node on the ‘nt:base’
> node type.
> * Add a property index for 'testProp'
> * On the property index definition, set the following properties:
> ** analyzed (Boolean) : true
> ** isRegexp (Boolean) : true
> ** name (String) : testProp
> ** nodeScopeIndex (Boolean) : true
> ** nullCheckEnabled (Boolean) : true
> ** propertyIndex (Boolean) : true
> ** useInExcerpt (Boolean) : true
> * The following exception will start appearing in the logs:
> {code}
> 05.11.2015 16:52:23.524 *ERROR* [pool-7-thread-1]
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job
> execution of
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate@6540caf4 :
> nullCheckEnabled can be set to true for property definition using regular
> expression
> java.lang.IllegalStateException: nullCheckEnabled can be set to true for
> property definition using regular expression
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.PropertyDefinition.validate(PropertyDefinition.java:200)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.PropertyDefinition.(PropertyDefinition.java:125)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition$IndexingRule.collectPropConfigs(IndexDefinition.java:830)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition$IndexingRule.(IndexDefinition.java:650)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.collectIndexRules(IndexDefinition.java:555)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.IndexDefinition.(IndexDefinition.java:217)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.(LuceneIndexEditorContext.java:143)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.(LuceneIndexEditor.java:134)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:63)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:52)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.ja
> {code}
> * Stop and Restart the repository
> ** The repository will fail to start with the following exception
> {code}
> [org.apache.jackrabbit.oak.api.jmx.RepositoryManagementMBean]] ServiceEvent
> REGISTERED
> 05.11.2015 16:48:28.238 *ERROR* [FelixStartLevel]
> com.adobe.granite.repository.impl.SlingRepositoryManager start: Uncaught
> Throwable trying to access Repository, calling stopRepository()
> java.lang.IllegalMonitorStateException: attempt to unlock read lock, not
> locked by current thread
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:444)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:428)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1341)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:881)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3678) Use stable reverse revision comparator in UpdateUtils.applyChanges()
Marcel Reutegger created OAK-3678: - Summary: Use stable reverse revision comparator in UpdateUtils.applyChanges() Key: OAK-3678 URL: https://issues.apache.org/jira/browse/OAK-3678 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk, mongomk, rdbmk Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.3.12 The method currently takes a comparator parameter, but the DocumentNodeStore requires that a revision map is always sorted reverse. To avoid incorrect usage of the method, the comparator parameter should be removed and the implementation always uses the stable reverse revision comparator for a new TreeMap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3372) Collapsing external events in BackgroundObserver even before queue is full leads to JournalEntry not getting used
[
https://issues.apache.org/jira/browse/OAK-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3372:
---
Labels: candidate_oak_1_0 candidate_oak_1_2 resilience (was: resilience)
> Collapsing external events in BackgroundObserver even before queue is full
> leads to JournalEntry not getting used
> -
>
> Key: OAK-3372
> URL: https://issues.apache.org/jira/browse/OAK-3372
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3.5
>Reporter: Vikas Saurabh
>Assignee: Michael Dürig
> Labels: candidate_oak_1_0, candidate_oak_1_2, resilience
> Fix For: 1.3.10
>
> Attachments: OAK-3372.patch
>
>
> BackgroundObserver currently merges external events if the last one in queue
> is also an external event. This leads to diff being done for a revision pair
> which is different from the ones pushed actively into cache during backgroud
> read (using JournalEntry) i.e. diff queries for {{diff("/a/b", rA, rC)}}
> while background read had pushed results of {{diff("/a/b", rA, rB)}} and
> {{diff("/a/b", rB, rC)}}.
> (cc [~mreutegg], [~egli], [~chetanm], [~mduerig])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3611) upgrade H2DB dependency to 1.4.190
[ https://issues.apache.org/jira/browse/OAK-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026758#comment-15026758 ] Thomas Mueller commented on OAK-3611: - http://svn.apache.org/r1716391 (trunk) > upgrade H2DB dependency to 1.4.190 > -- > > Key: OAK-3611 > URL: https://issues.apache.org/jira/browse/OAK-3611 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > > (we are currently at 1.4.185) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3611) upgrade H2DB dependency to 1.4.190
[ https://issues.apache.org/jira/browse/OAK-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-3611. - Resolution: Fixed > upgrade H2DB dependency to 1.4.190 > -- > > Key: OAK-3611 > URL: https://issues.apache.org/jira/browse/OAK-3611 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > > (we are currently at 1.4.185) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3646) Inconsistent read of hierarchy
[ https://issues.apache.org/jira/browse/OAK-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15026806#comment-15026806 ] Marcel Reutegger commented on OAK-3646: --- I started to work on a fix that gets rid of the current RevisionComparator. Its use is the primary source of trouble because it does not provide a stable comparison of revisions across cluster nodes. Ordering of revisions with different clusterIds may change when one of the revision timestamps becomes older than one hour. As a replacement for the RevisionComparator I'd like to introduce a RevisionVector. This is a replacement for Revision whenever the DocumentNodeStore reads a node state at a given 'revision'. Instead of relying on additional information from the RevisionComparator, the RevisionVector already contains the information about what Revisions from other cluster nodes are visible at that time (local revision). E.g. given a RevisionVector \[r7-0-1, r4-0-2] for the root node state on cluster node 1, this means this cluster nodes sees changes up to r4-0-2 from cluster node 2. Traversing down the tree will update the read revision vector according to _lastRev entries and explicit modifications on the document. Calculating a node state at some read revision vector does not need additional information to decide if a change is visible or not. It simply compares the revision with the revision vector to decide if the revision is visible or not. > Inconsistent read of hierarchy > --- > > Key: OAK-3646 > URL: https://issues.apache.org/jira/browse/OAK-3646 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is similar to OAK-3388, but about hierarchy information like which child > nodes exist at a given revision of the parent node. This issue only occurs in > a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3678) Use stable reverse revision comparator in UpdateUtils.applyChanges()
[ https://issues.apache.org/jira/browse/OAK-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3678. --- Resolution: Fixed Done in trunk: http://svn.apache.org/r1716426 > Use stable reverse revision comparator in UpdateUtils.applyChanges() > > > Key: OAK-3678 > URL: https://issues.apache.org/jira/browse/OAK-3678 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk, rdbmk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.3.12 > > > The method currently takes a comparator parameter, but the DocumentNodeStore > requires that a revision map is always sorted reverse. To avoid incorrect > usage of the method, the comparator parameter should be removed and the > implementation always uses the stable reverse revision comparator for a new > TreeMap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
