[jira] [Commented] (OAK-2019) Compact only if needed
[ https://issues.apache.org/jira/browse/OAK-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092522#comment-14092522 ] Konrad Windszus commented on OAK-2019: -- So if compaction creates a new Tar containing only non-garbage that leaves the old Tar in a state, where nothing is referenced in it. So IMHO cleanup should be able to remove that old Tar completely (because at that state it only contains garbage). Why is that not the case? Compact only if needed -- Key: OAK-2019 URL: https://issues.apache.org/jira/browse/OAK-2019 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: compact-if-needed.patch Add a verification before the TarMK compaction runs to see if there's at least one tar file that needs cleanup. Otherwise skip compaction entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-2020) NodeState view at given version is not stable with DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092529#comment-14092529 ] Thomas Mueller commented on OAK-2020: - DocumentNodeStore should provide same NodeState for given (path, revision) whenever a NodeState is obtained from it. Does it need to be the same object, or would it be enough if it's a different object, but the same hash code, and NodeState.equals(..) would return true? NodeState view at given version is not stable with DocumentNodeStore Key: OAK-2020 URL: https://issues.apache.org/jira/browse/OAK-2020 Project: Jackrabbit Oak Issue Type: Bug Components: mongomk Reporter: Chetan Mehrotra Fix For: 1.1 DocumentNodeStore should provide same NodeState for given (path, revision) whenever a NodeState is obtained from it. This fails in some cases if the Node cache in DocumentNodeStore gets overflown and then the NodeState returned differs. This causes issues like # Spurious Commits see - Some commit would fails with conflicts in paths which were not modified in that commit # Diff logic would traverse those paths which are not related to changes done in that commit More details would be provided in comments below -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-2020) NodeState view at given version is not stable with DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092533#comment-14092533
]
Chetan Mehrotra commented on OAK-2020:
--
Does it need to be the same object, or would it be enough if it's a different
object, but the same hash code, and NodeState.equals(..) would return true?
Need not be same Java reference. Key thing required is that they should have
same lastRevision as the DocumentNodeState equals relies on that and whats
being observed here is that lastRevision changes when same Node at same version
is fetched at later point in time
{code:java}
public boolean equals(Object that) {
if (this == that) {
return true;
} else if (that instanceof DocumentNodeState) {
DocumentNodeState other = (DocumentNodeState) that;
if (getPath().equals(other.getPath())) {
return lastRevision.equals(other.lastRevision);
}
} ...
}
{code}
NodeState view at given version is not stable with DocumentNodeStore
Key: OAK-2020
URL: https://issues.apache.org/jira/browse/OAK-2020
Project: Jackrabbit Oak
Issue Type: Bug
Components: mongomk
Reporter: Chetan Mehrotra
Fix For: 1.1
DocumentNodeStore should provide same NodeState for given (path, revision)
whenever a NodeState is obtained from it. This fails in some cases if the
Node cache in DocumentNodeStore gets overflown and then the NodeState
returned differs. This causes issues like
# Spurious Commits see - Some commit would fails with conflicts in paths
which were not modified in that commit
# Diff logic would traverse those paths which are not related to changes done
in that commit
More details would be provided in comments below
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-2019) Compact only if needed
[ https://issues.apache.org/jira/browse/OAK-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092543#comment-14092543 ] Jukka Zitting commented on OAK-2019: The garbage identified by this patch can be reclaimed by a normal cleanup even without compaction, so as such the check isn't too useful (you could just run cleanup instead). Compact only if needed -- Key: OAK-2019 URL: https://issues.apache.org/jira/browse/OAK-2019 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: compact-if-needed.patch Add a verification before the TarMK compaction runs to see if there's at least one tar file that needs cleanup. Otherwise skip compaction entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-2019) Compact only if needed
[ https://issues.apache.org/jira/browse/OAK-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092569#comment-14092569 ] Konrad Windszus commented on OAK-2019: -- Currently the only way to trigger compaction during running Oak (and also the cleanup afterwards I guess) is through the revisionGarbageCollection. Can you extend the information at http://jackrabbit.apache.org/oak/docs/nodestore/segmentmk.html#Segment_Compaction to explain the two different phases (compaction and cleanup)? Compact only if needed -- Key: OAK-2019 URL: https://issues.apache.org/jira/browse/OAK-2019 Project: Jackrabbit Oak Issue Type: Improvement Components: segmentmk Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: compact-if-needed.patch Add a verification before the TarMK compaction runs to see if there's at least one tar file that needs cleanup. Otherwise skip compaction entirely. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (OAK-2018) Query: before throwing traversed more than x nodes exception, log it
[ https://issues.apache.org/jira/browse/OAK-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved OAK-2018. - Resolution: Fixed Fix Version/s: 1.1 Revision 1616237 (trunk) Revision 1617227 (1.0 branch) Query: before throwing traversed more than x nodes exception, log it --- Key: OAK-2018 URL: https://issues.apache.org/jira/browse/OAK-2018 Project: Jackrabbit Oak Issue Type: Improvement Components: query Affects Versions: 1.0 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.1, 1.0.5 The FilterIterators class can throw an exception if a query traversed more than a number of items (configurable). This should be logged, for cases where the client silently ignores this exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OAK-2022) XPath queries with order by are never converted to union
[ https://issues.apache.org/jira/browse/OAK-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2022: Affects Version/s: 1.0 XPath queries with order by are never converted to union Key: OAK-2022 URL: https://issues.apache.org/jira/browse/OAK-2022 Project: Jackrabbit Oak Issue Type: Bug Components: query Affects Versions: 1.0 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.0.5 XPath queries with or conditions are usually converted to union, however this is not done if there is an order by clause. Union queries do support order by, so I don't currently see a reason for this restriction any more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-2022) XPath queries with order by are never converted to union
Thomas Mueller created OAK-2022: --- Summary: XPath queries with order by are never converted to union Key: OAK-2022 URL: https://issues.apache.org/jira/browse/OAK-2022 Project: Jackrabbit Oak Issue Type: Bug Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.0.5 XPath queries with or conditions are usually converted to union, however this is not done if there is an order by clause. Union queries do support order by, so I don't currently see a reason for this restriction any more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (OAK-2022) XPath queries with order by are never converted to union
[ https://issues.apache.org/jira/browse/OAK-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-2022: Component/s: query XPath queries with order by are never converted to union Key: OAK-2022 URL: https://issues.apache.org/jira/browse/OAK-2022 Project: Jackrabbit Oak Issue Type: Bug Components: query Affects Versions: 1.0 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.0.5 XPath queries with or conditions are usually converted to union, however this is not done if there is an order by clause. Union queries do support order by, so I don't currently see a reason for this restriction any more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1368) Only one Observer per session
[
https://issues.apache.org/jira/browse/OAK-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092732#comment-14092732
]
Michael Dürig commented on OAK-1368:
I implemented a
[draft|https://github.com/mduerig/jackrabbit-oak/commits/OAK-1368] of the
approach outlined in the 4th bullet point above in my private GitHub fork. As
this is a big change I structured it into a couple of commits to make it easier
to follow:
* [Piggy back diffing |
https://github.com/mduerig/jackrabbit-oak/commit/31981e991ccf815a532d91c7b72c386819a118b1#diff-d41d8cd98f00b204e9800998ecf8427e]:
Each session only has a single observer doing a single diff per committed
revision. One of the registered listeners will receive the events immediately
while the others piggy back on the diff, keep all their events in a queue and
dispatch them one by one on the same thread. A challenge with this approach is
registering new listeners: as there is only one diff operation off a shared
revision queue the queue might still hold revisions from the past for what the
new listener is concerned. I added a [callback mechanism |
https://github.com/mduerig/jackrabbit-oak/blob/31981e991ccf815a532d91c7b72c386819a118b1/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/commit/BackgroundObserver.java#L194]
to the background observer to defer the actual registration of the listener
until the revision queue is at the right revision.
* [Fixed limit on event queues |
https://github.com/mduerig/jackrabbit-oak/commit/f6e8d721a6230fb399cba94cc347620a498a4787#diff-d41d8cd98f00b204e9800998ecf8427e]:
Event queues of piggy back listeners overflow after a fixed number of events.
Listeners for which this happens will simply be tried again in a [divide and
conquer |
https://github.com/mduerig/jackrabbit-oak/blob/f6e8d721a6230fb399cba94cc347620a498a4787/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/observation/ChangeProcessor.java#L330]
mode.
* [Sub tree optimisation |
https://github.com/mduerig/jackrabbit-oak/commit/3244002134ec851b70758748caa06d23f8f0f76f#diff-d41d8cd98f00b204e9800998ecf8427e]:
Diff as few sub trees as possible by looking into the path constraints of all
the filters of all the listeners.
* [Memory sensitive event queue |
https://github.com/mduerig/jackrabbit-oak/commit/0a2f187aacce3b365124c84a644389717764efb8#diff-d41d8cd98f00b204e9800998ecf8427e]:
Instead of having the event queues overflow after a fixed number of events,
make them overflow once heap becomes scarce. This will result in a runtime
trade off of memory vs. CPU: fall back to diffing if there is not enough memory
to hold all the events.
Only one Observer per session
-
Key: OAK-1368
URL: https://issues.apache.org/jira/browse/OAK-1368
Project: Jackrabbit Oak
Issue Type: Improvement
Components: jcr
Reporter: Jukka Zitting
Assignee: Michael Dürig
Labels: observation
Fix For: 1.1, 1.0.5
As mentioned in OAK-1332, a case where a single session registers multiple
observation listeners can be troublesome if events are delivered concurrently
to all of those listeners, since in such a case the {{NamePathMapper}} and
other session internals will likely suffer from lock contention.
A good way to avoid this would be to have all the listeners registered within
a single session be tied to a single {{Observer}} and thus processed
sequentially.
Doing so would also improve performance as the listeners could leverage the
same content diff. As the listeners come from a single session and thus
presumably from a single client, there's no need to worry about one client
blocking the work of another.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (OAK-1763) OrderedIndex does not comply with JCR's compareTo semantics
[ https://issues.apache.org/jira/browse/OAK-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092733#comment-14092733 ] Davide Giannella commented on OAK-1763: --- As said in [oak-dev|http://markmail.org/message/k363be3q7bodz6jn] even the date encoding is affected even if marginally as the timezone will rarely change on the server side. Nevertheless a proposed solution for encoding of dates is something like the following https://gist.github.com/davidegiannella/e278a8178f151bef1150 OrderedIndex does not comply with JCR's compareTo semantics --- Key: OAK-1763 URL: https://issues.apache.org/jira/browse/OAK-1763 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Michael Dürig The ordered index currently uses the lexicographical order of the string representation of the values. This does not comply with [JCR's compareTo sementics | http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.5.1%20CompareTo%20Semantics] for e.g. double values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (OAK-1763) OrderedIndex does not comply with JCR's compareTo semantics
[ https://issues.apache.org/jira/browse/OAK-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092733#comment-14092733 ] Davide Giannella edited comment on OAK-1763 at 8/11/14 12:50 PM: - As said in [oak-dev|http://markmail.org/message/k363be3q7bodz6jn] even the date encoding is affected even if marginally as the timezone will rarely change on the server side. Nevertheless a proposed solution for encoding of dates is something like the following https://gist.github.com/davidegiannella/e278a8178f151bef1150 *edit*. As the encoding applies to longs it could be reused for numbers as well. was (Author: edivad): As said in [oak-dev|http://markmail.org/message/k363be3q7bodz6jn] even the date encoding is affected even if marginally as the timezone will rarely change on the server side. Nevertheless a proposed solution for encoding of dates is something like the following https://gist.github.com/davidegiannella/e278a8178f151bef1150 OrderedIndex does not comply with JCR's compareTo semantics --- Key: OAK-1763 URL: https://issues.apache.org/jira/browse/OAK-1763 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Michael Dürig The ordered index currently uses the lexicographical order of the string representation of the values. This does not comply with [JCR's compareTo sementics | http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.5.1%20CompareTo%20Semantics] for e.g. double values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-2022) XPath queries with order by are never converted to union
[ https://issues.apache.org/jira/browse/OAK-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092740#comment-14092740 ] Thomas Mueller commented on OAK-2022: - The problem with _always_ converting to union is that an ordered index can't be used. However, for the queries I have seen so far, it's better to use union and then to sort in memory. The best solution would be to estimate the cost of both case: * union and sort in memory, and * no union but use the ordered index and then to pick the solution with the lower estimated cost. However, this is quite tricky. I will create a new issue for this. XPath queries with order by are never converted to union Key: OAK-2022 URL: https://issues.apache.org/jira/browse/OAK-2022 Project: Jackrabbit Oak Issue Type: Bug Components: query Affects Versions: 1.0 Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.0.5 XPath queries with or conditions are usually converted to union, however this is not done if there is an order by clause. Union queries do support order by, so I don't currently see a reason for this restriction any more. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (OAK-2023) Optimal index usage for XPath queries with order by combined with or
Thomas Mueller created OAK-2023: --- Summary: Optimal index usage for XPath queries with order by combined with or Key: OAK-2023 URL: https://issues.apache.org/jira/browse/OAK-2023 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Thomas Mueller Assignee: Thomas Mueller Fix For: 1.1 XPath queries with or are converted to union, even if there is an order by clause. In such cases, sorting is done in memory. See also OAK-2022. For some queries, it might be better to not use union, but use an ordered index instead. This is tricky to decide up-front, but it would be possible to estimate the cost of both variants and pick the one that seems better. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (OAK-1763) OrderedIndex does not comply with JCR's compareTo semantics
[
https://issues.apache.org/jira/browse/OAK-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092742#comment-14092742
]
Michael Dürig commented on OAK-1763:
bq. the timezone will rarely change on the server side.
This doesn't depend on the server's time zone but on the one specified by the
client:
{code}
setProperty(foo, 2014-04-22T10:11:24.002+01:00, PropertyType.DATE)
{code}
Will save the date property as string with the value
{{2014-04-22T10:11:24.002+01:00}}.
See also OAK- for a related discussion.
OrderedIndex does not comply with JCR's compareTo semantics
---
Key: OAK-1763
URL: https://issues.apache.org/jira/browse/OAK-1763
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Michael Dürig
The ordered index currently uses the lexicographical order of the string
representation of the values. This does not comply with [JCR's compareTo
sementics |
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.5.1%20CompareTo%20Semantics]
for e.g. double values.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (OAK-2024) Error when accessing /oak:index/rep:policy/reindex property via JCR
Tobias Bocanegra created OAK-2024:
-
Summary: Error when accessing /oak:index/rep:policy/reindex
property via JCR
Key: OAK-2024
URL: https://issues.apache.org/jira/browse/OAK-2024
Project: Jackrabbit Oak
Issue Type: Bug
Components: security
Affects Versions: 1.1
Reporter: Tobias Bocanegra
{noformat}
javax.jcr.nodetype.ConstraintViolationException: No matching property
definition found for 'reindex'
at
org.apache.jackrabbit.oak.plugins.nodetype.EffectiveNodeType.getPropertyDefinition(EffectiveNodeType.java:361)
at
org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.getDefinition(ReadOnlyNodeTypeManager.java:380)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl$9.perform(PropertyImpl.java:397)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl$9.perform(PropertyImpl.java:394)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:237)
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:113)
at
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getDefinition(PropertyImpl.java:394)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (OAK-2025) Make the cache size in MongoBlobStore configurable
Chetan Mehrotra created OAK-2025: Summary: Make the cache size in MongoBlobStore configurable Key: OAK-2025 URL: https://issues.apache.org/jira/browse/OAK-2025 Project: Jackrabbit Oak Issue Type: Improvement Components: mongomk Affects Versions: 1.0.5 Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Currently MongoBlobStore which extends the CachingBlobStore uses a fixed cache size of 16 MB. For deployment where more RAM is available and blob storage is frequently accessed i.e. that would be the case when Lucene index is large it make sense to make use of greater cache size -- This message was sent by Atlassian JIRA (v6.2#6252)
