[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994362#comment-15994362 ] Chetan Mehrotra commented on OAK-2808: -- bq. If blobs are removed after 30 minutes, and then one tries to rollback the repository state to before that (for the segment store, truncate the journal to what it was 31 minutes ago), the index would become corrupt. Yes that would be the case but then only guarantee we make with repository consistency at older revision is one where state is accessed based on some checkpoint. Any state beyond last valid checkpoint may not be consistent. If this is required then this feature can be disabled on those setups bq. An safer alternative to active deletion is to run revision garbage collection / segment store compaction, followed by datastore garbage collection. Thats the current state. However current cycle is set at weekly. And given DataStore GC for large repository takes time (mark phase on DocumentNodeStore specially and deletion in S3 is slow) its not feasible to run them frequently. May be for SegmentNodeStore with online gc we can run it frequently but that would need to be validated. bq. Basically, run the regular index update (which stores binaries in the datastore) much less frequently, for example just once per 5 minutes That would be tricky. If we make indexing less frequent then each cycle diff would take longer and it can lead to that indexing cycle take much longer causing the next cycle to take more time. We have seen this in few setups where if indexing starts lagging behind once and system is in active use then there is a high change of indexing lag becoming larger and larger (/cc [~stefan.eissing]) > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.8 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6153) Build Jackrabbit Oak #236 failed
Hudson created OAK-6153: --- Summary: Build Jackrabbit Oak #236 failed Key: OAK-6153 URL: https://issues.apache.org/jira/browse/OAK-6153 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ The build Jackrabbit Oak #236 has failed. First failed run: [Jackrabbit Oak #236|https://builds.apache.org/job/Jackrabbit%20Oak/236/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/236/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5192) Reduce Lucene related growth of repository size
[ https://issues.apache.org/jira/browse/OAK-5192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994348#comment-15994348 ] Thomas Mueller commented on OAK-5192: - An alternative to changing the merge policy might be to use NRT indexes, so that the index in the repository is updated much less frequently, for example every 5 minutes. See also the [comment OAK-2808|https://issues.apache.org/jira/browse/OAK-2808?focusedCommentId=15994345&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15994345]. Another alternative is to use asynchronous property indexes. It would be interesting to know the relative size / growth comparing asynchronous property indexes vs. asynchronous Lucene property indexes. > Reduce Lucene related growth of repository size > --- > > Key: OAK-5192 > URL: https://issues.apache.org/jira/browse/OAK-5192 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, segment-tar >Reporter: Michael Dürig > Labels: perfomance, scalability > Fix For: 1.8 > > Attachments: added-bytes-zoom.png > > > I observed Lucene indexing contributing to up to 99% of repository growth. > While the size of the index itself is well inside reasonable bounds, the > overall turnover of data being written and removed again can be as much as > 99%. > In the case of the TarMK this negatively impacts overall system performance > due to fast growing number of tar files / segments, bad locality of > reference, cache misses/thrashing when looking up segments and vastly > prolonged garbage collection cycles. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-2808) Active deletion of 'deleted' Lucene index files from DataStore without relying on full scale Blob GC
[ https://issues.apache.org/jira/browse/OAK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994345#comment-15994345 ] Thomas Mueller commented on OAK-2808: - I'm not sure if that's a big problem, but it is a limitation: If blobs are removed after 30 minutes, and then one tries to rollback the repository state to before that (for the segment store, truncate the journal to what it was 31 minutes ago), the index would become corrupt. An safer alternative to active deletion is to run revision garbage collection / segment store compaction, followed by datastore garbage collection. A second safer alternative would be to upload less binaries to the datastore. Don't we have that already with NRT indexes (where each cluster node indexes the repository state itself)? If not, could we change NRT indexes so this is possible? Basically, run the regular index update (which stores binaries in the datastore) much less frequently, for example just once per 5 minutes, but let each cluster node update the local index (in the file system) for example update every 10 seconds? > Active deletion of 'deleted' Lucene index files from DataStore without > relying on full scale Blob GC > > > Key: OAK-2808 > URL: https://issues.apache.org/jira/browse/OAK-2808 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Thomas Mueller > Labels: datastore, performance > Fix For: 1.8 > > Attachments: copyonread-stats.png, OAK-2808-1.patch > > > With storing of Lucene index files within DataStore our usage pattern > of DataStore has changed between JR2 and Oak. > With JR2 the writes were mostly application based i.e. if application > stores a pdf/image file then that would be stored in DataStore. JR2 by > default would not write stuff to DataStore. Further in deployment > where large number of binary content is present then systems tend to > share the DataStore to avoid duplication of storage. In such cases > running Blob GC is a non trivial task as it involves a manual step and > coordination across multiple deployments. Due to this systems tend to > delay frequency of GC > Now with Oak apart from application the Oak system itself *actively* > uses the DataStore to store the index files for Lucene and there the > churn might be much higher i.e. frequency of creation and deletion of > index file is lot higher. This would accelerate the rate of garbage > generation and thus put lot more pressure on the DataStore storage > requirements. > Discussion thread http://markmail.org/thread/iybd3eq2bh372zrl -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994338#comment-15994338
]
Marcel Reutegger commented on OAK-6149:
---
Unfortunately, it does fail. The next message in the log is:
{noformat}
02.05.2017 13:42:14.924 *DEBUG* [atomic-counter-3]
org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor
[5a97015f-6294-4d32-9057-81d91617a818] caught Exception. Rescheduling.
OakIndexUpdate0001: Missing index provider detected for type [lucene] on index
[/oak:index/authorizables]
{noformat}
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> 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.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-4933) Create a data store implementation that integrates with Microsoft Azure Blob Storage
[ https://issues.apache.org/jira/browse/OAK-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-4933: --- Fix Version/s: 1.6.2 > Create a data store implementation that integrates with Microsoft Azure Blob > Storage > > > Key: OAK-4933 > URL: https://issues.apache.org/jira/browse/OAK-4933 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob, core >Reporter: Matt Ryan >Assignee: Amit Jain > Fix For: 1.7.0, 1.8, 1.6.2 > > Attachments: full-patch-1.6.patch, OAK-4933-v5.patch > > > This epic proposes the creation of a new type of Oak data store, > AzureDataStore, that offers an integration between Oak and Microsoft Azure > Blob Storage. AzureDataStore would be very similar in purpose and > functionality to S3DataStore, with a different backend that uses Azure Blob > Storage instead of S3. > Some initial exploration into this concept can be seen in my github here: > https://github.com/mattvryan/jackrabbit-oak/tree/azure-blob-store > More info about Azure Blob Storage: > * [Java > SDK|https://azure.microsoft.com/en-us/documentation/articles/storage-java-how-to-use-blob-storage/] > * [Javadoc|http://azure.github.io/azure-storage-java/] > * [Source|https://github.com/azure/azure-storage-java] (GitHub) - Microsoft's > Azure Storage Java SDK is open source and Apache licensed > * [Package > info|https://mvnrepository.com/artifact/com.microsoft.azure/azure-storage] on > mvnrepository.com > As I see it, the following work would be required: > * Create an AzureDataStore class that extends CachingDataStore > * Create a new backend for Azure Blob Storage > * Comprehensive unit testing of the new data store and backend classes > * Create test "mocks" for the necessary Azure Storage classes to facilitate > unit testing (they are all final classes and cannot be mocked directly) > * Create SharedAzureDataStore class > * Create AzureDataStoreService class > * Implement similar JMX metrics as exist for S3DataStore > * Combine and refactor existing Oak code with newly added code to make best > reuse of existing code, etc. > * Integration testing with system configured with AzureDataStore, comparison > w/ S3DataStore in terms of performance and correctness > * Modify Azure Storage SDK code to make it into a valid OSGi bundle, and > submit these changes back to that project (currently it is not an OSGi bundle > and therefore currently has to be embedded) > List isn't purported to be comprehensive of course. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-4933) Create a data store implementation that integrates with Microsoft Azure Blob Storage
[ https://issues.apache.org/jira/browse/OAK-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994306#comment-15994306 ] Amit Jain commented on OAK-4933: Merged into 1.6 branch with 1793609, 1793610, 1793611 > Create a data store implementation that integrates with Microsoft Azure Blob > Storage > > > Key: OAK-4933 > URL: https://issues.apache.org/jira/browse/OAK-4933 > Project: Jackrabbit Oak > Issue Type: Epic > Components: blob, core >Reporter: Matt Ryan >Assignee: Amit Jain > Fix For: 1.7.0, 1.8, 1.6.2 > > Attachments: full-patch-1.6.patch, OAK-4933-v5.patch > > > This epic proposes the creation of a new type of Oak data store, > AzureDataStore, that offers an integration between Oak and Microsoft Azure > Blob Storage. AzureDataStore would be very similar in purpose and > functionality to S3DataStore, with a different backend that uses Azure Blob > Storage instead of S3. > Some initial exploration into this concept can be seen in my github here: > https://github.com/mattvryan/jackrabbit-oak/tree/azure-blob-store > More info about Azure Blob Storage: > * [Java > SDK|https://azure.microsoft.com/en-us/documentation/articles/storage-java-how-to-use-blob-storage/] > * [Javadoc|http://azure.github.io/azure-storage-java/] > * [Source|https://github.com/azure/azure-storage-java] (GitHub) - Microsoft's > Azure Storage Java SDK is open source and Apache licensed > * [Package > info|https://mvnrepository.com/artifact/com.microsoft.azure/azure-storage] on > mvnrepository.com > As I see it, the following work would be required: > * Create an AzureDataStore class that extends CachingDataStore > * Create a new backend for Azure Blob Storage > * Comprehensive unit testing of the new data store and backend classes > * Create test "mocks" for the necessary Azure Storage classes to facilitate > unit testing (they are all final classes and cannot be mocked directly) > * Create SharedAzureDataStore class > * Create AzureDataStoreService class > * Implement similar JMX metrics as exist for S3DataStore > * Combine and refactor existing Oak code with newly added code to make best > reuse of existing code, etc. > * Integration testing with system configured with AzureDataStore, comparison > w/ S3DataStore in terms of performance and correctness > * Modify Azure Storage SDK code to make it into a valid OSGi bundle, and > submit these changes back to that project (currently it is not an OSGi bundle > and therefore currently has to be embedded) > List isn't purported to be comprehensive of course. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5995) Lucene indexing with copyonread/write holding unexpectedly much files open
[
https://issues.apache.org/jira/browse/OAK-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994289#comment-15994289
]
Chetan Mehrotra commented on OAK-5995:
--
bq. It looks like the customer setup the pre production instance without
clearing the local FS copy of the index so Lucene was working the wrong files
and had issues with that.
Good to know. This would be handled better in Oak 1.6 with fix for OAK-4114
which would ensure that local index copy if purged if there is any mismatch
between index files on local dir and one in NodeStore
> Lucene indexing with copyonread/write holding unexpectedly much files open
> --
>
> Key: OAK-5995
> URL: https://issues.apache.org/jira/browse/OAK-5995
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
> Attachments: lsofout2.txt
>
>
> We recently faced the issue that our Oak based enterprise content management
> system run into failures due to too much open files. Monitoring the lsof
> output we found out that most of the opened files of the process are the
> files within the configured localIndexDir of the LuceneIndexProviderService.
> {code}
> enableCopyOnReadSupport="true"
> localIndexDir="tmp/index"
> enableCopyOnWriteSupport="true"
> {code}
> See attached the lsof output:
> {code}
> ~ wc -l lsofout2.txt
>20388 lsofout2.txt
> ~ grep "tmp/index" lsofout2.txt | wc -l
>13499
> {code}
> where more then 60% of open files are "tmp/index" ones as configured as
> {{localIndexDir}} shortly after a restart of the process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6081) Indexing tooling via oak-run
[ https://issues.apache.org/jira/browse/OAK-6081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994281#comment-15994281 ] Chetan Mehrotra commented on OAK-6081: -- This tooling can be implemented in following phases # v0 - Target here would be to have enable support for doing async indexing as is done currently via oak-run. In this phase we would not be changing indexing logic much but would just allow the async indexing run done via oak-run # v1 - Indexer creates index files only on file system and in the end the files are copied to repo # v2 - Support interruption i.e. if indexing gets killed in between it can start from last state # v3 - multithreaded traversal > Indexing tooling via oak-run > > > Key: OAK-6081 > URL: https://issues.apache.org/jira/browse/OAK-6081 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: indexing, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > To enable better management for indexing related operation specially around > reindexing indexes on large repository setup we should implement some tooling > as part of oak-run > The tool would support > # *Resumable tarversal* - It should be able to reindex large repo with > resumable traversal such that even if indexing breaks due to some issue it > can resume from last state (OAK-5833) > # *Multithreaded traversal* - Current indexing is single threaded and hence > for large repo it can take long time. Plan here is to support multi threaded > indexing where each thread can be assigned a part of repository tree to index > and in the end the indexes are merged > # For DocumentNodeStore setup it would be possible to connect oak-run to a > live cluster and it would take care of indexing -> storing index on disk -> > merging index -> importing it back at end. This would ensure that live setup > faces minimum disruption and is not loaded much > # For SegementNodeStore setup it would be possible to index on a cloned setup > and then provide a way to copy the index back -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994279#comment-15994279
]
Chetan Mehrotra commented on OAK-5412:
--
Looks good.
# May be break the commit in 2 where
## Refactoring related to use of Closer and
## Changes required for GCMonitor support
# From use in Segment it appears that LoggingGCMonitor is not enabled as a
service by default and needs to be explicitly used/configured. So may be we
need to use DelegatingGCMonitor which used LoggingGCMonitor and
GCMonitorTracker (/cc [~mduerig] )
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6075) Oak run console script to check index consistency
[ https://issues.apache.org/jira/browse/OAK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-6075: - Component/s: lucene > Oak run console script to check index consistency > - > > Key: OAK-6075 > URL: https://issues.apache.org/jira/browse/OAK-6075 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > > I would like to implement a groovy script to check index consistency. The > check would have two modes > # Basic check - Check if all blobs referred by index files can be accessed > # Deep check - This would use Lucene IndexCheck support > This is meant to be interim solution untill OAK-5558 is implemented as it > enables use of such a check on older branches also -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-6075) Oak run console script to check index consistency
[ https://issues.apache.org/jira/browse/OAK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6075. -- Resolution: Won't Fix Fix Version/s: (was: 1.8) Given we do not have consensus on hosting such scripts in oak repo I have moved them to https://github.com/chetanmeh/oak-console-scripts Resolving this as wont fix > Oak run console script to check index consistency > - > > Key: OAK-6075 > URL: https://issues.apache.org/jira/browse/OAK-6075 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > > I would like to implement a groovy script to check index consistency. The > check would have two modes > # Basic check - Check if all blobs referred by index files can be accessed > # Deep check - This would use Lucene IndexCheck support > This is meant to be interim solution untill OAK-5558 is implemented as it > enables use of such a check on older branches also -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (OAK-2214) NPE creating a PropertyIndex using default name
[
https://issues.apache.org/jira/browse/OAK-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2214.
--
Resolution: Won't Fix
> NPE creating a PropertyIndex using default name
> ---
>
> Key: OAK-2214
> URL: https://issues.apache.org/jira/browse/OAK-2214
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: property-index
>Reporter: Alex Parvulescu
>
> At one point in time it was possible to create a property index without
> specifying the property name[0] and the node name of the property definition
> was used, this yields a NPE now [1].
> [0] http://jackrabbit.apache.org/oak/docs/query.html#The_Property_Index
> [1]
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditor.(PropertyIndexEditor.java:119)
> at
> org.apache.jackrabbit.oak.plugins.index.property.PropertyIndexEditorProvider.getIndexEditor(PropertyIndexEditorProvider.java:44)
> at
> org.apache.jackrabbit.oak.plugins.index.CompositeIndexEditorProvider.getIndexEditor(CompositeIndexEditorProvider.java:74)
> at
> org.apache.jackrabbit.oak.spi.whiteboard.WhiteboardIndexEditorProvider.getIndexEditor(WhiteboardIndexEditorProvider.java:50)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.collectIndexEditors(IndexUpdate.java:156)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:115)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994264#comment-15994264
]
Chetan Mehrotra edited comment on OAK-6149 at 5/3/17 4:29 AM:
--
This is just a warn logging and it should not cause the call to fail as such.
The warning was meant to identify code paths which do not set CommitContext as
part of CommitInfo and looks like commit done by AtomicCounterEditor does not
include that. The exception trace logged was meant to identify such code paths
was (Author: chetanm):
This is just a warn logging and it should not cause the call to fail as such.
The warning was meant to identify code paths which do not set CommitContext as
part of CommitInfo and looks like commit done by AtomicCounterEditor does not
include that.
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> 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.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994264#comment-15994264
]
Chetan Mehrotra commented on OAK-6149:
--
This is just a warn logging and it should cause the call to fail as such. The
warning was meant to identify code paths which do not set CommitContext as part
of CommitInfo and looks like commit done by AtomicCounterEditor does not
include that.
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> 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.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
[
https://issues.apache.org/jira/browse/OAK-6149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994264#comment-15994264
]
Chetan Mehrotra edited comment on OAK-6149 at 5/3/17 4:28 AM:
--
This is just a warn logging and it should not cause the call to fail as such.
The warning was meant to identify code paths which do not set CommitContext as
part of CommitInfo and looks like commit done by AtomicCounterEditor does not
include that.
was (Author: chetanm):
This is just a warn logging and it should cause the call to fail as such. The
warning was meant to identify code paths which do not set CommitContext as part
of CommitInfo and looks like commit done by AtomicCounterEditor does not
include that.
> AtomicCounter fails with LuceneIndexEditorProvider
> --
>
> Key: OAK-6149
> URL: https://issues.apache.org/jira/browse/OAK-6149
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.6.0
> Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> The AtomicCounter fails to consolidate the value when running on
> DocumentNodeStore with lucene indexes.
> The task scheduled by the {{AtomicCounterEditor}} fails with:
> {noformat}
> 02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
> CommitContext found for commit
> java.lang.Exception: null
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
> 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.java:240)
> at
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
> at
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
> at
> org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
> at
> org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
> at
> org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993188#comment-15993188
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#235|https://builds.apache.org/job/Jackrabbit%20Oak/235/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/235/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6152) AccessControlImporter doesn't handle multivalued restrictions
angela created OAK-6152:
---
Summary: AccessControlImporter doesn't handle multivalued
restrictions
Key: OAK-6152
URL: https://issues.apache.org/jira/browse/OAK-6152
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Assignee: angela
Fix For: 1.7.0, 1.8
while working on OAK-5882 i noticed that the {{AccessControlImporter}} doesn't
handle multi-valued restrictions.
[~alex.parvulescu], fyi
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993108#comment-15993108
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#234|https://builds.apache.org/job/Jackrabbit%20Oak/234/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/234/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5042) Improve caching of segments
[
https://issues.apache.org/jira/browse/OAK-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-5042.
Resolution: Won't Fix
Fix Version/s: (was: 1.7.1)
(was: 1.8)
After further consideration and tests I couldn't find conclusive evidence for
changing the underlying cache: while some low level probing showed improvements
in the cache hit rate it also showed negative impacts elsewhere. I suggest to
take this issue up again should we encounter a specific bottleneck with the
segment cache which we have a benchmark for we can optimise against.
> Improve caching of segments
> ---
>
> Key: OAK-5042
> URL: https://issues.apache.org/jira/browse/OAK-5042
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: performance, scalability
> Attachments: OAK-5042.png
>
>
> Various aspects of how Segment Tar caches segments could possibly improved.
> The current cache is a result of replacing the former ad-hoc cache with a
> proper one in OAK-3055. While the former was prone to contention under
> concurrent load the current cache is too oblivious about reads: read accesses
> are always served through {{SegmentId.segment}} and never actually hit the
> cache. This results in frequently accessed segments not to be seen as such by
> the cache and potentially being prematurely evicted.
> Possibly approaches to address this problem include:
> * Reinstantiating the cache we had pre OAK-3055 but making in fully
> concurrent.
> * Convey the information about read accesses to the current cache.
> * In either of the above cases avoid bulk segments from being placed into the
> cache.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-5956) Improve cache statistics of the segment cache
[
https://issues.apache.org/jira/browse/OAK-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-5956.
Resolution: Fixed
Fix Version/s: (was: 1.7.1)
1.7.0
Fixed at http://svn.apache.org/viewvc?rev=1793528&view=rev
> Improve cache statistics of the segment cache
> -
>
> Key: OAK-5956
> URL: https://issues.apache.org/jira/browse/OAK-5956
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: monitoring
> Fix For: 1.7.0, 1.8
>
>
> The statistics provided by the segment cache are off due to the fact it
> serves as 2nd level cache: as it doesn't see all the hits in the 1st level
> cache ({{SegmentId.getSegment()}}), it reports a hit/miss rate that is to
> low.
> We should look into how we could expose better statistics wrt. caching of
> segments. Possible consolidated over 1st and 2nd level caches.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6151) Minor bugs in AccessControlImporter
[
https://issues.apache.org/jira/browse/OAK-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-6151:
Fix Version/s: 1.8
1.7.0
> Minor bugs in AccessControlImporter
> ---
>
> Key: OAK-6151
> URL: https://issues.apache.org/jira/browse/OAK-6151
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
>
> while working on OAK-5882 (i.e. writing tests for {{AccessControlImporter}})
> i noticed a few minor bugs:
> - {{init}}: should check for {{Session}} implementing {{JackrabbitSession}}
> - {{MutableEntry.setPrincipal}}: for consistency with the rest of the ac-mgt
> code this should throw {{javax.jcr.security.AccessControlException}} instead
> of {{java.security.AccessControlException}}
> - {{MutableEntry}}: potential NPE for privileges in case of an incomplete
> ACE. should create a empty list right away and then leave the handling of the
> empty priv-array to the {{acl.addEntry}} call in {{applyTo}}, which by
> default with throw {{AccessControlException}}.
> [~alexparvulescu], fyi
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6151) Minor bugs in AccessControlImporter
[
https://issues.apache.org/jira/browse/OAK-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela resolved OAK-6151.
-
Resolution: Fixed
Committed revision 1793516.
[~tripod], it might be that the fix replacing
{{java.security.AccessControlException}} by
{{javax.jcr.security.AccessControlException}} has an impact on the ac-import
part of Jackrabbit FileVault.
> Minor bugs in AccessControlImporter
> ---
>
> Key: OAK-6151
> URL: https://issues.apache.org/jira/browse/OAK-6151
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: angela
>Assignee: angela
>Priority: Minor
>
> while working on OAK-5882 (i.e. writing tests for {{AccessControlImporter}})
> i noticed a few minor bugs:
> - {{init}}: should check for {{Session}} implementing {{JackrabbitSession}}
> - {{MutableEntry.setPrincipal}}: for consistency with the rest of the ac-mgt
> code this should throw {{javax.jcr.security.AccessControlException}} instead
> of {{java.security.AccessControlException}}
> - {{MutableEntry}}: potential NPE for privileges in case of an incomplete
> ACE. should create a empty list right away and then leave the handling of the
> empty priv-array to the {{acl.addEntry}} call in {{applyTo}}, which by
> default with throw {{AccessControlException}}.
> [~alexparvulescu], fyi
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6122) enforce oak-run size
[
https://issues.apache.org/jira/browse/OAK-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-6122:
Attachment: oak-run-size-configurable.diff
Proposed patch allowing to override the limit using {{max.jar.size}}.
> enforce oak-run size
>
>
> Key: OAK-6122
> URL: https://issues.apache.org/jira/browse/OAK-6122
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Fix For: 1.7.0, 1.8
>
> Attachments: mvn.log, oak-run-size-configurable.diff
>
>
> In order to avoid again an uncontrolled growing of oak-run let's enforce some
> size control.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6151) Minor bugs in AccessControlImporter
angela created OAK-6151:
---
Summary: Minor bugs in AccessControlImporter
Key: OAK-6151
URL: https://issues.apache.org/jira/browse/OAK-6151
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: angela
Assignee: angela
Priority: Minor
while working on OAK-5882 (i.e. writing tests for {{AccessControlImporter}}) i
noticed a few minor bugs:
- {{init}}: should check for {{Session}} implementing {{JackrabbitSession}}
- {{MutableEntry.setPrincipal}}: for consistency with the rest of the ac-mgt
code this should throw {{javax.jcr.security.AccessControlException}} instead of
{{java.security.AccessControlException}}
- {{MutableEntry}}: potential NPE for privileges in case of an incomplete ACE.
should create a empty list right away and then leave the handling of the empty
priv-array to the {{acl.addEntry}} call in {{applyTo}}, which by default with
throw {{AccessControlException}}.
[~alexparvulescu], fyi
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992953#comment-15992953
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#233|https://builds.apache.org/job/Jackrabbit%20Oak/233/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/233/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992871#comment-15992871
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#232|https://builds.apache.org/job/Jackrabbit%20Oak/232/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/232/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992860#comment-15992860
]
Julian Reschke commented on OAK-6150:
-
I'm not sure how to get a *complete* list of errors, as the release plugin
stops when a subproject fails.
FWIW, we only need to address the errors for now.
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6089) update maven plugins
[ https://issues.apache.org/jira/browse/OAK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992846#comment-15992846 ] Thomas Mueller commented on OAK-6089: - http://svn.apache.org/r1793485 I also disabled line numbers. It looks like this was enabled before, but the old version probably didn't support it. I find the line numbers more distracting than helping. > update maven plugins > > > Key: OAK-6089 > URL: https://issues.apache.org/jira/browse/OAK-6089 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8 > > > Before moving to Java 8 (OAK-5664), I'd like to update all maven plugins to > the newest version applicable to the maven version we use (as suggested by > [~cziegeler]). > See also > http://www.mojohaus.org/versions-maven-plugin/examples/display-plugin-updates.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-6150:
-
Priority: Blocker (was: Major)
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Blocker
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992840#comment-15992840
]
Alex Parvulescu edited comment on OAK-6150 at 5/2/17 12:57 PM:
---
starting with the plan javadoc, and only focusing on errors:
{noformat}
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:139:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:140:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermEnum;
[ERROR] ^
[ERROR] symbol: class TermEnum
[ERROR] location: package org.apache.lucene.index
{noformat}
{noformat}
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public ConfigurationAdmin
addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:409:
error: type ServiceReference does not take parameters
[ERROR] public Repository addingService(ServiceReference reference)
{
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/RunnableJobTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public Future addingService(ServiceReference reference) {
{noformat}
{noformat}
[ERROR]
oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/FileCache.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
[ERROR]
oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
{noformat}
{noformat}
[ERROR]
oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/OakValue.java:31:
error: reference not found
[ERROR] * Same as {@link #getString()} unless that names and paths are returned
in their
{noformat}
was (Author: alex.parvulescu):
starting with the plan javadoc, and only focusing on errors:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:javadoc (default-cli) on
project jackrabbit-oak: An error has occurred in JavaDocs report generation:
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:139:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:140:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermEnum;
[ERROR] ^
[ERROR] symbol: class TermEnum
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public ConfigurationAdmin
addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:409:
error: type ServiceReference does not take parameters
[ERROR] public Repository addingService(ServiceReference reference)
{
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/RunnableJobTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public Future addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/FileCache.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
[ERROR]
oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
[ERROR]
oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/OakValue.java:31:
error: reference not found
[ERROR] * Same as {@link #getString()} unless that names and paths are returned
in their
{noformat}
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
[jira] [Commented] (OAK-6150) Javadoc plugin fails on Java 8
[
https://issues.apache.org/jira/browse/OAK-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992840#comment-15992840
]
Alex Parvulescu commented on OAK-6150:
--
starting with the plan javadoc, and only focusing on errors:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.10.3:javadoc (default-cli) on
project jackrabbit-oak: An error has occurred in JavaDocs report generation:
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:139:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermDocs;
[ERROR] ^
[ERROR] symbol: class TermDocs
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-upgrade/src/main/java/org/apache/jackrabbit/oak/upgrade/RepositoryUpgrade.java:140:
error: cannot find symbol
[ERROR] import org.apache.lucene.index.TermEnum;
[ERROR] ^
[ERROR] symbol: class TermEnum
[ERROR] location: package org.apache.lucene.index
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/ConfigTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public ConfigurationAdmin
addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/OakOSGiRepositoryFactory.java:409:
error: type ServiceReference does not take parameters
[ERROR] public Repository addingService(ServiceReference reference)
{
[ERROR] ^
[ERROR]
oak-pojosr/src/main/java/org/apache/jackrabbit/oak/run/osgi/RunnableJobTracker.java:60:
error: type ServiceReference does not take parameters
[ERROR] public Future addingService(ServiceReference reference) {
[ERROR] ^
[ERROR]
oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/FileCache.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
[ERROR]
oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/FileIOUtils.java:54:
error: cannot find symbol
[ERROR] import static org.apache.commons.io.FileUtils.copyInputStreamToFile;
[ERROR] ^
[ERROR] symbol: static copyInputStreamToFile
[ERROR] location: class
[ERROR]
oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/OakValue.java:31:
error: reference not found
[ERROR] * Same as {@link #getString()} unless that names and paths are returned
in their
{noformat}
> Javadoc plugin fails on Java 8
> --
>
> Key: OAK-6150
> URL: https://issues.apache.org/jira/browse/OAK-6150
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: doc
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
> Fix For: 1.7.0
>
>
> As discussed on the mailing list (will provide link soon) the javadoc
> generation fails on java 8. For next level complexity the release plugin also
> fails.
> For javadocs:
> {noformat}
> mvn javadoc:javadoc
> {noformat}
> and for the more adventurous:
> {noformat}
> mvn release:prepare -DdryRun=true
> {noformat}
> I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
> the release (not sure when that is though).
> [~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6150) Javadoc plugin fails on Java 8
Alex Parvulescu created OAK-6150:
Summary: Javadoc plugin fails on Java 8
Key: OAK-6150
URL: https://issues.apache.org/jira/browse/OAK-6150
Project: Jackrabbit Oak
Issue Type: Bug
Components: doc
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Fix For: 1.7.0
As discussed on the mailing list (will provide link soon) the javadoc
generation fails on java 8. For next level complexity the release plugin also
fails.
For javadocs:
{noformat}
mvn javadoc:javadoc
{noformat}
and for the more adventurous:
{noformat}
mvn release:prepare -DdryRun=true
{noformat}
I'm tentatively setting fix version 1.7.0 to try to resolve this in time for
the release (not sure when that is though).
[~reschke] could you add the relevant errors here?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6149) AtomicCounter fails with LuceneIndexEditorProvider
Marcel Reutegger created OAK-6149:
-
Summary: AtomicCounter fails with LuceneIndexEditorProvider
Key: OAK-6149
URL: https://issues.apache.org/jira/browse/OAK-6149
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Affects Versions: 1.6.0
Environment: Oak 1.6.1 with DocumentNodeStore on MongoDB 3.2.x
Reporter: Marcel Reutegger
Assignee: Marcel Reutegger
Fix For: 1.8
The AtomicCounter fails to consolidate the value when running on
DocumentNodeStore with lucene indexes.
The task scheduled by the {{AtomicCounterEditor}} fails with:
{noformat}
02.05.2017 13:42:14.923 *WARN* [atomic-counter-3]
org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider No
CommitContext found for commit
java.lang.Exception: null
at
org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorProvider.getIndexEditor(LuceneIndexEditorProvider.java:133)
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.java:240)
at
org.apache.jackrabbit.oak.plugins.index.IndexUpdate.enter(IndexUpdate.java:160)
at
org.apache.jackrabbit.oak.spi.commit.VisibleEditor.enter(VisibleEditor.java:57)
at
org.apache.jackrabbit.oak.spi.commit.CompositeEditor.enter(CompositeEditor.java:66)
at
org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:49)
at
org.apache.jackrabbit.oak.spi.commit.EditorHook.processCommit(EditorHook.java:54)
at
org.apache.jackrabbit.oak.spi.commit.CompositeHook.processCommit(CompositeHook.java:61)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch$InMemory.merge(DocumentNodeStoreBranch.java:511)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge0(DocumentNodeStoreBranch.java:185)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreBranch.merge(DocumentNodeStoreBranch.java:119)
at
org.apache.jackrabbit.oak.plugins.document.DocumentRootBuilder.merge(DocumentRootBuilder.java:167)
at
org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.merge(DocumentNodeStore.java:1694)
at
org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:410)
at
org.apache.jackrabbit.oak.plugins.atomic.AtomicCounterEditor$ConsolidatorTask.call(AtomicCounterEditor.java:335)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992830#comment-15992830 ] Alex Parvulescu commented on OAK-6136: -- bq. if you think it's a good idea, feel free to rename it as well. I'll leave it to [~chetanm] to decide what is best in this area. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.7.0, 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992823#comment-15992823 ] Tomek Rękawek commented on OAK-6136: The only parts of the code referencing the "multiplexing" keyword is the indexing logic in oak-core and oak-lucene. [~alex.parvulescu], if you think it's a good idea, feel free to rename it as well. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.7.0, 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-6136: --- Fix Version/s: 1.7.0 > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.7.0, 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992818#comment-15992818 ] Tomek Rękawek commented on OAK-6136: Done. The oak-multiplex module was renamed to oak-store-federated in [r1793482|https://svn.apache.org/r1793482]. Also, I've renamed all the class names and doc references. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: federated >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomek Rękawek updated OAK-6136: --- Component/s: multiplexing > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: multiplexing >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-5412:
--
Attachment: OAK-5412.patch
Attached proposed changes. Feedback welcome.
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
> Attachments: OAK-5412.patch
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992777#comment-15992777 ] Chetan Mehrotra commented on OAK-6136: -- bq. The proposed module name: oak-store-federated. +1. Federated store is more apt name and right now we do not have much baggage. So easy to rename. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6148) Warning if there are many Lucene documents
[ https://issues.apache.org/jira/browse/OAK-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-6148: Labels: candidate_oak_1_6 (was: ) > Warning if there are many Lucene documents > -- > > Key: OAK-6148 > URL: https://issues.apache.org/jira/browse/OAK-6148 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller > Labels: candidate_oak_1_6 > Fix For: 1.8 > > > Lucene indexes are limited to Integer.MAX_VALUE (LUCENE-4104), so Lucene > indexes can have at most around 2 billion nodes indexed. > We should avoid running into this limit. For example, we could log a warning > if the number of documents is a multiple of 200 million, so a user has plenty > of time to change the index configuration. > Also, it would be good to be able to read the current number of documents per > index (using JMX for example), so that one can find out how far he is from > the limit. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6148) Warning if there are many Lucene documents
[ https://issues.apache.org/jira/browse/OAK-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-6148: Component/s: lucene > Warning if there are many Lucene documents > -- > > Key: OAK-6148 > URL: https://issues.apache.org/jira/browse/OAK-6148 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Thomas Mueller > Fix For: 1.8 > > > Lucene indexes are limited to Integer.MAX_VALUE (LUCENE-4104), so Lucene > indexes can have at most around 2 billion nodes indexed. > We should avoid running into this limit. For example, we could log a warning > if the number of documents is a multiple of 200 million, so a user has plenty > of time to change the index configuration. > Also, it would be good to be able to read the current number of documents per > index (using JMX for example), so that one can find out how far he is from > the limit. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6148) Warning if there are many Lucene documents
Thomas Mueller created OAK-6148: --- Summary: Warning if there are many Lucene documents Key: OAK-6148 URL: https://issues.apache.org/jira/browse/OAK-6148 Project: Jackrabbit Oak Issue Type: Improvement Components: query Reporter: Thomas Mueller Fix For: 1.8 Lucene indexes are limited to Integer.MAX_VALUE (LUCENE-4104), so Lucene indexes can have at most around 2 billion nodes indexed. We should avoid running into this limit. For example, we could log a warning if the number of documents is a multiple of 200 million, so a user has plenty of time to change the index configuration. Also, it would be good to be able to read the current number of documents per index (using JMX for example), so that one can find out how far he is from the limit. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992756#comment-15992756 ] Michael Dürig commented on OAK-6136: Even better, agreed. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992755#comment-15992755 ] Tomek Rękawek edited comment on OAK-6136 at 5/2/17 11:40 AM: - Since we're here, how about renaming the Multiplexing Node Store to Federated Node Store? "Multiplexing" may give an impression that we allow to create a few separate Oak instances/node stores on a single physical node store, while it's quite the opposite. If we agree on this, I can take care of renaming. The proposed module name: oak-store-federated. was (Author: tomek.rekawek): Since we're here, how about renaming the Multiplexing Node Store to Federated Node Store? "Multiplexing" may give an impression that we allow to create a few separate Oak instances/node stores on a single physical node store, while it's quite the opposite. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992755#comment-15992755 ] Tomek Rękawek commented on OAK-6136: Since we're here, how about renaming the Multiplexing Node Store to Federated Node Store? "Multiplexing" may give an impression that we allow to create a few separate Oak instances/node stores on a single physical node store, while it's quite the opposite. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992669#comment-15992669
]
Alex Parvulescu commented on OAK-6145:
--
bq. do you know of the upgrade from Jackrabbit 2.x is always to Oak 1.0?
I think it is possible to upgrade to whatever version you need.
bq. in case we changed to content structure of the member-references, we would
need to make sure to touch the upgrade code
yes. very good point. upgrading the existing structure will be an important
topic once we settle on the new format, but I'd tackle that after we reach
consensus on what changes are needed in this area.
> Move MembershipWriter#setMembers() to oak-upgrade
> -
>
> Key: OAK-6145
> URL: https://issues.apache.org/jira/browse/OAK-6145
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security, upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6145.patch, OAK-6145-v2.patch
>
>
> As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's
> the only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-6145:
-
Attachment: OAK-6145-v2.patch
v2 of the patch. made the default value public and used it from the upgrade
code.
> Move MembershipWriter#setMembers() to oak-upgrade
> -
>
> Key: OAK-6145
> URL: https://issues.apache.org/jira/browse/OAK-6145
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security, upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6145.patch, OAK-6145-v2.patch
>
>
> As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's
> the only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6089) update maven plugins
[ https://issues.apache.org/jira/browse/OAK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992652#comment-15992652 ] Julian Reschke commented on OAK-6089: - Sorry for the breakage, and thanks for finding the right solution! > update maven plugins > > > Key: OAK-6089 > URL: https://issues.apache.org/jira/browse/OAK-6089 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8 > > > Before moving to Java 8 (OAK-5664), I'd like to update all maven plugins to > the newest version applicable to the maven version we use (as suggested by > [~cziegeler]). > See also > http://www.mojohaus.org/versions-maven-plugin/examples/display-plugin-updates.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (OAK-6147) Review SessionOperation usage in security code
Alex Parvulescu created OAK-6147:
Summary: Review SessionOperation usage in security code
Key: OAK-6147
URL: https://issues.apache.org/jira/browse/OAK-6147
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Some of the {{SessionOperation}} usage in security related bits is entirely not
correct. Most of the operations are marked as read-only, when a lot of them
should be read-write.
Items to review (just did a lookup of the class, so maybe not all of them need
attention):
org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator
org.apache.jackrabbit.oak.jcr.delegate.AuthorizableDelegator
org.apache.jackrabbit.oak.jcr.delegate.GroupDelegator
org.apache.jackrabbit.oak.jcr.delegate.ImpersonationDelegator
org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator
org.apache.jackrabbit.oak.jcr.delegate.PrincipalManagerDelegator
org.apache.jackrabbit.oak.jcr.delegate.PrivilegeManagerDelegator
org.apache.jackrabbit.oak.jcr.delegate.UserDelegator
org.apache.jackrabbit.oak.jcr.security.AccessManager
[~anchela] fyi
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6144) ExternalIdentity should have a method indicating if an identity is actually active
[ https://issues.apache.org/jira/browse/OAK-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992645#comment-15992645 ] angela commented on OAK-6144: - [~baedke], IMHO this is a new feature not an improvement -> adjusted type accordingly. > ExternalIdentity should have a method indicating if an identity is actually > active > -- > > Key: OAK-6144 > URL: https://issues.apache.org/jira/browse/OAK-6144 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > > The interface ExternalIdentityProvider currently offers the method > getIdentity(ExternalIdentityRef) to resolve a reference to an external > Identity, but there is no way to tell if the external identity is considered > active by the identity provider. The ability to resolve the reference doesn't > mean that the resulting identity may actually be used for authentication or > authorization. > If ExternaIIdentity isn't able to express this difference, it's hard to come > up with a sensible implemenation of e.g. > SynchronizationMBean#purgeOrphanedUsers(), because the ability to resolve a > reference to an external identity doesn't mean that the corresponding Oak > user is still valid. > A new method ExternalIdentiy#isActive() would allow us to clearly define the > notion of an "orphaned user". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (OAK-6144) ExternalIdentity should have a method indicating if an identity is actually active
[ https://issues.apache.org/jira/browse/OAK-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated OAK-6144: Issue Type: New Feature (was: Improvement) > ExternalIdentity should have a method indicating if an identity is actually > active > -- > > Key: OAK-6144 > URL: https://issues.apache.org/jira/browse/OAK-6144 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: auth-external >Reporter: Manfred Baedke >Assignee: Manfred Baedke > > The interface ExternalIdentityProvider currently offers the method > getIdentity(ExternalIdentityRef) to resolve a reference to an external > Identity, but there is no way to tell if the external identity is considered > active by the identity provider. The ability to resolve the reference doesn't > mean that the resulting identity may actually be used for authentication or > authorization. > If ExternaIIdentity isn't able to express this difference, it's hard to come > up with a sensible implemenation of e.g. > SynchronizationMBean#purgeOrphanedUsers(), because the ability to resolve a > reference to an external identity doesn't mean that the corresponding Oak > user is still valid. > A new method ExternalIdentiy#isActive() would allow us to clearly define the > notion of an "orphaned user". -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992644#comment-15992644
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#231|https://builds.apache.org/job/Jackrabbit%20Oak/231/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/231/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992637#comment-15992637
]
angela commented on OAK-6145:
-
[~alexparvulescu], if we made
{{MembershipWriter.DEFAULT_MEMBERSHIP_THRESHHOLD}} public, the
{{UpgradeMembershipWriter}} would not need to extend from {{MembershipWriter}}
and it was clear that the {{UpgradeMembershipWriter}} doesn't use any other
functionality provided by the {{MembershipWriter}}.
One more thought: do you know of the upgrade from Jackrabbit 2.x is always to
Oak 1.0? the reason why I am asking: in case we changed to content structure of
the member-references, we would need to make sure to touch the upgrade code
_if_ it was also intended to be used for direct upgrade from Jackrabbit 2.x to
Oak > 1.6.
> Move MembershipWriter#setMembers() to oak-upgrade
> -
>
> Key: OAK-6145
> URL: https://issues.apache.org/jira/browse/OAK-6145
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security, upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6145.patch
>
>
> As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's
> the only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6089) update maven plugins
[
https://issues.apache.org/jira/browse/OAK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992636#comment-15992636
]
Michael Dürig commented on OAK-6089:
Updating the skin to the latest version as well makes this work for me again:
{code}
--- oak-doc/src/site/site.xml (date 149371497)
+++ oak-doc/src/site/site.xml (revision )
@@ -89,7 +89,7 @@
org.apache.maven.skins
maven-fluido-skin
-1.3.0
+1.6
{code}
> update maven plugins
>
>
> Key: OAK-6089
> URL: https://issues.apache.org/jira/browse/OAK-6089
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.7.0, 1.8
>
>
> Before moving to Java 8 (OAK-5664), I'd like to update all maven plugins to
> the newest version applicable to the maven version we use (as suggested by
> [~cziegeler]).
> See also
> http://www.mojohaus.org/versions-maven-plugin/examples/display-plugin-updates.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6146) LoginModuleImpl could also clear local state after successful commit
Alex Parvulescu created OAK-6146:
Summary: LoginModuleImpl could also clear local state after
successful commit
Key: OAK-6146
URL: https://issues.apache.org/jira/browse/OAK-6146
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Priority: Minor
It seems the {{LoginModuleImpl}} clears its state in the case of an {{abort}}
(via the {{AbstractLoginModule}} or a successful {{commit}} that is coming from
another module.
A minor improvement here is that the login module doesn't need to hold on to
the local state until logout (when the module is discarded), if the login went
through on this module, so can clear state early on this execution branch as
well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6089) update maven plugins
[ https://issues.apache.org/jira/browse/OAK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992629#comment-15992629 ] Thomas Mueller commented on OAK-6089: - Hm, reverting _just_ the maven-site plugin to 3.3 will make "mvn site" work, but it looks like the documentation is no longer generated (without error message). So that might not be the solution. > update maven plugins > > > Key: OAK-6089 > URL: https://issues.apache.org/jira/browse/OAK-6089 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.7.0, 1.8 > > > Before moving to Java 8 (OAK-5664), I'd like to update all maven plugins to > the newest version applicable to the maven version we use (as suggested by > [~cziegeler]). > See also > http://www.mojohaus.org/versions-maven-plugin/examples/display-plugin-updates.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6089) update maven plugins
[
https://issues.apache.org/jira/browse/OAK-6089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992618#comment-15992618
]
Thomas Mueller commented on OAK-6089:
-
[~julian.resc...@gmx.de] you have updated maven-site-plugin from 3.3 to 3.6 in
http://svn.apache.org/viewvc?view=revision&revision=1791854 . It looks like
this broke "mvn site" for the "oak-doc" project. With 3.3, it works, and with
3.6, I get:
{noformat}
[ERROR] ResourceManager.getResource() parse exception
org.apache.velocity.exception.ParseErrorException: Encountered "source" at
META-INF/maven/site.vm[line 1039, column 52]
Was expecting one of:
"," ...
")" ...
...
{noformat}
Maybe we can just revert to 3.3?
> update maven plugins
>
>
> Key: OAK-6089
> URL: https://issues.apache.org/jira/browse/OAK-6089
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 1.7.0, 1.8
>
>
> Before moving to Java 8 (OAK-5664), I'd like to update all maven plugins to
> the newest version applicable to the maven version we use (as suggested by
> [~cziegeler]).
> See also
> http://www.mojohaus.org/versions-maven-plugin/examples/display-plugin-updates.html
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-6145:
-
Fix Version/s: 1.8
1.7.0
> Move MembershipWriter#setMembers() to oak-upgrade
> -
>
> Key: OAK-6145
> URL: https://issues.apache.org/jira/browse/OAK-6145
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security, upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6145.patch
>
>
> As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's
> the only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
[
https://issues.apache.org/jira/browse/OAK-6145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu updated OAK-6145:
-
Attachment: OAK-6145.patch
proposed patch. [~anchela] wdyt?
> Move MembershipWriter#setMembers() to oak-upgrade
> -
>
> Key: OAK-6145
> URL: https://issues.apache.org/jira/browse/OAK-6145
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security, upgrade
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>Priority: Minor
> Fix For: 1.7.0, 1.8
>
> Attachments: OAK-6145.patch
>
>
> As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's
> the only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OAK-6141) MembershipWriter setMembers() doesn't properly cleanup tree
[
https://issues.apache.org/jira/browse/OAK-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Parvulescu resolved OAK-6141.
--
Resolution: Won't Fix
resolving won't fix, created OAK-6145 for the method move.
> MembershipWriter setMembers() doesn't properly cleanup tree
> ---
>
> Key: OAK-6141
> URL: https://issues.apache.org/jira/browse/OAK-6141
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'm pretty sure this [0] is supposed to be instead:
> {noformat}
> group.getChildNode(UserConstants.REP_MEMBERS_LIST).remove();
> {noformat}
> in its current shape, this will fail to cleanup preexisting members.
> Also, I'd prefer if this would actually: 1. cleanup, 2. call existing
> #addMembers method to reduce code duplication.
> [~anchela] thoughts?
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/MembershipWriter.java#L248
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (OAK-6145) Move MembershipWriter#setMembers() to oak-upgrade
Alex Parvulescu created OAK-6145:
Summary: Move MembershipWriter#setMembers() to oak-upgrade
Key: OAK-6145
URL: https://issues.apache.org/jira/browse/OAK-6145
Project: Jackrabbit Oak
Issue Type: Improvement
Components: core, security, upgrade
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Priority: Minor
As suggested on OAK-6141, let's move this method to {{oak-upgrade}} as it's the
only place it's used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6098) Build timeout
[
https://issues.apache.org/jira/browse/OAK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992607#comment-15992607
]
Thomas Mueller edited comment on OAK-6098 at 5/2/17 9:24 AM:
-
"update maven plugins" is OAK-6089, not OAK-6098 as noted in the commit message
of http://svn.apache.org/r1791865
was (Author: tmueller):
"update maven plugins" is OAK-6089, not OAK-6089 as noted in the commit message
of http://svn.apache.org/r1791865
> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
> Labels: CI, jenkins
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually
> the build takes around 40mins.
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6098) Build timeout
[
https://issues.apache.org/jira/browse/OAK-6098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992607#comment-15992607
]
Thomas Mueller commented on OAK-6098:
-
"update maven plugins" is OAK-6089, not OAK-6089 as noted in the commit message
of http://svn.apache.org/r1791865
> Build timeout
> -
>
> Key: OAK-6098
> URL: https://issues.apache.org/jira/browse/OAK-6098
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
> Labels: CI, jenkins
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #175 has failed.
> First failed run: [Jackrabbit Oak
> #175|https://builds.apache.org/job/Jackrabbit%20Oak/175/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/175/console]
> This build timed out on node https://builds.apache.org/computer/H10. Usually
> the build takes around 40mins.
> {code}
> Build timed out (after 60 minutes). Marking the build as failed.
> {code}
> Also timed out on https://builds.apache.org/computer/cassandra5. See
> https://builds.apache.org/view/J/job/Jackrabbit%20Oak/208/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992578#comment-15992578
]
Hudson commented on OAK-6139:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#230|https://builds.apache.org/job/Jackrabbit%20Oak/230/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/230/console]
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992571#comment-15992571 ] Robert Munteanu edited comment on OAK-6136 at 5/2/17 8:59 AM: -- Makes sense to me, unless we want to add any potential multiplexing blob store implementation in the same project. was (Author: rombert): Makes sense to me, unless we want to add any potential blob store implementation in the same project. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[ https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992571#comment-15992571 ] Robert Munteanu commented on OAK-6136: -- Makes sense to me, unless we want to add any potential blob store implementation in the same project. > Extract the multiplexing implementation code into a separate bundle > --- > > Key: OAK-6136 > URL: https://issues.apache.org/jira/browse/OAK-6136 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Robert Munteanu >Assignee: Julian Sedding > Fix For: 1.8 > > Attachments: > 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch, > OAK-6136.patch > > > Since we already kicked off the m12n effort for 1.8 it would be good to > separate the multiplexing implementation from oak-core into its own bundle as > well. > I will look into providing a patch for the change. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-3834) AsyncIndexUpdate default async lease timeout is (too?) long
[ https://issues.apache.org/jira/browse/OAK-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992567#comment-15992567 ] Chetan Mehrotra commented on OAK-3834: -- bq. what prevents us from using a 1 minute timeout (indexing pause at most 2 minutes)? Fear of unknown ;) Some aspects I can think of # Cluster node N2 has a delayed background read and there in unstable topology it sees older value of lease update (say 2 mins old) and then it decides it can break the lease. In this case merge would not be successful but there would some churn though # With 1 min lease we would be update the lease every minute. So if an indexing cycle takes 10 min we would be doing 10 in between commits to renew the lease Note that the lease feature is a second level defence. If the setup has stable topology and the scheduling logic can ensure that indexing job is running as a true singleton in a cluster then it is not much required. In all thinking about it now I think we can reduce the timeout to 1 mins [~alex.parvulescu] Thoughts? > AsyncIndexUpdate default async lease timeout is (too?) long > --- > > Key: OAK-3834 > URL: https://issues.apache.org/jira/browse/OAK-3834 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller > > Oak ensures the async indexes are updated only in one cluster node, using a > lease mechanism in oak-core, org.apache.jackrabbit.oak.plugins.index, > AsyncIndexUpdate, DEFAULT_ASYNC_TIMEOUT. The default is 15 minutes (system > property "oak.async.lease.timeout", default "15"). > After killing the process or (when using OSGi) updating the Oak bundle, > sometimes the index is not updated for 15 minutes. > 15 minutes is quite long. What are the risks of changing this to 1 minutes? > According to some tests, the timeout mechanism is also used with the segment > store, even thought there can not be multiple cluster nodes. I thought the > timeout mechanism is only used with the document store? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6136) Extract the multiplexing implementation code into a separate bundle
[
https://issues.apache.org/jira/browse/OAK-6136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992564#comment-15992564
]
Michael Dürig commented on OAK-6136:
Would it make sense to name this module {{oak-store-multiplex}}? This name
would imply a bit more about what it is while at the same time placing in next
to {{oak-store-spi}}.
> Extract the multiplexing implementation code into a separate bundle
> ---
>
> Key: OAK-6136
> URL: https://issues.apache.org/jira/browse/OAK-6136
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Robert Munteanu
>Assignee: Julian Sedding
> Fix For: 1.8
>
> Attachments:
> 0001-OAK-6136-Extract-the-multiplexing-implementation-cod.patch,
> OAK-6136.patch
>
>
> Since we already kicked off the m12n effort for 1.8 it would be good to
> separate the multiplexing implementation from oak-core into its own bundle as
> well.
> I will look into providing a patch for the change.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-4637) Property index: include/exclude key pattern list
[
https://issues.apache.org/jira/browse/OAK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992553#comment-15992553
]
Chetan Mehrotra edited comment on OAK-4637 at 5/2/17 8:49 AM:
--
The usecase I have in mind is the one related to slingResourceType. In Sling
the "sling:resourceType" property is added to each node created via Sling api.
Due to this even the nodes created for Sling Job Management also have
sling:resourceType=slingevent:Job or sling:Folder causing such nodes to be
indexed.
However no code does a query for these values. So we need a way to exclude such
resource type values from getting indexed i.e. way to provide a list of values
which should not be indexed
Also note that there may be query like below which should still be able to use
the index on sling:resourceType.
{noformat}
/jcr:root/etc/replication//*[jcr:like(@sling:resourceType,
"cq/replication/components/%agent")]
{noformat}
>From my current understanding of code in property index such queries gets
>converted to property != null (untill OAK-5897 is implemented). The current
>implementation (rev 1793097) looks like would opt out of handling such a
>query. But we need a way such that index still gets used for these queries.
{noformat}
if (valuePattern.matchesAll()) {
// matches all values: not a problem
} else if (values == null) {
// "is not null" condition, but we have a value pattern
// that doesn't match everything
// so we can't use that index
continue;
}
{noformat}
was (Author: chetanm):
The usecase I have in mind is the one related to slingResourceType. In Sling
the "sling:resourceType" property is added to each node created via Sling api.
Due to this even the nodes created for Sling Job Management also have
sling:resourceType=slingevent:Job or sling:Folder causing such nodes to be
indexed.
However no code does a query for these values. So we need a way to exclude such
resource type values from getting indexed.
Do note that there may be query like below which should still be able to use
the index on sling:resourceType.
{noformat}
/jcr:root/etc/replication//*[jcr:like(@sling:resourceType,
"cq/replication/components/%agent")]
{noformat}
>From my current understanding of code in property index such queries gets
>converted to property != null (untill OAK-5897 is implemented). The current
>implementation (rev 1793097) looks like would opt out of handling such a
>query. But we need a way such that index still gets used.
{noformat}
if (valuePattern.matchesAll()) {
// matches all values: not a problem
} else if (values == null) {
// "is not null" condition, but we have a value pattern
// that doesn't match everything
// so we can't use that index
continue;
}
{noformat}
> Property index: include/exclude key pattern list
>
>
> Key: OAK-4637
> URL: https://issues.apache.org/jira/browse/OAK-4637
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.8
>
>
> In some cases, property indexes contain many nodes, and updating them can be
> slow. Right now we have filters for node and mixin types, path (include and
> exclude).
> An include and exclude list of values (patterns) would be useful. For example
> the property "status", if we only ever run queries with the condition "status
> = 'ACTIVE'", then nodes with status INACTIVE and DONE don't need to be
> indexed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-4653) nodetype index can create unusable nodes under index structures
[
https://issues.apache.org/jira/browse/OAK-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra updated OAK-4653:
-
Fix Version/s: 1.8
> nodetype index can create unusable nodes under index structures
> ---
>
> Key: OAK-4653
> URL: https://issues.apache.org/jira/browse/OAK-4653
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: property-index
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
> Fix For: 1.8
>
>
> {{nodetype}} index is just a special property index definition with
> definition declaring to index {{jcr:primaryType}} and {{jcr:mixinTypes}}.
> Since, it's just property index, we can specify {{declaringNodeTypes}} too to
> filter which type of nodes get indexed.
> On query side, declaringNodeTypes are used to check whether the index can be
> used at all or not.
> Now, for nodetype, if node being indexed passes declaringNodeType filter
> (either primary type or mixin matches), then all its mixins and primaryType
> gets indexed irrespective of whether declaringNodeType contains it or not.
> This is perfectly correct behavior from property index point of view. But, in
> this regards, we should treat nodetype index to be special and index only
> those property values that are part of declaring node types.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4637) Property index: include/exclude key pattern list
[
https://issues.apache.org/jira/browse/OAK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992553#comment-15992553
]
Chetan Mehrotra commented on OAK-4637:
--
The usecase I have in mind is the one related to slingResourceType. In Sling
the "sling:resourceType" property is added to each node created via Sling api.
Due to this even the nodes created for Sling Job Management also have
sling:resourceType=slingevent:Job or sling:Folder causing such nodes to be
indexed.
However no code does a query for these values. So we need a way to exclude such
resource type values from getting indexed.
Do note that there may be query like below which should still be able to use
the index on sling:resourceType.
{noformat}
/jcr:root/etc/replication//*[jcr:like(@sling:resourceType,
"cq/replication/components/%agent")]
{noformat}
>From my current understanding of code in property index such queries gets
>converted to property != null (untill OAK-5897 is implemented). The current
>implementation (rev 1793097) looks like would opt out of handling such a
>query. But we need a way such that index still gets used.
{noformat}
if (valuePattern.matchesAll()) {
// matches all values: not a problem
} else if (values == null) {
// "is not null" condition, but we have a value pattern
// that doesn't match everything
// so we can't use that index
continue;
}
{noformat}
> Property index: include/exclude key pattern list
>
>
> Key: OAK-4637
> URL: https://issues.apache.org/jira/browse/OAK-4637
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: property-index
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.8
>
>
> In some cases, property indexes contain many nodes, and updating them can be
> slow. Right now we have filters for node and mixin types, path (include and
> exclude).
> An include and exclude list of values (patterns) would be useful. For example
> the property "status", if we only ever run queries with the condition "status
> = 'ACTIVE'", then nodes with status INACTIVE and DONE don't need to be
> indexed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6129) Create compound index on _sdType and _sdMaxRevTime
[
https://issues.apache.org/jira/browse/OAK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992543#comment-15992543
]
Chetan Mehrotra commented on OAK-6129:
--
bq. I'm prepared to change the DB schema, but it will require a bit of work
with respect to compatibility and migration. I wouldn't rush this until we have
proper test coverage for it.
Then lets have an issue for that so that it gets tracked
> Create compound index on _sdType and _sdMaxRevTime
> --
>
> Key: OAK-6129
> URL: https://issues.apache.org/jira/browse/OAK-6129
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
>
> Replace the current index on {{_sdType}} with a partial index on {{_sdType}}
> and {{_sdMaxRevTime}}. This is required to run queries issued by the Revision
> GC efficiently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-5995) Lucene indexing with copyonread/write holding unexpectedly much files open
[
https://issues.apache.org/jira/browse/OAK-5995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992541#comment-15992541
]
Dirk Rudolph commented on OAK-5995:
---
Thanks for your support [~chetanm]. It looks like the customer setup the pre
production instance without clearing the local FS copy of the index so Lucene
was working the wrong files and had issues with that. Clearing the local copy
of the indexes and letting them be recreated from repo resolved the issue as
far as I know.
> Lucene indexing with copyonread/write holding unexpectedly much files open
> --
>
> Key: OAK-5995
> URL: https://issues.apache.org/jira/browse/OAK-5995
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.1
>Reporter: Dirk Rudolph
>Assignee: Chetan Mehrotra
> Attachments: lsofout2.txt
>
>
> We recently faced the issue that our Oak based enterprise content management
> system run into failures due to too much open files. Monitoring the lsof
> output we found out that most of the opened files of the process are the
> files within the configured localIndexDir of the LuceneIndexProviderService.
> {code}
> enableCopyOnReadSupport="true"
> localIndexDir="tmp/index"
> enableCopyOnWriteSupport="true"
> {code}
> See attached the lsof output:
> {code}
> ~ wc -l lsofout2.txt
>20388 lsofout2.txt
> ~ grep "tmp/index" lsofout2.txt | wc -l
>13499
> {code}
> where more then 60% of open files are "tmp/index" ones as configured as
> {{localIndexDir}} shortly after a restart of the process.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4637) Property index: include/exclude key pattern list
[ https://issues.apache.org/jira/browse/OAK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992523#comment-15992523 ] Thomas Mueller commented on OAK-4637: - If there are two patterns, I guess "exclude" would have priority. > Property index: include/exclude key pattern list > > > Key: OAK-4637 > URL: https://issues.apache.org/jira/browse/OAK-4637 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.8 > > > In some cases, property indexes contain many nodes, and updating them can be > slow. Right now we have filters for node and mixin types, path (include and > exclude). > An include and exclude list of values (patterns) would be useful. For example > the property "status", if we only ever run queries with the condition "status > = 'ACTIVE'", then nodes with status INACTIVE and DONE don't need to be > indexed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6141) MembershipWriter setMembers() doesn't properly cleanup tree
[
https://issues.apache.org/jira/browse/OAK-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992524#comment-15992524
]
angela commented on OAK-6141:
-
i don't have a strong preference wrt moving... whenever i stumble over that
method it bothers me a little bit where it is located and that is is public for
usage out of {{oak-upgrade}} only... but never enough though to actually take
action. but it even confused me in the past so maybe it's time now :-)
> MembershipWriter setMembers() doesn't properly cleanup tree
> ---
>
> Key: OAK-6141
> URL: https://issues.apache.org/jira/browse/OAK-6141
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'm pretty sure this [0] is supposed to be instead:
> {noformat}
> group.getChildNode(UserConstants.REP_MEMBERS_LIST).remove();
> {noformat}
> in its current shape, this will fail to cleanup preexisting members.
> Also, I'd prefer if this would actually: 1. cleanup, 2. call existing
> #addMembers method to reduce code duplication.
> [~anchela] thoughts?
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/MembershipWriter.java#L248
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-4637) Property index: include/exclude key pattern list
[ https://issues.apache.org/jira/browse/OAK-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992520#comment-15992520 ] Thomas Mueller commented on OAK-4637: - [~chetanm] it is possible to use regular expressions to exclude entries as well, using [negative|http://stackoverflow.com/questions/2078915/a-regular-expression-to-exclude-a-word-string] [look-around|http://stackoverflow.com/questions/406230/regular-expression-to-match-a-line-that-doesnt-contain-a-word]. Even thought it is probably not that efficient (I'm not sure if it's measurably slower). it would be good to know more exact use cases. Use cases I have in mind are: * as a basis for OAK-4653 (include list should be sufficient here) * to exclude certain common "slingResourceType" values (for example), and similar, in order to shrink the index size (only index what is really queried for). > Property index: include/exclude key pattern list > > > Key: OAK-4637 > URL: https://issues.apache.org/jira/browse/OAK-4637 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: property-index >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Critical > Fix For: 1.8 > > > In some cases, property indexes contain many nodes, and updating them can be > slow. Right now we have filters for node and mixin types, path (include and > exclude). > An include and exclude list of values (patterns) would be useful. For example > the property "status", if we only ever run queries with the condition "status > = 'ACTIVE'", then nodes with status INACTIVE and DONE don't need to be > indexed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (OAK-5412) Use GCMonitor for revision gc task run in DocumentNodeStore
[
https://issues.apache.org/jira/browse/OAK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-5412:
-
Assignee: Marcel Reutegger
> Use GCMonitor for revision gc task run in DocumentNodeStore
> ---
>
> Key: OAK-5412
> URL: https://issues.apache.org/jira/browse/OAK-5412
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
>Reporter: Chetan Mehrotra
>Assignee: Marcel Reutegger
> Fix For: 1.8
>
>
> DocumentNodeStore should use {{GCMonitor}} to inform interested parties about
> GC task progress (similar to how its used in SegmentNodeStore)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6141) MembershipWriter setMembers() doesn't properly cleanup tree
[
https://issues.apache.org/jira/browse/OAK-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992515#comment-15992515
]
Alex Parvulescu commented on OAK-6141:
--
bq. the method mentioned is only used for migration from Jackrabbit 2.x to Oak.
ah, thanks for clarifying. I read the javadoc 'migration' as also 'upgrade'
(Oak -> Oak) and possibly 'sidegrade' (see new Oak Segment Tar format).
bq. would suggest to resolve this not a bug.
makes perfect sense
bq. what we could do though is moving the migration code (i.e. that very
method) to the oak-upgrade module as it is really not used elsewhere.
hmm, maybe move it to a local {{upgrade}} package?
> MembershipWriter setMembers() doesn't properly cleanup tree
> ---
>
> Key: OAK-6141
> URL: https://issues.apache.org/jira/browse/OAK-6141
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'm pretty sure this [0] is supposed to be instead:
> {noformat}
> group.getChildNode(UserConstants.REP_MEMBERS_LIST).remove();
> {noformat}
> in its current shape, this will fail to cleanup preexisting members.
> Also, I'd prefer if this would actually: 1. cleanup, 2. call existing
> #addMembers method to reduce code duplication.
> [~anchela] thoughts?
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/MembershipWriter.java#L248
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-3834) AsyncIndexUpdate default async lease timeout is (too?) long
[ https://issues.apache.org/jira/browse/OAK-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992505#comment-15992505 ] Thomas Mueller commented on OAK-3834: - [~chetanm] [~catholicon] what prevents us from using a 1 minute timeout (indexing pause at most 2 minutes)? I think 5 minutes timeout (indexing pause of 10 minutes) is still quite long. There are two reasons (I know) to use a short timeout: * Users have to wait until indexes are update. * Due to caching effect, indexing is probably a bit faster if timeout is shorter. With caching effect I mean: data that was stored recently is still in the (MongoDB or filesystem ) cache. > AsyncIndexUpdate default async lease timeout is (too?) long > --- > > Key: OAK-3834 > URL: https://issues.apache.org/jira/browse/OAK-3834 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller > > Oak ensures the async indexes are updated only in one cluster node, using a > lease mechanism in oak-core, org.apache.jackrabbit.oak.plugins.index, > AsyncIndexUpdate, DEFAULT_ASYNC_TIMEOUT. The default is 15 minutes (system > property "oak.async.lease.timeout", default "15"). > After killing the process or (when using OSGi) updating the Oak bundle, > sometimes the index is not updated for 15 minutes. > 15 minutes is quite long. What are the risks of changing this to 1 minutes? > According to some tests, the timeout mechanism is also used with the segment > store, even thought there can not be multiple cluster nodes. I thought the > timeout mechanism is only used with the document store? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (OAK-5947) Allowing non-admin user to set repository permissions fails
[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992498#comment-15992498
]
angela edited comment on OAK-5947 at 5/2/17 7:49 AM:
-
proposed fix in OAK-5947.patch
[~alexparvulescu], i would appreciate if you could review the proposed fix.
will continue to write additional tests for the additional permission-eval
calls for the repository level.
was (Author: anchela):
proposed fix.
[~alexparvulescu], i would appreciate if you could review the proposed fix.
will continue to write additional tests for the additional permission-eval
calls for the repository level.
> Allowing non-admin user to set repository permissions fails
> ---
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
>Reporter: Julian Sedding
>Assignee: angela
> Fix For: 1.8
>
> Attachments: OAK-5947.patch, OAK-5947-tests.patch,
> SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
>
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6139) Test failure: SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6139:
--
Labels: CI Jenkins (was: )
Fix Version/s: 1.8
Component/s: pojosr
Summary: Test failure:
SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
(was: Build Jackrabbit Oak #220 failed)
> Test failure:
> SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable()
> ---
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, pojosr
>Reporter: Hudson
> Labels: CI, Jenkins
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-6139) Build Jackrabbit Oak #220 failed
[
https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6139:
--
Description:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #220 has failed.
First failed run: [Jackrabbit Oak
#220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
{noformat}
[ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.813
s <<< FAILURE! - in
org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
[ERROR]
testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
Time elapsed: 0.219 s <<< FAILURE!
org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
assert securityProviderServiceReferences != null
| |
null false
at
org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
at
org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
at
org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
{noformat}
was:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #220 has failed.
First failed run: [Jackrabbit Oak
#220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> Build Jackrabbit Oak #220 failed
>
>
> Key: OAK-6139
> URL: https://issues.apache.org/jira/browse/OAK-6139
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #220 has failed.
> First failed run: [Jackrabbit Oak
> #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console]
> {noformat}
> [ERROR] Tests run: 11, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 2.813 s <<< FAILURE! - in
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest
> [ERROR]
> testRequiredAuthorizationConfigurationNotAvailable(org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest)
> Time elapsed: 0.219 s <<< FAILURE!
> org.codehaus.groovy.runtime.powerassert.PowerAssertionError:
> assert securityProviderServiceReferences != null
>| |
>null false
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredService(SecurityProviderRegistrationTest.groovy:318)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.this$3$testRequiredService(SecurityProviderRegistrationTest.groovy)
> at
> org.apache.jackrabbit.oak.run.osgi.SecurityProviderRegistrationTest.testRequiredAuthorizationConfigurationNotAvailable(SecurityProviderRegistrationTest.groovy:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (OAK-5947) Allowing non-admin user to set repository permissions fails
[
https://issues.apache.org/jira/browse/OAK-5947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-5947:
Attachment: OAK-5947-tests.patch
OAK-5947.patch
proposed fix.
[~alexparvulescu], i would appreciate if you could review the proposed fix.
will continue to write additional tests for the additional permission-eval
calls for the repository level.
> Allowing non-admin user to set repository permissions fails
> ---
>
> Key: OAK-5947
> URL: https://issues.apache.org/jira/browse/OAK-5947
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.0, 1.2, 1.4.0, 1.6.0
>Reporter: Julian Sedding
>Assignee: angela
> Fix For: 1.8
>
> Attachments: OAK-5947.patch, OAK-5947-tests.patch,
> SetRepoPolicyTest.patch
>
>
> Given a user principal {{testUser}} is granted {{jcr:readAccessControl}} and
> {{jcr:modifyAccessControl}} on the repository ({{rep:repoPolicy}}), I would
> expect that this user can e.g. allow {{everyone}} the
> {{jcr:namespaceManagement}} permission on the repository.
> Currently this fails with the following exception:
> {noformat}
> javax.jcr.PathNotFoundException: No tree at null
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:163)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.getApplicablePolicies(AccessControlManagerImpl.java:184)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:121)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$7.perform(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:208)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.getApplicablePolicies(AccessControlManagerDelegator.java:117)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.getApplicablePolicies(JackrabbitAccessControlManagerDelegator.java:147)
> at
> org.apache.jackrabbit.commons.jackrabbit.authorization.AccessControlUtils.getAccessControlList(AccessControlUtils.java:128)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:85)
>
> {noformat}
> or after granting {{jcr:read}} on {{/}}:
> {noformat}
> javax.jcr.AccessDeniedException
> at org.apache.jackrabbit.oak.util.NodeUtil.addChild(NodeUtil.java:113)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setNodeBasedAcl(AccessControlManagerImpl.java:289)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:220)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.oak.jcr.SetRepoPolicyPermissionsTest.setRepositoryPermissions(SetRepoPolicyPermissionsTest.java:90)
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6139) Build Jackrabbit Oak #220 failed
[ https://issues.apache.org/jira/browse/OAK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992484#comment-15992484 ] Hudson commented on OAK-6139: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #229|https://builds.apache.org/job/Jackrabbit%20Oak/229/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/229/console] > Build Jackrabbit Oak #220 failed > > > Key: OAK-6139 > URL: https://issues.apache.org/jira/browse/OAK-6139 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #220 has failed. > First failed run: [Jackrabbit Oak > #220|https://builds.apache.org/job/Jackrabbit%20Oak/220/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/220/console] -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (OAK-6141) MembershipWriter setMembers() doesn't properly cleanup tree
[
https://issues.apache.org/jira/browse/OAK-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992480#comment-15992480
]
angela commented on OAK-6141:
-
what we could do though is moving the migration code (i.e. that very method) to
the {{oak-upgrade}} module as it is really not used elsewhere.
> MembershipWriter setMembers() doesn't properly cleanup tree
> ---
>
> Key: OAK-6141
> URL: https://issues.apache.org/jira/browse/OAK-6141
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'm pretty sure this [0] is supposed to be instead:
> {noformat}
> group.getChildNode(UserConstants.REP_MEMBERS_LIST).remove();
> {noformat}
> in its current shape, this will fail to cleanup preexisting members.
> Also, I'd prefer if this would actually: 1. cleanup, 2. call existing
> #addMembers method to reduce code duplication.
> [~anchela] thoughts?
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/MembershipWriter.java#L248
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6141) MembershipWriter setMembers() doesn't properly cleanup tree
[
https://issues.apache.org/jira/browse/OAK-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992476#comment-15992476
]
angela commented on OAK-6141:
-
[~alexparvulescu], the method mentioned is only used for migration from
Jackrabbit 2.x to Oak. Therefore the existing code is correct as the
{{UserConstants.REP_MEMBERS_LIST}} was only introduced in Oak 1.0. Previously
the tree structure started differently as you can see in the node type
definition. I would not touch that migration code unless we have a bug in the
migration, which IMHO is not the case.
-> would suggest to resolve this not a bug.
> MembershipWriter setMembers() doesn't properly cleanup tree
> ---
>
> Key: OAK-6141
> URL: https://issues.apache.org/jira/browse/OAK-6141
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: Alex Parvulescu
>Assignee: Alex Parvulescu
>
> I'm pretty sure this [0] is supposed to be instead:
> {noformat}
> group.getChildNode(UserConstants.REP_MEMBERS_LIST).remove();
> {noformat}
> in its current shape, this will fail to cleanup preexisting members.
> Also, I'd prefer if this would actually: 1. cleanup, 2. call existing
> #addMembers method to reduce code duplication.
> [~anchela] thoughts?
> [0]
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/MembershipWriter.java#L248
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6129) Create compound index on _sdType and _sdMaxRevTime
[
https://issues.apache.org/jira/browse/OAK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992443#comment-15992443
]
Julian Reschke commented on OAK-6129:
-
[~mreutegg] - back then, there simply was no need, as there simply was no RDB
specific VersionGCSupport. When I introduced it, I worked around the issue by
using constraints on {{_id}} instead.
I'm prepared to change the DB schema, but it will require a bit of work with
respect to compatibility and migration. I wouldn't rush this until we have
proper test coverage for it.
> Create compound index on _sdType and _sdMaxRevTime
> --
>
> Key: OAK-6129
> URL: https://issues.apache.org/jira/browse/OAK-6129
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
>
> Replace the current index on {{_sdType}} with a partial index on {{_sdType}}
> and {{_sdMaxRevTime}}. This is required to run queries issued by the Revision
> GC efficiently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6129) Create compound index on _sdType and _sdMaxRevTime
[
https://issues.apache.org/jira/browse/OAK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15992443#comment-15992443
]
Julian Reschke edited comment on OAK-6129 at 5/2/17 7:02 AM:
-
[~mreutegg] - back then, there simply was no need, as there simply was no RDB
specific {{VersionGCSupport}}. When I introduced it, I worked around the issue
by using constraints on {{_id}} instead.
I'm prepared to change the DB schema, but it will require a bit of work with
respect to compatibility and migration. I wouldn't rush this until we have
proper test coverage for it.
was (Author: reschke):
[~mreutegg] - back then, there simply was no need, as there simply was no RDB
specific VersionGCSupport. When I introduced it, I worked around the issue by
using constraints on {{_id}} instead.
I'm prepared to change the DB schema, but it will require a bit of work with
respect to compatibility and migration. I wouldn't rush this until we have
proper test coverage for it.
> Create compound index on _sdType and _sdMaxRevTime
> --
>
> Key: OAK-6129
> URL: https://issues.apache.org/jira/browse/OAK-6129
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
> Fix For: 1.7.0, 1.8
>
>
> Replace the current index on {{_sdType}} with a partial index on {{_sdType}}
> and {{_sdMaxRevTime}}. This is required to run queries issued by the Revision
> GC efficiently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
