[jira] [Commented] (OAK-5469) TarMK: scaling the content
[
https://issues.apache.org/jira/browse/OAK-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953737#comment-15953737
]
Michael Dürig commented on OAK-5469:
Maybe realted / interesting here: [shared memory and gc
pauses|http://www.evanjones.ca/jvm-mmap-pause.html].
> TarMK: scaling the content
> --
>
> Key: OAK-5469
> URL: https://issues.apache.org/jira/browse/OAK-5469
> Project: Jackrabbit Oak
> Issue Type: Epic
> Components: segment-tar
>Reporter: Michael Dürig
> Labels: scalability
> Fix For: 1.8
>
> Attachments: segment-per-path.png
>
>
> Production experience has shown that big repositories are prone to thrashing:
> {quote}
> Monitoring showed as massive level of major page faults, load averages
> several times the number of cores, system cpu levels well above 50% and
> extreme levels of IO. As more IOPS was provisioned the instance consumed all
> available IOPS. The TechOps team reported many TB of read IO per hour and
> hardly any write IO.
> Investigation revealed that the repository size was just larger than the
> available RAM on the machine. The instance was running in MMAPED mode and the
> IO was due to major page faults mapping in and out pages of memory. This was
> made worse by transparent huge page settings causing huge pages to be mapped
> proactively on major page faults. Compaction reduced the repository size to
> less than RAM. The TechOps team now monitor the total tar file size and dont
> let it exceed the RAM on the machine, scheduling compactions to keep within
> limits. Since the default to TarMK was to run memory mapped rather than on
> heap, the JVM had no visibility of the mayhem being caused at OS level.
> {quote}
> This epic is all about improving scalability of the TarMK wrt. the content.
> Below are some initial points to consider. Let's create issues and link them
> to this epic as we go.
> * What kind of internal / external monitoring do we need to understand and
> optimally predict thrashing? Can we monitor the working set (active pages)?
> The number of segments in the segment cache might be a good starting point.
> * (How) can we reproduce the thrashing (easily enough)? Can we scale it down
> (i.e. to an instance with littler RAM)?
> * What is the impact of transparent huge pages (and switching it off)? How
> much do we suffer from read amplification? What would be the impact of not
> memory mapping but instead increasing the size of the segment buffer
> accordingly? Both approaches aim at having finer grained control over the
> data actually being loaded into RAM.
> * What other OS level tweaks should / can we look at?
> * Can we reduce the working set by keeping it more compact? E.g. running
> GC/compaction, reducing read amplification (see above), improving
> de-duplication of values, storing values more efficiently (e.g. dates, and
> boolean), can we on the fly compress buffers (e.g. segments)?
> * How do we testing with big repositories?
> * What is a big repository? (Potential target: 100 GB segment store - 500M
> nodes, TBC)
> * What to measure (indicators of size): size on disk (after compaction),
> number of JCR nodes, number of node records (reachable vs. waste)
> * How to measure?
> * {{oak-run debug}} (needs improvements for better scalability)
> * one-line tool to provide all the info?
> * How to obtain big repositories (generate or re-use existing)?
> * What to analyze / monitor / debug?
> * Possible limits: number of nodes (relative to RAM) for which trashing
> starts to occur, max. number of direct children, max. concurrent requests
> during online garbage collection.
> * Platform monitoring:
> * basic: disc size, IO, CPU, memory
> * Asses impact of hardware upgrades on performance. E.g. what impact
> does doubling RAM/IO/CPU have on our test scenarios.
> * in depth: page faults, writes / reads per process, working set of
> nodes, commit statistics, incoming requests vs Oak operations, other hiccups
> * Tools: [Ganglia|http://ganglia.info/],
> [jHiccups|https://github.com/giltene/jHiccup],
> [AppDynamics|https://www.appdynamics.com/]
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-3459) Scalability/Longevity test for number of properties
[ https://issues.apache.org/jira/browse/OAK-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-3459: Component/s: (was: bench) benchmarks > Scalability/Longevity test for number of properties > --- > > Key: OAK-3459 > URL: https://issues.apache.org/jira/browse/OAK-3459 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: Davide Giannella >Assignee: Davide Giannella >Priority: Minor > > Create a scalability or longevity test that will provide insights on > how Oak performs with the increasing of the number of properties under > one node. > How is insert? How is read? How is update? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-2914) scalabilty benchmark for queries getSize()
[ https://issues.apache.org/jira/browse/OAK-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2914: Component/s: (was: bench) benchmarks > scalabilty benchmark for queries getSize() > -- > > Key: OAK-2914 > URL: https://issues.apache.org/jira/browse/OAK-2914 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks, query >Reporter: Davide Giannella >Assignee: Davide Giannella > > Create a scalability benchmark that will measure the time taken for a > getSize() in these situations > - lucene property index defined > - index serving all conditions of the query > - index serving only part of the conditions of the query -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-2988) Improve ConcurrentReadTest
[ https://issues.apache.org/jira/browse/OAK-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-2988: Component/s: (was: run) (was: bench) benchmarks > Improve ConcurrentReadTest > -- > > Key: OAK-2988 > URL: https://issues.apache.org/jira/browse/OAK-2988 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Affects Versions: 1.0.15, 1.2.2 >Reporter: Philipp Suter >Priority: Minor > Attachments: ConcurrentReadTest.diff > > > Use a more realistic test scenario for oak-run benchmark tests. > ConcurrentReadTest.java currently only creates one root node while in reality > a repository might have multiple root nodes. > Change is attached as diff. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5928) improve benchmarks for removal of group members
[ https://issues.apache.org/jira/browse/OAK-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-5928: Component/s: benchmarks > improve benchmarks for removal of group members > --- > > Key: OAK-5928 > URL: https://issues.apache.org/jira/browse/OAK-5928 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: benchmarks >Reporter: angela >Priority: Minor > > instead of just removing existing members which renders the runTest method a > no-op ones there are no members left, the tests should be adjusted to > removing both existing a non-existing members -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6020:
Attachment: OAK-6020.diff
proposed patch
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6020:
Attachment: (was: OAK-6020.diff)
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6027) UserImporter.Impersonators : use Oak path to user instead of ID
[
https://issues.apache.org/jira/browse/OAK-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6027.
-
Resolution: Fixed
Assignee: angela
Committed revision 1790006.
> UserImporter.Impersonators : use Oak path to user instead of ID
> ---
>
> Key: OAK-6027
> URL: https://issues.apache.org/jira/browse/OAK-6027
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> since the {{UserImporter.Impersonators}} is built on a specific
> implementation of the user management API it would be possible to use the
> path of the tree to lookup the user upon post-processing of the
> impersonators. this would simplify the resolution of the user upon
> {{ProtectedPropertyImporter.processReferences}}.
> found while working OAK-5882
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953598#comment-15953598
]
Julian Reschke commented on OAK-6020:
-
re a) - the same is true for the implementations this is supposed to replace
:-) -- but it seems to be better to use Locale.ENGLISH, right?
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953585#comment-15953585
]
Julian Reschke commented on OAK-6020:
-
a) Indeed.
b) Oops. I'll claim that I would have noticed when checking in.
Stay tuned.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953576#comment-15953576
]
Marcel Reutegger commented on OAK-6020:
---
Hmm, related to Vikas comment, wouldn't it be better to use a predefined
Locale? The current patch uses the default Locale, which is platform specific.
This means the test may fail if the default locale does not use the comma
character as a separator but something else.
The test is also in the default package. Sorry, didn't notice when I looked at
the patch the first time...
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6027) UserImporter.Impersonators : use Oak path to user instead of ID
angela created OAK-6027:
---
Summary: UserImporter.Impersonators : use Oak path to user instead
of ID
Key: OAK-6027
URL: https://issues.apache.org/jira/browse/OAK-6027
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core
Reporter: angela
Priority: Minor
Fix For: 1.7.0, 1.8
since the {{UserImporter.Impersonators}} is built on a specific implementation
of the user management API it would be possible to use the path of the tree to
lookup the user upon post-processing of the impersonators. this would simplify
the resolution of the user upon {{ProtectedPropertyImporter.processReferences}}.
found while working OAK-5882
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6026) spi.xml.PropInfo: missing error msg in case of multivalue mismatch
[ https://issues.apache.org/jira/browse/OAK-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6026. - Resolution: Fixed Assignee: angela Committed revision 1790004. > spi.xml.PropInfo: missing error msg in case of multivalue mismatch > -- > > Key: OAK-6026 > URL: https://issues.apache.org/jira/browse/OAK-6026 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela > Fix For: 1.7.0, 1.8 > > > spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6024) Use of DocumentMKBuilderProvider with virtual clock is fragile
[
https://issues.apache.org/jira/browse/OAK-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6024.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Fixed in trunk: http://svn.apache.org/r1790001
> Use of DocumentMKBuilderProvider with virtual clock is fragile
> --
>
> Key: OAK-6024
> URL: https://issues.apache.org/jira/browse/OAK-6024
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> Using a DocumentMKBuilderProvider rule in a test with a virtual clock is
> fragile, because many tests reset the clock in Revision and ClusterNodeInfo
> in a {{@After}} method. This may cause problems because the {{@After}} method
> is called before the builder provider's {{after()}} method. Between those two
> calls a DocumentNodeStore instance may be running with a reset clock, while
> it was initialied with a virtual clock.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953539#comment-15953539
]
Vikas Saurabh commented on OAK-6020:
well, usually the 3 magnitudes of change in the quantity being analyzed is
uncommon... but in any case, 'sort' it seems is smarter that I took it to be.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6026) spi.xml.PropInfo: missing error msg in case of multivalue mismatch
angela created OAK-6026: --- Summary: spi.xml.PropInfo: missing error msg in case of multivalue mismatch Key: OAK-6026 URL: https://issues.apache.org/jira/browse/OAK-6026 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Fix For: 1.7.0, 1.8 spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953537#comment-15953537
]
Julian Reschke commented on OAK-6020:
-
Sorting is already victim of different units/scales, no?
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953518#comment-15953518
]
Vikas Saurabh edited comment on OAK-6020 at 4/3/17 2:00 PM:
A minor point wrt to what I see in tests - the tests suggest comma at
thousands. I'm not completely sure of all the use-case, -but I think that would
screw up simple sorting using {{sort -nk}} pattern (there could be a flag in
sort that I'm missing though)-.
Ignore that as it seems sort is smart:
{noformat}$ sort -nk1 < 1
> 1,000
> 10
> 10,000
> EOF
1
10
1,000
10,000
{noformat}
was (Author: catholicon):
A minor point wrt to what I see in tests - the tests suggest comma at
thousands. I'm not completely sure of all the use-case, but I think that would
screw up simple sorting using {{sort -nk}} pattern (there could be a flag in
sort that I'm missing though).
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953518#comment-15953518
]
Vikas Saurabh commented on OAK-6020:
A minor point wrt to what I see in tests - the tests suggest comma at
thousands. I'm not completely sure of all the use-case, but I think that would
screw up simple sorting using {{sort -nk}} pattern (there could be a flag in
sort that I'm missing though).
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (OAK-6025) Remove --[src-]s3datastore parameter from oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek reassigned OAK-6025:
--
Assignee: Tomek Rękawek
> Remove --[src-]s3datastore parameter from oak-upgrade
> -
>
> Key: OAK-6025
> URL: https://issues.apache.org/jira/browse/OAK-6025
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: upgrade
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
> Fix For: 1.8
>
>
> It seems that the {{\-\-\[src\-\]s3datastore}} can be replaced with the
> {{path}} property specified in the s3 configuration file (passes as
> --s3config). We should remove the {{\-\-\[src\-\]s3datastore}} parameters to
> avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6025) Remove --[src-]s3datastore parameter from oak-upgrade
Tomek Rękawek created OAK-6025:
--
Summary: Remove --[src-]s3datastore parameter from oak-upgrade
Key: OAK-6025
URL: https://issues.apache.org/jira/browse/OAK-6025
Project: Jackrabbit Oak
Issue Type: Improvement
Components: upgrade
Reporter: Tomek Rękawek
Fix For: 1.8
It seems that the {{\-\-\[src\-\]s3datastore}} can be replaced with the
{{path}} property specified in the s3 configuration file (passes as
--s3config). We should remove the {{\-\-\[src\-\]s3datastore}} parameters to
avoid confusion.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6024) Use of DocumentMKBuilderProvider with virtual clock is fragile
Marcel Reutegger created OAK-6024:
-
Summary: Use of DocumentMKBuilderProvider with virtual clock is
fragile
Key: OAK-6024
URL: https://issues.apache.org/jira/browse/OAK-6024
Project: Jackrabbit Oak
Issue Type: Test
Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
Fix For: 1.8
Using a DocumentMKBuilderProvider rule in a test with a virtual clock is
fragile, because many tests reset the clock in Revision and ClusterNodeInfo in
a {{@After}} method. This may cause problems because the {{@After}} method is
called before the builder provider's {{after()}} method. Between those two
calls a DocumentNodeStore instance may be running with a reset clock, while it
was initialied with a virtual clock.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953471#comment-15953471
]
Marcel Reutegger commented on OAK-6020:
---
+1 looks good to me.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6023) UserImporter: handlePropInfo for rep:authorizableId never returns true
[
https://issues.apache.org/jira/browse/OAK-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6023.
-
Resolution: Fixed
Committed revision 1789987.
> UserImporter: handlePropInfo for rep:authorizableId never returns true
> --
>
> Key: OAK-6023
> URL: https://issues.apache.org/jira/browse/OAK-6023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.7.0, 1.8
>
>
> in contrast to other user/group properties such as {{rep:principalName}} the
> method {{UserImporter.handlePropInfo}} never returns true when dealing with
> {{rep:authorizableId}} even if the {{PropInfo}} was successfully processed.
> Spotted while working on OAK-5882
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6020:
Attachment: OAK-6020.diff
Proposal.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
> Attachments: OAK-6020.diff
>
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (OAK-6023) UserImporter: handlePropInfo for rep:authorizableId never returns true
[
https://issues.apache.org/jira/browse/OAK-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela reassigned OAK-6023:
---
Assignee: angela
> UserImporter: handlePropInfo for rep:authorizableId never returns true
> --
>
> Key: OAK-6023
> URL: https://issues.apache.org/jira/browse/OAK-6023
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
> Fix For: 1.7.0, 1.8
>
>
> in contrast to other user/group properties such as {{rep:principalName}} the
> method {{UserImporter.handlePropInfo}} never returns true when dealing with
> {{rep:authorizableId}} even if the {{PropInfo}} was successfully processed.
> Spotted while working on OAK-5882
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6023) UserImporter: handlePropInfo for rep:authorizableId never returns true
angela created OAK-6023:
---
Summary: UserImporter: handlePropInfo for rep:authorizableId never
returns true
Key: OAK-6023
URL: https://issues.apache.org/jira/browse/OAK-6023
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Fix For: 1.7.0, 1.8
in contrast to other user/group properties such as {{rep:principalName}} the
method {{UserImporter.handlePropInfo}} never returns true when dealing with
{{rep:authorizableId}} even if the {{PropInfo}} was successfully processed.
Spotted while working on OAK-5882
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6022) ReadPreferenceIT uses incorrect clock
[ https://issues.apache.org/jira/browse/OAK-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-6022. --- Resolution: Fixed Fix Version/s: 1.7.0 Fixed in trunk: http://svn.apache.org/r1789978 > ReadPreferenceIT uses incorrect clock > - > > Key: OAK-6022 > URL: https://issues.apache.org/jira/browse/OAK-6022 > Project: Jackrabbit Oak > Issue Type: Test > Components: documentmk >Affects Versions: 1.6.0 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Minor > Fix For: 1.7.0, 1.8 > > > The test uses a virtual clock, but does not initialize the DocumentNodeStore > with the test clock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6022) ReadPreferenceIT uses incorrect clock
Marcel Reutegger created OAK-6022: - Summary: ReadPreferenceIT uses incorrect clock Key: OAK-6022 URL: https://issues.apache.org/jira/browse/OAK-6022 Project: Jackrabbit Oak Issue Type: Test Components: documentmk Affects Versions: 1.6.0 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Priority: Minor Fix For: 1.8 The test uses a virtual clock, but does not initialize the DocumentNodeStore with the test clock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6016) DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
[
https://issues.apache.org/jira/browse/OAK-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6016.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Fixed in trunk: http://svn.apache.org/r1789975
> DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
> --
>
> Key: OAK-6016
> URL: https://issues.apache.org/jira/browse/OAK-6016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: candidate_oak_1_6
> Fix For: 1.7.0, 1.8
>
>
> Comparing node states in read-only mode may fail with an
> IllegalStateException when the journal is used to perform a diff.
> {noformat}
> java.lang.IllegalStateException: Root document does not have a lastRev entry
> for local clusterId 0
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
> at
> org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
> [...]
> Caused by: java.lang.IllegalStateException: Root document does not have a
> lastRev entry for local clusterId 0
> at
> org.apache.jackrabbit.oak.plugins.document.JournalDiffLoader.call(JournalDiffLoader.java:82)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.diffImpl(DocumentNodeStore.java:2428)
> {noformat}
> See also OAK-6011.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953325#comment-15953325
]
Julian Reschke commented on OAK-6020:
-
a) right.
b) that is an issue indeed.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953311#comment-15953311
]
Marcel Reutegger commented on OAK-6020:
---
I would rather avoid such characters.
Btw, this code doesn't just look like the Guava Stopwatch, but in my view is a
copy of the Guava code. If that's the case, then we have to retain the
copyright that's present in the header of the Guava source. At least that's my
interpretation of the Apache License v2 / 4c.
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6020:
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4
candidate_oak_1_6 (was: )
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4,
> candidate_oak_1_6
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6021) Remove segment graph functionality from oak-run
Michael Dürig created OAK-6021: -- Summary: Remove segment graph functionality from oak-run Key: OAK-6021 URL: https://issues.apache.org/jira/browse/OAK-6021 Project: Jackrabbit Oak Issue Type: Improvement Components: run, segment-tar Reporter: Michael Dürig Fix For: 1.8 We could probably remove the segment graph functionality from oak-run. This has been implemented mainly (and solely?) for the purpose of analysing the problems around OAK-3348 and I assume it would quickly start falling behind as we move forward. Also for this kind of analysis I have switched to [oak-script|https://github.com/mduerig/script-oak], which is far more flexible. Let's decide closer to cutting 1.8 how to go forward here. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5566) TestFailure: remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty
[ https://issues.apache.org/jira/browse/OAK-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5566: -- Fix Version/s: (was: 1.4.15) 1.4.16 > TestFailure: > remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty > -- > > Key: OAK-5566 > URL: https://issues.apache.org/jira/browse/OAK-5566 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, remoting >Reporter: Hudson > Labels: test-failure, ubuntu > Fix For: 1.4.16 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting #1396 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting > #1396|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5418) Test failure: TomcatIT.testTomcat()
[ https://issues.apache.org/jira/browse/OAK-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5418: -- Fix Version/s: (was: 1.4.15) 1.4.16 > Test failure: TomcatIT.testTomcat() > --- > > Key: OAK-5418 > URL: https://issues.apache.org/jira/browse/OAK-5418 > Project: Jackrabbit Oak > Issue Type: Test > Components: continuous integration, examples >Affects Versions: 1.4 >Reporter: Hudson >Assignee: Chetan Mehrotra > Labels: test-failure, ubuntu > Fix For: 1.4.16 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=DOCUMENT_NS,profile=unittesting #1357 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_NS,profile=unittesting > #1357|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5509) Backport Lucene index stability improvements to 1.4
[ https://issues.apache.org/jira/browse/OAK-5509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5509: -- Fix Version/s: (was: 1.4.15) 1.4.16 > Backport Lucene index stability improvements to 1.4 > --- > > Key: OAK-5509 > URL: https://issues.apache.org/jira/browse/OAK-5509 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.4.16 > > > In 1.6 (trunk) quite a few improvement were in Lucene indexing to make it > more resilient against corruption (OAK-3269). This task is meant to determine > which all are safe to backport to 1.4 branch -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5470) Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2
[ https://issues.apache.org/jira/browse/OAK-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5470: -- Fix Version/s: (was: 1.4.15) 1.4.16 > Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2 > -- > > Key: OAK-5470 > URL: https://issues.apache.org/jira/browse/OAK-5470 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.2.23, 1.4.13 >Reporter: Hudson > Labels: test-failure, windows > Fix For: 1.2.25, 1.4.16 > > Attachments: sysout-1380.log, unit-tests-build-1371.log, > unit-tests.log > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1371 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1371|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5458) Test failure: RepositoryBootIT.repositoryLogin
[ https://issues.apache.org/jira/browse/OAK-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-5458: -- Fix Version/s: (was: 1.4.15) 1.4.16 > Test failure: RepositoryBootIT.repositoryLogin > -- > > Key: OAK-5458 > URL: https://issues.apache.org/jira/browse/OAK-5458 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, examples >Affects Versions: 1.4, 1.5.18 >Reporter: Hudson >Assignee: Chetan Mehrotra > Labels: test-failure, ubuntu > Fix For: 1.8, 1.6.2, 1.4.16 > > Attachments: unit-tests-1379.log > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting #1369 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1369|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1369/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1369/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6020) add a Guava Stopwatch like duration formatter
[
https://issues.apache.org/jira/browse/OAK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953224#comment-15953224
]
Julian Reschke commented on OAK-6020:
-
Question: the use of non-ASCII characters in logs (for microseconds) has led to
confusion more than once. Should we avoid that here?
> add a Guava Stopwatch like duration formatter
> -
>
> Key: OAK-6020
> URL: https://issues.apache.org/jira/browse/OAK-6020
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: commons
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
>
> The duration formatter in {{com.google.common.base.Stopwatch}} can only be
> sued when we indeed have a {{Stopwatch}} object, which is not always the case.
> {{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
> already.
> Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6020) add a Guava Stopwatch like duration formatter
Julian Reschke created OAK-6020:
---
Summary: add a Guava Stopwatch like duration formatter
Key: OAK-6020
URL: https://issues.apache.org/jira/browse/OAK-6020
Project: Jackrabbit Oak
Issue Type: Improvement
Components: commons
Reporter: Julian Reschke
Assignee: Julian Reschke
Priority: Minor
The duration formatter in {{com.google.common.base.Stopwatch}} can only be sued
when we indeed have a {{Stopwatch}} object, which is not always the case.
{{org.apache.jackrabbit.oak.management.ManagementOperation}} has similar code
already.
Proposal: move that code into a separate generic class.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6019) UserImporter: Redundant assignment of UserManager
[ https://issues.apache.org/jira/browse/OAK-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6019. - Resolution: Fixed Committed revision 1789940. > UserImporter: Redundant assignment of UserManager > - > > Key: OAK-6019 > URL: https://issues.apache.org/jira/browse/OAK-6019 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.7.0, 1.8 > > > spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6019) UserImporter: Redundant assignment of UserManager
angela created OAK-6019: --- Summary: UserImporter: Redundant assignment of UserManager Key: OAK-6019 URL: https://issues.apache.org/jira/browse/OAK-6019 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: angela Assignee: angela Priority: Minor Fix For: 1.7.0, 1.8 spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Piovesana updated OAK-6015:
-
Description:
On a versione node _nodeA_ i can do:
{{AccessControlUtils.clear(nodeA, userPrincipal)}}
without having to checkout the node.
After saving the session I tried to login as _userPrincipal_ and I couldn't
find _nodeA_, so it seems that the clear operation did work even if the node
was checked-in.
was:
On a versione node _nodeA_ i can do:
{{AccessControlUtils.clear(nodeA, userPrincipal)}}
without having to checkout the node.
After saving the session I tried to login as _userPrincipal_ and I couldn't
find _nodeA_, so it seems that the clear operation did work even if the node
was checkedin.
> ACL of versioned node can be modified without checking out the node
> ---
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkout the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checked-in.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6015) ACL of versioned node can be modified without checking in the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953206#comment-15953206
]
Marco Piovesana commented on OAK-6015:
--
Yes I'm sorry, I wrote checkin instead of checkout. I'm updating title and
description right away.
Marco.
> ACL of versioned node can be modified without checking in the node
> --
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkin the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checked-out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Piovesana updated OAK-6015:
-
Description:
On a versione node _nodeA_ i can do:
{{AccessControlUtils.clear(nodeA, userPrincipal)}}
without having to checkout the node.
After saving the session I tried to login as _userPrincipal_ and I couldn't
find _nodeA_, so it seems that the clear operation did work even if the node
was checkedin.
was:
On a versione node _nodeA_ i can do:
{{AccessControlUtils.clear(nodeA, userPrincipal)}}
without having to checkin the node.
After saving the session I tried to login as _userPrincipal_ and I couldn't
find _nodeA_, so it seems that the clear operation did work even if the node
was checked-out.
> ACL of versioned node can be modified without checking out the node
> ---
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkout the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checkedin.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6015) ACL of versioned node can be modified without checking out the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marco Piovesana updated OAK-6015:
-
Summary: ACL of versioned node can be modified without checking out the
node (was: ACL of versioned node can be modified without checking in the node)
> ACL of versioned node can be modified without checking out the node
> ---
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkin the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checked-out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6016) DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
[
https://issues.apache.org/jira/browse/OAK-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953163#comment-15953163
]
Marcel Reutegger commented on OAK-6016:
---
Added an ignored test: http://svn.apache.org/r1789930
> DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
> --
>
> Key: OAK-6016
> URL: https://issues.apache.org/jira/browse/OAK-6016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: candidate_oak_1_6
> Fix For: 1.8
>
>
> Comparing node states in read-only mode may fail with an
> IllegalStateException when the journal is used to perform a diff.
> {noformat}
> java.lang.IllegalStateException: Root document does not have a lastRev entry
> for local clusterId 0
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
> at
> org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
> [...]
> Caused by: java.lang.IllegalStateException: Root document does not have a
> lastRev entry for local clusterId 0
> at
> org.apache.jackrabbit.oak.plugins.document.JournalDiffLoader.call(JournalDiffLoader.java:82)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.diffImpl(DocumentNodeStore.java:2428)
> {noformat}
> See also OAK-6011.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6017) Reset timestamps on Revision.setClock()
[
https://issues.apache.org/jira/browse/OAK-6017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-6017.
---
Resolution: Fixed
Fix Version/s: 1.7.0
Done in trunk: http://svn.apache.org/r1789928
> Reset timestamps on Revision.setClock()
> ---
>
> Key: OAK-6017
> URL: https://issues.apache.org/jira/browse/OAK-6017
> Project: Jackrabbit Oak
> Issue Type: Test
> Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> Revision.setClock() is used for tests only. E.g. when a virtual clock should
> be used in a test. Revision.setClock() only resets the timestamps
> ({{lastTimestamp}} and {{lastRevisionTimestamp}}) only when the clock is
> reset to the default. The method should also reset the timestamps when any
> other clock is set for a test. Otherwise the timestamps may be newer than the
> current time of the clock in use.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6018) UserImporter: session field can avoided by passing to init method
[ https://issues.apache.org/jira/browse/OAK-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved OAK-6018. - Resolution: Fixed Committed revision 1789925. > UserImporter: session field can avoided by passing to init method > - > > Key: OAK-6018 > URL: https://issues.apache.org/jira/browse/OAK-6018 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: angela >Assignee: angela >Priority: Minor > Fix For: 1.7.0, 1.8 > > > spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6018) UserImporter: session field can avoided by passing to init method
angela created OAK-6018: --- Summary: UserImporter: session field can avoided by passing to init method Key: OAK-6018 URL: https://issues.apache.org/jira/browse/OAK-6018 Project: Jackrabbit Oak Issue Type: Improvement Reporter: angela Assignee: angela Priority: Minor Fix For: 1.7.0, 1.8 spotted while working on OAK-5882 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6017) Reset timestamps on Revision.setClock()
Marcel Reutegger created OAK-6017:
-
Summary: Reset timestamps on Revision.setClock()
Key: OAK-6017
URL: https://issues.apache.org/jira/browse/OAK-6017
Project: Jackrabbit Oak
Issue Type: Test
Components: documentmk
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
Fix For: 1.8
Revision.setClock() is used for tests only. E.g. when a virtual clock should be
used in a test. Revision.setClock() only resets the timestamps
({{lastTimestamp}} and {{lastRevisionTimestamp}}) only when the clock is reset
to the default. The method should also reset the timestamps when any other
clock is set for a test. Otherwise the timestamps may be newer than the current
time of the clock in use.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6015) ACL of versioned node can be modified without checking in the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953109#comment-15953109
]
angela commented on OAK-6015:
-
[~iosonomarco], the subject/description is confusing... don't you mean to say
that the node is checked-in and it still works? so, 'without checking _out_ the
node'? if the node is checked out writing is possible in the first place...
it's only the checked-in state that should be read only. please clarify.
> ACL of versioned node can be modified without checking in the node
> --
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkin the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checked-out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6016) DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
[
https://issues.apache.org/jira/browse/OAK-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6016:
--
Description:
Comparing node states in read-only mode may fail with an IllegalStateException
when the journal is used to perform a diff.
{noformat}
java.lang.IllegalStateException: Root document does not have a lastRev entry
for local clusterId 0
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
at
org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
[...]
Caused by: java.lang.IllegalStateException: Root document does not have a
lastRev entry for local clusterId 0
at
org.apache.jackrabbit.oak.plugins.document.JournalDiffLoader.call(JournalDiffLoader.java:82)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.diffImpl(DocumentNodeStore.java:2428)
{noformat}
See also OAK-6011.
was:
Comparing node states in read-only mode may fail with an IllegalStateException
when the journal is used to perform a diff.
{noformat}
java.lang.IllegalStateException: Root document does not have a lastRev entry
for local clusterId 0
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
at
org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
{noformat}
See also OAK-6011.
> DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
> --
>
> Key: OAK-6016
> URL: https://issues.apache.org/jira/browse/OAK-6016
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Affects Versions: 1.6.0
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: candidate_oak_1_6
> Fix For: 1.8
>
>
> Comparing node states in read-only mode may fail with an
> IllegalStateException when the journal is used to perform a diff.
> {noformat}
> java.lang.IllegalStateException: Root document does not have a lastRev entry
> for local clusterId 0
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
> at
> org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
> [...]
> Caused by: java.lang.IllegalStateException: Root document does not have a
> lastRev entry for local clusterId 0
> at
> org.apache.jackrabbit.oak.plugins.document.JournalDiffLoader.call(JournalDiffLoader.java:82)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.diffImpl(DocumentNodeStore.java:2428)
> {noformat}
> See also OAK-6011.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6011) Test failure: JdbcToSegmentTest:validateMigration
[
https://issues.apache.org/jira/browse/OAK-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953106#comment-15953106
]
Marcel Reutegger commented on OAK-6011:
---
Disabling the journal for diff calculation just hides the underlying issue when
the DocumentNodeStore is in read-only mode. I created OAK-6016 to fix the issue
in oak-core.
> Test failure: JdbcToSegmentTest:validateMigration
> --
>
> Key: OAK-6011
> URL: https://issues.apache.org/jira/browse/OAK-6011
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
>Affects Versions: 1.8
>Reporter: Michael Dürig
>Assignee: Tomek Rękawek
> Labels: CI, test-failure
> Fix For: 1.7.0, 1.8
>
>
> {code}
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy
> content
> at com.google.common.io.Closer.rethrow(Closer.java:149)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.migrate(OakUpgrade.java:81)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.migrate(OakUpgrade.java:67)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.main(OakUpgrade.java:48)
> at
> org.apache.jackrabbit.oak.upgrade.cli.AbstractOak2OakTest.prepare(AbstractOak2OakTest.java:112)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
> at
> org.apache.jackrabbit.oak.upgrade.RepositorySidegrade.copy(RepositorySidegrade.java:264)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.sidegrade(OakUpgrade.java:92)
> at
> org.apache.jackrabbit.oak.upgrade.cli.OakUpgrade.migrate(OakUpgrade.java:78)
> ... 34 more
> Caused by: com.google.common.util.concurrent.UncheckedExecutionException:
> java.lang.IllegalStateException: Root document does not have a lastRev entry
> for local clusterId 0
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
> at
> com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
> at
> org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
> at
> org.apache.jackrabbit.oak.plugins.document.AbstractDocumentNodeState.compareAgainstBaseState(AbstractDocumentNodeState.java:114)
> at
> org.apache.jackrabbit.oak.upgrade.RepositorySidegrade.migrateWithCheckpoints(RepositorySidegrade.java:369)
> at
> org.apache.jackrabbit.oak.upgrade.RepositorySidegrade.copyState(RepositorySidegrade.java:294)
> at
> org.apache.jackrabbit.oak.upgrade.RepositorySidegrade.copy(RepositorySidegrade.java:257)
> ... 36 more
> Caused by: java.lang.IllegalStateException: Root document does not have a
> lastRev entry for local clusterId 0
> at
> org.apache.jackrabbit.oak.plugins.document.JournalDiffLoader.call(JournalDiffLoader.java:82)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.diffImpl(DocumentNodeStore.java:2428)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.access$1100(DocumentNodeStore.java:136)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$8.call(DocumentNodeStore.java:1637)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache$1.call(MemoryDiffCache.java:89)
> at
> org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache$1.call(MemoryDiffCache.java:83)
> at
> com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4724)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3522)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2315)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2278)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2193)
> ... 45 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6016) DocumentNodeStore.compare() fails with IllegalStateException in read-only mode
Marcel Reutegger created OAK-6016:
-
Summary: DocumentNodeStore.compare() fails with
IllegalStateException in read-only mode
Key: OAK-6016
URL: https://issues.apache.org/jira/browse/OAK-6016
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Affects Versions: 1.6.0
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Priority: Minor
Fix For: 1.8
Comparing node states in read-only mode may fail with an IllegalStateException
when the journal is used to perform a diff.
{noformat}
java.lang.IllegalStateException: Root document does not have a lastRev entry
for local clusterId 0
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2199)
at com.google.common.cache.LocalCache.get(LocalCache.java:3932)
at
com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4721)
at
org.apache.jackrabbit.oak.plugins.document.MemoryDiffCache.getChanges(MemoryDiffCache.java:83)
at
org.apache.jackrabbit.oak.plugins.document.TieredDiffCache.getChanges(TieredDiffCache.java:50)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.compare(DocumentNodeStore.java:1632)
{noformat}
See also OAK-6011.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6015) ACL of versioned node can be modified without checking in the node
[
https://issues.apache.org/jira/browse/OAK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15953102#comment-15953102
]
Marco Piovesana commented on OAK-6015:
--
Sure, in the test I first grant to "testUser" some privileges and then i try to
clear them without checking out the node:
{code:title=ACLErrorTest.java|borderStyle=solid}
@Test(expected = VersionException.class)
public void shouldFailWhenTryingToChangeNodeSharestOnCheckedOutNode()
throws IOException, RepositoryException, InvalidFileStoreVersionException {
File driveFile = new File("/tmp/oakTest", "oakrepo");
File repositoryFile = new File(driveFile, "repository");
File dataStoreFile = new File(driveFile, "datastore");
BlobStore blobStore = new
FileBlobStore(dataStoreFile.getAbsolutePath());
FileStore fileStore =
FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build();
SegmentNodeStore segmentNodeStore =
SegmentNodeStoreBuilders.builder(fileStore).build();
Jcr jcr = new Jcr(segmentNodeStore).with(new InitialContent()).with(new
SecurityProviderImpl());
Repository repository = jcr.createRepository();
Session session = repository.login(ADMIN_CREDENTIALS);
User user = ((JackrabbitSession)
session).getUserManager().createUser("testUser", "testUser", new
PrincipalImpl("testUser"), null);
session.save();
VersionManager versionManager =
session.getWorkspace().getVersionManager();
Node testFolder = JcrUtils.getOrAddNode(session.getRootNode(),
"myfile", JcrConstants.NT_FOLDER);
testFolder.addMixin(JcrConstants.MIX_VERSIONABLE);
session.save();
versionManager.checkout(testFolder.getPath());
versionManager.checkin(testFolder.getPath());
versionManager.checkout(testFolder.getPath());
AccessControlUtils.addAccessControlEntry(testFolder.getSession(),
testFolder.getPath(), user.getPrincipal(), new String[]{Privilege.JCR_ALL},
true);
session.save();
versionManager.checkin(testFolder.getPath());
AccessControlUtils.clear(testFolder, user.getPrincipal().getName());
session.save();
session.logout();
repositoryStore.close();
((JackrabbitRepository) repository).shutdown();
}
{code}
> ACL of versioned node can be modified without checking in the node
> --
>
> Key: OAK-6015
> URL: https://issues.apache.org/jira/browse/OAK-6015
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
>Reporter: Marco Piovesana
>
> On a versione node _nodeA_ i can do:
> {{AccessControlUtils.clear(nodeA, userPrincipal)}}
> without having to checkin the node.
> After saving the session I tried to login as _userPrincipal_ and I couldn't
> find _nodeA_, so it seems that the clear operation did work even if the node
> was checked-out.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
