[jira] [Updated] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-8187:
--
Fix Version/s: 1.14.0

> Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider 
> and RestrictionProvider
> -
>
> Key: OAK-8187
> URL: https://issues.apache.org/jira/browse/OAK-8187
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Reporter: angela
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>
> The way multiple {{AuthorizableNodeName}}, {{AuthorizableActionProvider}} and 
> {{RestrictionProvider}} service are handled by 
> {{SecurityProviderRegistration}} suffers from the same issues as was reported 
> for {{UserAuthenticationFactory}} (see OAK-8045). Once OAK-8045 is addressed 
> we should adopt the same behavior for the remaining bind/unbind methods for 
> the interfaces mentioned above.
> cc: [~stillalex]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5858) Lucene index may return the wrong result if path is excluded

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5858:
--
Fix Version/s: (was: 1.12.0)

> Lucene index may return the wrong result if path is excluded
> 
>
> Key: OAK-5858
> URL: https://issues.apache.org/jira/browse/OAK-5858
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> If a query uses a Lucene index that has "excludedPaths", the query result may 
> be wrong (not contain all matching nodes). This is case even if there is a 
> property index available for the queried property. Example:
> {noformat}
> Indexes:
> /oak:index/resourceType/type = "property"
> /oak:index/lucene/type = "lucene"
> /oak:index/lucene/excludedPaths = ["/etc"]
> /oak:index/lucene/indexRules/nt:base/properties/resourceType
> Query:
> /jcr:root/etc//*[jcr:like(@resourceType, "x%y")]
> Index cost:
> cost for /oak:index/resourceType is 1602.0
> cost for /oak:index/lucene is 1001.0
> Result:
> (empty)
> Expected result:
> /etc/a
> /etc/b
> {noformat}
> Here, the lucene index is picked, even thought the query explicitly queries 
> for /etc, and the lucene index has this path excluded.
> I think the lucene index should not be picked in case the index does not 
> match the query path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8203) Build Jackrabbit Oak #2070 failed

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813334#comment-16813334
 ] 

Hudson commented on OAK-8203:
-

Build is still failing.
Failed run: [Jackrabbit Oak 
#2072|https://builds.apache.org/job/Jackrabbit%20Oak/2072/] [console 
log|https://builds.apache.org/job/Jackrabbit%20Oak/2072/console]

> Build Jackrabbit Oak #2070 failed
> -
>
> Key: OAK-8203
> URL: https://issues.apache.org/jira/browse/OAK-8203
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration
>Reporter: Hudson
>Priority: Major
>
> No description is provided
> The build Jackrabbit Oak #2070 has failed.
> First failed run: [Jackrabbit Oak 
> #2070|https://builds.apache.org/job/Jackrabbit%20Oak/2070/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/2070/console]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OAK-8186) Create API in OAK for file access to binaries in the repository.

[Ruben Reusser (JIRA)]

[ 
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813336#comment-16813336
 ] 

Ruben Reusser commented on OAK-8186:


[~mduerig] nio.Files.copy is a file system copy (operates on files directly), 
o.a.c.io.IOUtils.copy is a stream copy and represents the way jackrabbit file 
vault and other upstream applications using oak mostly create temp files. 

> Create API in OAK for file access to binaries in the repository.
> 
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>Reporter: Henry Saginor
>Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg, 
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It 
> would be nice if an API existed to get file access directly from OAK. This 
> might also meet some use cases documented at 
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached 
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API 
> makes it explicit that a temp file is created. I am not sure if direct access 
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>  
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6765) Convert oak-jcr to OSGi R6 annotations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6765:
--
Fix Version/s: (was: 1.12.0)

> Convert oak-jcr to OSGi R6 annotations
> --
>
> Key: OAK-6765
> URL: https://issues.apache.org/jira/browse/OAK-6765
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: jcr
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7412) Make oak-solr extend from oak-search

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7412:
--
Fix Version/s: (was: 1.12.0)

> Make oak-solr extend from oak-search
> 
>
> Key: OAK-7412
> URL: https://issues.apache.org/jira/browse/OAK-7412
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: oak-search
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Once Oak Search module is ready, Oak Solr should be refactored so that it 
> extends from oak-search SPIs.
> Both implementation and extensive testing (regression, performance) should be 
> conducted to make sure nothing is lost during this transition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7744) Persistent cache for the Segment Node Store

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7744:
--
Fix Version/s: (was: 1.12.0)

> Persistent cache for the Segment Node Store
> ---
>
> Key: OAK-7744
> URL: https://issues.apache.org/jira/browse/OAK-7744
> Project: Jackrabbit Oak
>  Issue Type: Story
>  Components: segment-tar
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7744.patch
>
>
> With the introduction of custom, remote persistence mechanisms for the 
> SegmentMK (namely the Azure Segment Store), it makes sense to create another 
> level of cache, apart from the on-heap segment cache which is currently used.
> Let's implement the persistent cache, using the existing {{TarFiles}} class 
> and storing the processed segments on disk. It may be created as a 
> pass-through {{SegmentNodeStorePersistence}} implementation, so it can be 
> composed with other existing persistence implementations, eg. [split 
> persistence|OAK-7735].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6264) Test failure: IllegalArgumentException during upgrade tests

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6264:
--
Fix Version/s: (was: 1.12.0)

> Test failure: IllegalArgumentException during upgrade tests 
> 
>
> Key: OAK-6264
> URL: https://issues.apache.org/jira/browse/OAK-6264
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, upgrade
>Reporter: Hudson
>Priority: Major
>  Labels: CI, jenkins, test-failure
> Fix For: 1.14.0
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #338 has failed.
> First failed run: [Jackrabbit Oak 
> #338|https://builds.apache.org/job/Jackrabbit%20Oak/338/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/338/console]
> {noformat}
> javax.jcr.RepositoryException: Failed to copy content
> Stacktrace
> java.lang.RuntimeException: javax.jcr.RepositoryException: Failed to copy 
> content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: javax.jcr.RepositoryException: Failed to copy content
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> Caused by: java.lang.IllegalArgumentException
>   at 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.prepare(CopyCheckpointsTest.java:141)
> {noformat}
> This affects 
> {noformat}
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Suppress
>  the warning]
> 
> org.apache.jackrabbit.oak.upgrade.CopyCheckpointsTest.validateMigration[Source
>  data store defined, checkpoints migrated]
> 
> org.apache.jackrabbit.oak.upgrade.IgnoreMissingBinariesTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.UpgradeOldSegmentTest.upgradeFrom10
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentTarToSegmentTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTarWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.SegmentToSegmentWithMissingDestinationDirectoryTest.validateMigration
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment-tar -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, no blobstores defined, segment -> segment-tar]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to embedded, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  embedded to external, no blobstores defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  references, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to embedded, src blobstore defined]
> 
> org.apache.jackrabbit.oak.upgrade.cli.blob.CopyBinariesTest.validateMigration[Copy
>  external to external, src blobstore defined]
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFbsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FbsToFdsTest.validateMigration
> org.apache.jackrabbit.oak.upgrade.cli.blob.FdsToFbsTest.validateMigration
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5553) Index async index in a new lane without blocking the main lane

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5553:
--
Fix Version/s: (was: 1.12.0)

> Index async index in a new lane without blocking the main lane
> --
>
> Key: OAK-5553
> URL: https://issues.apache.org/jira/browse/OAK-5553
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: indexing
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently if an async index has to be reindex for any reason say update of 
> index definition then this process blocks the indexing of other indexes on 
> that lane. 
> For e.g. if on "async" lane we have 2 indexes /oak:index/fooIndex and 
> /oak:index/barIndex and fooIndex needs to be reindexed. In such a case 
> currently AsyncIndexUpdate would work on reindexing and untill that gets 
> complete other index do not receive any update. If the reindexing takes say 1 
> day then other index would start lagging behind by that time. Note that NRT 
> indexing would help somewhat here.
> To improve this we can implement something similar to what was done for 
> property index in OAK-1456 i.e. provide a way where 
> # an admin can trigger reindex of some async indexes
> # those indexes are moved to different lane and then reindexed
> # post reindexing logic should then move them back to there original lane
> Further this task can then be performed on non leader node as the indexes 
> would not be part of any active lane. Also we may implement it as part of 
> oak-run



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-2976) Oak percolator

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-2976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-2976:
--
Fix Version/s: (was: 1.12.0)

> Oak percolator
> --
>
> Key: OAK-2976
> URL: https://issues.apache.org/jira/browse/OAK-2976
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: query
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Inspired by [Elasticsearch 
> percolator|https://www.elastic.co/guide/en/elasticsearch/reference/current/search-percolate.html]
>  we may implement an Oak percolator that would basically store queries and 
> perform specific tasks upon indexing of documents matching those queries.
> The reasons for possibly having that are that such a mechanism could be used 
> to run common but slow queries automatically whenever batches of matching 
> documents get indexed, to eventually warm up the underlying indexes caches.
> Also such a percolator could be used as a notification mechanism (alerting, 
> monitoring).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6303) Cache in CachingBlobStore might grow beyond configured limit

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6303:
--
Fix Version/s: (was: 1.12.0)

> Cache in CachingBlobStore might grow beyond configured limit
> 
>
> Key: OAK-6303
> URL: https://issues.apache.org/jira/browse/OAK-6303
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: blob, core
>Reporter: Julian Reschke
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-6303-test.diff, OAK-6303.diff
>
>
> It appears that depending on actual cache entry sizes, the {{CacheLIRS}} 
> might grow beyond the configured limit.
> For {{RDBBlobStore}}, the limit is currently configured to 16MB, yet storing 
> random 2M entries appears to fill the cache with 64MB of data (according to 
> it's own stats).
> The attached test case reproduces this.
> (it seems this is caused by the fact that each of the 16 segments of the 
> cache can hold 2 entries, no matter how big they are...)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7671) [oak-run] Deprecate the datastorecheck command in favor of datastore

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7671:
--
Fix Version/s: (was: 1.12.0)

> [oak-run] Deprecate the datastorecheck command in favor of datastore
> 
>
> Key: OAK-7671
> URL: https://issues.apache.org/jira/browse/OAK-7671
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: run
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.14.0
>
>
> With the introduction of \{{datastore}} command which supports both garbage 
> collection as well as consistency check the \{{datastorecheck}} command 
> should be deprecated and delegated internally to use that implementation. 
> Besides some options which are currently not supported by the new command 
> should also be implemented e.g. --ids, --refs



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7328) Update DocumentNodeStore based OakFixture

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7328:
--
Fix Version/s: (was: 1.12.0)

> Update DocumentNodeStore based OakFixture
> -
>
> Key: OAK-7328
> URL: https://issues.apache.org/jira/browse/OAK-7328
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: run
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> The current OakFixtures using a DocumentNodeStore use a configuration / setup 
> which is different from what a default DocumentNodeStoreService would use. It 
> would be better if benchmarks run with a configuration close to a default 
> setup. The main differences identified are:
> - Does not have a proper executor, which means some tasks are executed with 
> the same thread.
> - Does not use a separate persistent cache for the journal (diff cache).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-1905) SegmentMK: Arch segment(s)

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-1905:
--
Fix Version/s: (was: 1.12.0)

> SegmentMK: Arch segment(s)
> --
>
> Key: OAK-1905
> URL: https://issues.apache.org/jira/browse/OAK-1905
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Jukka Zitting
>Priority: Minor
>  Labels: perfomance, scalability
> Fix For: 1.14.0
>
>
> There are a lot of constants and other commonly occurring name, values and 
> other data in a typical repository. To optimize storage space and access 
> speed, it would be useful to place such data in one or more constant "arch 
> segments" that are always cached in memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5937) Disable query where path restriction is not absolute

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5937:
--
Fix Version/s: (was: 1.12.0)

> Disable query where path restriction is not absolute
> 
>
> Key: OAK-5937
> URL: https://issues.apache.org/jira/browse/OAK-5937
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
> Fix For: 1.14.0
>
>
> Query like below cannot be executed in a performant way. We should provide an 
> option to reject such queries
> //content/foo/bar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7725) Allow to have the users and groups created in the immutable part of the composite setup

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7725:
--
Fix Version/s: (was: 1.12.0)

> Allow to have the users and groups created in the immutable part of the 
> composite setup
> ---
>
> Key: OAK-7725
> URL: https://issues.apache.org/jira/browse/OAK-7725
> Project: Jackrabbit Oak
>  Issue Type: Story
>  Components: composite, security
>Reporter: Tomek Rękawek
>Assignee: Tomek Rękawek
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7725-tests.patch
>
>
> When running the Oak with Composite Node Store, the /home subtree is always 
> stored in the mutable, global part. Therefore, even if we switch the 
> immutable part (eg. /libs), the users and groups are not affected.
> This setup makes sense for the users and groups created interactively. 
> However, we also have the service users, which usually are not created 
> interactively, but are part of the application and therefore are related to 
> the /libs part. For such users, it'd make sense to include them dynamically, 
> together with the application, read-only mount.
> The proposal is to allow some part of the /home (eg. /home/service) to be 
> mounted from the read-only partial node store. Let's consider the constraints 
> we need to put in place (eg. it shouldn't be possible to have inter-mounts 
> group memberships) and how we can implement this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6309) Not always convert XPath "primaryType in a, b" to union

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6309:
--
Fix Version/s: (was: 1.12.0)

> Not always convert XPath "primaryType in a, b" to union
> ---
>
> Key: OAK-6309
> URL: https://issues.apache.org/jira/browse/OAK-6309
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Currently, queries with multiple primary types are always converted to a 
> "union", but this is not alway the best solution. The main problem is that 
> results are not sorted by score as expected. Example:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (@jcr:primaryType = 'acme:Page' or @jcr:primaryType = 'acme:Asset')] 
> {noformat}
> This is currently converted to a union, even if the same index is used for 
> buth subqueries (assuming there is an index on nt:hierarchyNode).
> A workaround is to use:
> {noformat}
> /jcr:root/content//element(*, nt:hierarchyNode)[jcr:contains(., 'abc)
> and (./@jcr:primaryType = 'acme:Page' or ./@jcr:primaryType = 'acme:Asset')] 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6619) Async indexer thread may get stuck in CopyOnWriteDirectory close method

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6619:
--
Fix Version/s: (was: 1.12.0)

> Async indexer thread may get stuck in CopyOnWriteDirectory close method
> ---
>
> Key: OAK-6619
> URL: https://issues.apache.org/jira/browse/OAK-6619
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Critical
> Fix For: 1.14.0
>
> Attachments: status-threaddump-Sep-5.txt
>
>
> With copy-on-write mode enabled at times its seen that async index thread 
> remain stuck in CopyOnWriteDirectory#close method
> {noformat}
> "async-index-update-async" prio=5 tid=0xb9e63 nid=0x timed_waiting
>java.lang.Thread.State: TIMED_WAITING
>   at sun.misc.Unsafe.park(Native Method)
>   - waiting to lock <0x2504cd51> (a 
> java.util.concurrent.CountDownLatch$Sync) owned by "null" tid=0x-1
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
>   at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.directory.CopyOnWriteDirectory.close(CopyOnWriteDirectory.java:221)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.updateSuggester(DefaultIndexWriter.java:177)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.writer.DefaultIndexWriter.close(DefaultIndexWriter.java:121)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorContext.closeWriter(LuceneIndexEditorContext.java:136)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditor.leave(LuceneIndexEditor.java:154)
>   at 
> org.apache.jackrabbit.oak.plugins.index.IndexUpdate.leave(IndexUpdate.java:357)
>   at 
> org.apache.jackrabbit.oak.spi.commit.VisibleEditor.leave(VisibleEditor.java:60)
>   at 
> org.apache.jackrabbit.oak.spi.commit.EditorDiff.process(EditorDiff.java:56)
>   at 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.updateIndex(AsyncIndexUpdate.java:727)
>   at 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.runWhenPermitted(AsyncIndexUpdate.java:572)
>   at 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate.run(AsyncIndexUpdate.java:431)
>   - locked <0x3d542de5> (a 
> org.apache.jackrabbit.oak.plugins.index.AsyncIndexUpdate)
>   at 
> org.apache.sling.commons.scheduler.impl.QuartzJobExecutor.execute(QuartzJobExecutor.java:245)
>   at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
>   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}
> The thread is waiting on a latch and no other thread is going to release the 
> latch.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-2538) Support index time aggregation in Solr index

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-2538:
--
Fix Version/s: (was: 1.12.0)

> Support index time aggregation in Solr index
> 
>
> Key: OAK-2538
> URL: https://issues.apache.org/jira/browse/OAK-2538
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: performance
> Fix For: 1.14.0
>
>
> Solr index is only able to do query time aggregation while that "would not 
> perform well for multi term searches as each term involves a separate call 
> and with intersection cursor being used the operation might result in reading 
> up all match terms even when user accesses only first page", therefore it'd 
> be good to implement index time aggregation like in Lucene index. (/cc 
> [~chetanm])



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6973) Define public/internal packages

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6973:
--
Fix Version/s: (was: 1.12.0)

> Define public/internal packages
> ---
>
> Key: OAK-6973
> URL: https://issues.apache.org/jira/browse/OAK-6973
> Project: Jackrabbit Oak
>  Issue Type: Task
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.14.0
>
>
> As part of the Oak modularization packages previously exported without a 
> version will at some point have to adhere to proper semantic versioning. See 
> also OAK-3919 and its sub-tasks.
> Since some of those packages are not meant to be used outside of Oak, there 
> should be a mechanism to define which exported packages are public and which 
> are considered internal. While semantic versioning rules apply to both 
> categories, we may want to provide different guarantees/guidance to consumers 
> of those packages. E.g. increasing the major version of a package used only 
> by Oak has less impact compared to a major version increase of a 'public' 
> package used by many applications.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5488) BackgroundObserver MBean report Listener class again

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5488:
--
Fix Version/s: (was: 1.12.0)

> BackgroundObserver MBean report Listener class again
> 
>
> Key: OAK-5488
> URL: https://issues.apache.org/jira/browse/OAK-5488
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, jcr
>Affects Versions: 1.5.18
>Reporter: Stefan Eissing
>Priority: Minor
> Fix For: 1.14.0
>
>
> The MBean stats for {{BackgroundObserverStats}} used to give the className of 
> the listening class.
> With the introduction of {{FilteringDispatcher}} all MBeans only list that 
> class name, making it difficult to find out which observer really is shown.
> Proposal: show the effective className as before again.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6833) LuceneIndex*Test failures

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6833:
--
Fix Version/s: (was: 1.12.0)

> LuceneIndex*Test failures
> -
>
> Key: OAK-6833
> URL: https://issues.apache.org/jira/browse/OAK-6833
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Julian Reschke
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: 
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  
> TEST-org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.xml,
>  org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexAugmentTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.txt, 
> unit-tests.log, unit-tests.log, unit-tests.log
>
>
> {noformat}
> [ERROR] testLuceneWithRelativeProperty[1: useBlobStore 
> (false)](org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest)
>   Time elapsed: 0.063 s  <<< FAILURE!
> java.lang.AssertionError: expected: but was:
> at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexEditorTest.testLuceneWithRelativeProperty(LuceneIndexEditorTest.java:341)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5152) Improve overflow handling in ChangeSetFilterImpl

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5152:
--
Fix Version/s: (was: 1.12.0)

> Improve overflow handling in ChangeSetFilterImpl
> 
>
> Key: OAK-5152
> URL: https://issues.apache.org/jira/browse/OAK-5152
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.5.14
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.14.0
>
>
> As described in OAK-5151 when a ChangeSet overflows, the ChangeSetFilterImpl 
> treats the changes as included and doesn't go further into the remaining, 
> perhaps not-overflown other sets. Besides more testing it wouldn't be much 
> effort to change this though. Putting this as outside of 1.6 scope for now 
> though.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5291) Per-Query Limits (nodes read, nodes read in memory)

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5291:
--
Fix Version/s: (was: 1.12.0)

> Per-Query Limits (nodes read, nodes read in memory)
> ---
>
> Key: OAK-5291
> URL: https://issues.apache.org/jira/browse/OAK-5291
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-1395 we added limits for long running queries. In OAK-1571 we added 
> OSGi configuration. In OAK-5237 we change the default settings.
> It would be nice to be able to define the limits per query, similar to 
> OAK-4888. The query would look like (for example, to limit reading to 1 
> million nodes, even if the default query limit is lower):
> {noformat}
> select * from [nt:base] 
> where ischildnode('/oak:index') 
> order by name()
> option(traversal ok, limit 100)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7922) Improve the operations and the reporting of the check command

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7922:
--
Fix Version/s: (was: 1.12.0)

> Improve the operations and the reporting of the check command
> -
>
> Key: OAK-7922
> URL: https://issues.apache.org/jira/browse/OAK-7922
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-7922-01.patch
>
>
> The check command allows a user to check for both the head and the 
> checkpoints. At the end of the execution the command outputs the consistent 
> revisions for the head and the individual checkpoints, if any is found. 
> Moreover, it prints an overall good revision. The consistent revisions for 
> the head and the checkpoints could all be different. If both the head and all 
> the checkpoints are assigned to a consistent revision, the overall good 
> revision is the oldest of those revisions.
> I wonder how useful all of this information is to a user of the command:
>  - I might have a revision where a checkpoint is consistent, but the head is 
> not. In this case, I don't want to revert to that revision because my system 
> will probably be unstable due to the inconsistent head.
>  - The overall good revision might still be partially inconsistent due to the 
> way the command short-circuits the consistency check on the head and the 
> checkpoints. If I revert to the overall good revision, the head might still 
> be inconsistent or one of the checkpoints might be missing.
> I propose to remove the {{\--checkpoints}} and the {{\--head}} flags and 
> define the behaviour of the command as follows.
>  - The check command checks one super-root at a time in its entirety (both 
> head and referenced checkpoints).
>  - The command exits as soon as a super-root is found where both the head and 
> all the checkpoints are consistent.
>  - While searching, the command might find a super-root with a consistent 
> head but one or more inconsistent checkpoint. In this case, the first of such 
> revisions is printed, specifying which checkpoints are inconsistent.
>  - The user might specify a {{--no-checkpoints}} flag to skip checking the 
> checkpoints in the steps above.
> The optimisations currently implemented by the check command can be 
> maintained. We don't need to fully traverse the head or the checkpoints if a 
> well-known corrupted path is still corrupted in the current iteration. The 
> approach proposed above enables additional optimisations:
>  - Since checkpoints are immutable, the command doesn't need to traverse a 
> checkpoint that was inspected before. This is true regardless of the 
> consistency of the checkpoint.
>  - If a super-root includes a checkpoint that was previously determined 
> corrupted, the command can skip that super-root without further inspection.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7230) Reduce calls to DocumentStore

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7230:
--
Fix Version/s: (was: 1.12.0)

> Reduce calls to DocumentStore
> -
>
> Key: OAK-7230
> URL: https://issues.apache.org/jira/browse/OAK-7230
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Major
>  Labels: performance
> Fix For: 1.14.0
>
>
> Analyze and further reduce calls to the DocumentStore when content is written 
> to the repository. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7192) Remove package export for org.apache.jackrabbit.oak.composite.checks

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7192:
--
Fix Version/s: (was: 1.12.0)

> Remove package export for org.apache.jackrabbit.oak.composite.checks
> 
>
> Key: OAK-7192
> URL: https://issues.apache.org/jira/browse/OAK-7192
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> It appears the package {{org.apache.jackrabbit.oak.composite.checks}} is only 
> used internally by the oak-store-composite module and should not be exported.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6947) Add package export versions for oak-store-spi

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6947:
--
Fix Version/s: (was: 1.12.0)

> Add package export versions for oak-store-spi
> -
>
> Key: OAK-6947
> URL: https://issues.apache.org/jira/browse/OAK-6947
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: store-spi
>Reporter: angela
>Assignee: Michael Dürig
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-6947.patch
>
>
> [~mduerig], [~mreutegg], [~frm], [~stillalex], do you have any strong 
> preferences wrt to the packages we placed in the _oak-store-spi_ module?
> Currently we explicitly export all packages and I think it would make sense 
> to enable the baseline plugin for these packages.
> Any objection from your side?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4498) Introduce lower limit for gc() maxRevisionAge

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4498:
--
Fix Version/s: (was: 1.12.0)

> Introduce lower limit for gc() maxRevisionAge
> -
>
> Key: OAK-4498
> URL: https://issues.apache.org/jira/browse/OAK-4498
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, documentmk
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> Introduce and enforce a lower limit for maxRevisionAge in 
> VersionGarbageCollector.gc().
> OAK-4494 changes the way documents in a cache are considered up-to-date. In 
> addition to the modCount value it also considers the modified timestamp. To 
> work properly, a new document must have a modified timestamp that is 
> different from a previous incarnation (i.e. before gc removed it). The 
> version GC should therefore not remove documents with a maxRevisionAge less 
> than the modified resolution (5 seconds).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5792) TarMK: Implement tooling to repair broken nodes

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5792:
--
Fix Version/s: (was: 1.12.0)

> TarMK: Implement tooling to repair broken nodes
> ---
>
> Key: OAK-5792
> URL: https://issues.apache.org/jira/browse/OAK-5792
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: run, segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: production, technical_debt, tooling
> Fix For: 1.14.0
>
>
> With {{oak-run check}} we can determine the last good revision of a 
> repository and use it to manually roll back a corrupted segment store. 
> Complementary to this we should implement a tool to roll forward a broken 
> revision to a fixed new revision. Such a tool needs to detect which items are 
> affected by a corruption and replace these items with markers. With this the 
> repository could brought back online and the markers could be used to 
> identify the locations in the tree where further manual action might be 
> needed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6566) Generate markdown files from metatype description

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6566:
--
Fix Version/s: (was: 1.12.0)

> Generate markdown files from metatype description
> -
>
> Key: OAK-6566
> URL: https://issues.apache.org/jira/browse/OAK-6566
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: doc
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently we maintain some documentation around supporting configuration 
> options for few components at [1]. Same information is also captured in 
> metatype annotation.
> We should look into generating these md file from metatype. This can possibly 
> be done via a new maven plugin [2]
> [1] http://jackrabbit.apache.org/oak/docs/osgi_config.html
> [2] https://github.com/TouK/metatype-exporter-maven-plugin



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5655) TarMK: Analyse locality of reference

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5655:
--
Fix Version/s: 1.14.0

> TarMK: Analyse locality of reference 
> -
>
> Key: OAK-5655
> URL: https://issues.apache.org/jira/browse/OAK-5655
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-tar
>Reporter: Michael Dürig
>Priority: Major
>  Labels: scalability
> Fix For: 1.12.0, 1.14.0
>
> Attachments: compaction-time-vs-reposize.m, 
> compaction-time-vs.reposize.png, data00053a.tar-reads.png, offrc.jfr, 
> segment-per-path-compacted-nocache.png, 
> segment-per-path-compacted-nostringcache.png, segment-per-path-compacted.png, 
> segment-per-path.png, segment-reads.png
>
>
> We need to better understand the locality aspects of content stored in TarMK: 
> * How is related content spread over segments?
> * What content do we consider related? 
> * How does locality of related content develop over time when changes are 
> applied?
> * What changes do we consider typical?
> * What is the impact of compaction on locality? 
> * What is the impact of the deduplication caches on locality (during normal 
> operation and during compaction)?
> * How good are checkpoints deduplicated? Can we monitor this online?
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7504) Include dynamic commit information in the persisted repository data

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7504:
--
Fix Version/s: (was: 1.12.0)

> Include dynamic commit information in the persisted repository data
> ---
>
> Key: OAK-7504
> URL: https://issues.apache.org/jira/browse/OAK-7504
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Minor
> Fix For: 1.14.0
>
>
> The data in the Segment Store doesn't provide any information about the 
> dynamic behaviour of the system. For example, who performed the commit? How 
> many commits were performed from the same committer?
> In order to simplify debugging the dynamic behaviour of a system, it should 
> be possible to store metadata about the commit in the super-root generated by 
> that commit. For example, the following information might be attached to the 
> super-root:
> * The name of the thread performing the commit. This solution might prove 
> expensive in terms of consumed disk space, but would be the most precise tool 
> to identify the author of a commit.
> * A hash of the thread name. If storing thread names proves expensive, a hash 
> of the thread name can be stored instead. This doesn't allow to exactly 
> identify the author of the commit, but would allow us to correlated different 
> commits as performed by the same thread.
> * Both the thread name and its hash, with the thread name stored only every 
> Nth commit. This solution is not as precise as storing the thread name for 
> every commit but, if there is a frequent committer, its thread name will be 
> more likely to be sampled, thus providing a precise identity to a thread name 
> hash.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6346) Set baseline plugin comparison for trunk to latest stable version

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6346:
--
Fix Version/s: (was: 1.12.0)

> Set baseline plugin comparison for trunk to latest stable version
> -
>
> Key: OAK-6346
> URL: https://issues.apache.org/jira/browse/OAK-6346
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: parent
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-6346-v1.patch, release-process-v1.patch
>
>
> The purpose of baseline plugin is to ensure that any change in api get 
> reflected in exported version of the package. Currently the baseline plugin 
> compares against the immediate previous version. 
> This causes issue with unstable branches where new features are being 
> implemented and which evolve over few minor release on the trunk. In such 
> cases its possible that a new method expose in 1.7.1 gets removed later in 
> 1.7.2 (as happened in OAK-6337).
> It would be better to configure baseline plugin to check against releases 
> from stable branch so that we can ensure that package versions are properly 
> aligned against stable versions



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5787) BlobStore should be Closeable

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5787:
--
Fix Version/s: (was: 1.12.0)

> BlobStore should be Closeable
> -
>
> Key: OAK-5787
> URL: https://issues.apache.org/jira/browse/OAK-5787
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob
>Reporter: Julian Reschke
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.14.0
>
>
> {{DocumentNodeStore}} currently calls {{close()}} if the blob store instance 
> implements {{Closeable}}.
> This has led to problems where wrapper implementations did not implement it, 
> and thus the actual blob store instance wasn't properly shut down.
> Proposal: make {{BlobStore}} extend {{Closeable}} and get rid of all 
> {{instanceof}} checks.
> [~tmueller] [~amitjain] - feedback appreciated.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5739) Misleading traversal warning for spellcheck queries without index

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5739:
--
Fix Version/s: (was: 1.12.0)

> Misleading traversal warning for spellcheck queries without index
> -
>
> Key: OAK-5739
> URL: https://issues.apache.org/jira/browse/OAK-5739
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-4313 we avoid traversal for native queries, but we see in some cases 
> traversal warnings as follows:
> {noformat}
> org.apache.jackrabbit.oak.query.QueryImpl query plan 
> [nt:base] as [a] /* traverse "" where (spellcheck([a], 'NothingToFind')) 
> and (issamenode([a], [/])) */
> org.apache.jackrabbit.oak.query.QueryImpl Traversal query (query without 
> index): 
> select [jcr:path], [jcr:score], [rep:spellcheck()] from [nt:base] as a where 
> spellcheck('NothingToFind') 
> and issamenode(a, '/') 
> /* xpath: /jcr:root
> [rep:spellcheck('NothingToFind')]/(rep:spellcheck()) */; 
> consider creating an index
> {noformat}
> This warning is misleading. If no index is available, then either the query 
> should fail, or the warning should say that the query result is not correct 
> because traversal is used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-1838) NodeStore API: divergence in contract and implementations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-1838:
--
Fix Version/s: (was: 1.12.0)

> NodeStore API: divergence in contract and implementations
> -
>
> Key: OAK-1838
> URL: https://issues.apache.org/jira/browse/OAK-1838
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Assignee: Marcel Reutegger
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently there is a gap between what the API mandates and what the document 
> and kernel node stores implement. This hinders further evolution of the Oak 
> stack as implementers must always be aware of non explicit design 
> requirements. We should look into ways we could close this gap by bringing 
> implementation and specification closer towards each other. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6911) Provide a way to tune inline size while storing binaries

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6911:
--
Fix Version/s: (was: 1.12.0)

> Provide a way to tune inline size while storing binaries
> 
>
> Key: OAK-6911
> URL: https://issues.apache.org/jira/browse/OAK-6911
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: performance, scalability
> Fix For: 1.14.0
>
>
> SegmentNodeStore currently inlines binaries of size less that 16KB 
> (Segment.MEDIUM_LIMIT) even if external BlobStore is configured. 
> Due to this behaviour quite a bit of segment tar storage consist of blob 
> data. In one setup out of 370 GB segmentstore size 290GB is due to inlined 
> binary. If most of this binary content is moved to BlobStore then it would 
> allow same repository to work better in lesser RAM
> So it would be useful if some way is provided to disable this default 
> behaviour and let BlobStore take control of inline size i.e. in presence of 
> BlobStore no inlining is attempted by SegmentWriter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5990) Add properties filtering support to OakEventFilter

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5990:
--
Fix Version/s: (was: 1.12.0)

> Add properties filtering support to OakEventFilter
> --
>
> Key: OAK-5990
> URL: https://issues.apache.org/jira/browse/OAK-5990
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.6.1
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.14.0
>
>
> SLING-6164 introduced a _property name hint_ which, when set, allows to limit 
> the observation events to only include those that affect at least one of the 
> those properties listed. The advantage is to be further able to reduce the 
> events sent out. This feature has not yet been implemented on the oak side. 
> Thus we should add this to the OakEventFilter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4614) Collection of observation resilience issues

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4614:
--
Fix Version/s: 1.14.0

> Collection of observation resilience issues
> ---
>
> Key: OAK-4614
> URL: https://issues.apache.org/jira/browse/OAK-4614
> Project: Jackrabbit Oak
>  Issue Type: Epic
>  Components: core, documentmk, jcr
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.12.0, 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7321) Test failure: DocumentNodeStoreIT.modifiedResetWithDiff

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7321:
--
Fix Version/s: (was: 1.12.0)

> Test failure: DocumentNodeStoreIT.modifiedResetWithDiff
> ---
>
> Key: OAK-7321
> URL: https://issues.apache.org/jira/browse/OAK-7321
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: continuous integration, documentmk
>Reporter: Hudson
>Priority: Major
> Fix For: 1.14.0
>
>
> No description is provided
> The build Jackrabbit Oak #1295 has failed.
> First failed run: [Jackrabbit Oak 
> #1295|https://builds.apache.org/job/Jackrabbit%20Oak/1295/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1295/console]
> {noformat}
> org.apache.jackrabbit.oak.plugins.document.DocumentStoreException: Configured 
> cluster node id 1 already in use: machineId/instanceId do not match: 
> mac:0242454078e1//home/jenkins/jenkins-slave/workspace/Jackrabbit 
> Oak/oak-store-document != 
> mac:0242d5bcc8f8//home/jenkins/jenkins-slave/workspace/Jackrabbit 
> Oak/oak-store-document
>   at 
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff(DocumentNodeStoreIT.java:65)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7193) DataStore: API to retrieve statistic (file headers, size estimation)

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7193:
--
Fix Version/s: (was: 1.12.0)

> DataStore: API to retrieve statistic (file headers, size estimation)
> 
>
> Key: OAK-7193
> URL: https://issues.apache.org/jira/browse/OAK-7193
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Extension of OAK-6254: in addition to retrieving the size, it would be good 
> to retrieve the estimated number and total size per file type. A simple (and 
> in my view sufficient) solution is to use the first few bytes ("magic 
> numbers", 2 bytes should be enough) to get the file type. That would allow to 
> estimate, for example, the number of, and total size, of PDF files, JPEG, 
> Lucene index and so on. A histogram would be nice as well, but I think is not 
> needed.
> To speed up calculation, the blob ID could be extended with the first 2 bytes 
> of the file content, that is: #@ where magic is the 
> first two bytes, in hex. That would allow to quickly get the data from the 
> blob ids (no need to actually read content).
> Sampling should be enough. The longer it takes, the more accurate the data. 
> We could store the data while doing datastore GC, in which case the returned 
> data would be somewhat stale; that's OK.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6759) Convert oak-blob-cloud-azure to OSGi R6 annotations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6759:
--
Fix Version/s: (was: 1.12.0)

> Convert oak-blob-cloud-azure to OSGi R6 annotations
> ---
>
> Key: OAK-6759
> URL: https://issues.apache.org/jira/browse/OAK-6759
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: blob-cloud
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7254) Indexes with excludedPaths, or includedPaths should not be picked for queries without path

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7254:
--
Fix Version/s: (was: 1.12.0)

> Indexes with excludedPaths, or includedPaths should not be picked for queries 
> without path
> --
>
> Key: OAK-7254
> URL: https://issues.apache.org/jira/browse/OAK-7254
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene, query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> Queries that don't have a clear path restriction should not use indexes that 
> have excludedPaths or includedPaths set, except in some exceptional cases (to 
> be defined).
> For example, if a query doesn't have a path restriction, say:
> {noformat}
> /jcr:root//element(*, nt:base)[@status='RUNNING']
> {noformat}
> Then an index that has excludedPaths set (for example to /etc) shouldn't be 
> used, at least not if a different index is available. Currently it is used 
> currently, actually in _favor_ of another index, if the property "status" is 
> commonly used in /etc. Because of that, the index that doesn't have 
> excludedPath has a higher cost (as it indexes the property "status" in /etc, 
> and so has more entries for "status", than the index that doesn't index /etc).
> The same for includedPaths, in case queryPaths isn't set to the same value(s).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6387) Building an index (new index + reindex): temporarily store blob references

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6387:
--
Fix Version/s: (was: 1.12.0)

> Building an index (new index + reindex): temporarily store blob references
> --
>
> Key: OAK-6387
> URL: https://issues.apache.org/jira/browse/OAK-6387
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene, query
>Reporter: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> If reindexing a Lucene index takes multiple days, and if datastore garbage 
> collection (DSGC) is run during that time, then DSGC may remove binaries of 
> that index because they are not referenced.
> It would be good if all binaries that are needed, and that are older than 
> (for example) one hour, are referenced during reindexing (for example in a 
> temporary location). So that DSGC will not remove them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5927) Load excerpt lazily

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5927:
--
Fix Version/s: (was: 1.12.0)

> Load excerpt lazily
> ---
>
> Key: OAK-5927
> URL: https://issues.apache.org/jira/browse/OAK-5927
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: performance
> Fix For: 1.14.0
>
>
> Currently LucenePropertyIndex loads the excerpt eagerly in batch as part of 
> loadDocs call. The load docs batch size doubles starting from 50 (max 100k) 
> as more data is read. 
> We should look into ways to make the excerpt loaded lazily as and when caller 
> ask for excerpt.
> Note that currently the excerpt are only loaded when query request for 
> excerpt i.e. there is a not null property restriction for {{rep:excerpt}}. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5860) Compressed segments

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5860:
--
Fix Version/s: (was: 1.12.0)

> Compressed segments
> ---
>
> Key: OAK-5860
> URL: https://issues.apache.org/jira/browse/OAK-5860
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: scalability
> Fix For: 1.14.0
>
>
> It would be interesting to see the effect of compressing the segments within 
> the tar files with a sufficiently effective and performant compression 
> algorithm:
> * Can we increase overall throughput by trading CPU for IO?
> * Can we scale to bigger repositories (in number of nodes) by squeezing in 
> more segments per MB and thus pushing out onset of thrashing?
> * What would be a good compression algorithm/library?
> * Can/should we make this optional? 
> * Migration and compatibility issues?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7358) Remove all usage of java.security.acl.Group for Java 13

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7358:
--
Fix Version/s: (was: 1.12.0)

> Remove all usage of java.security.acl.Group for Java 13
> ---
>
> Key: OAK-7358
> URL: https://issues.apache.org/jira/browse/OAK-7358
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.14.0
>
>
> Followup of OAK-7024 for the actual removal of the Group class from the 
> codebase to be java 11 compliant.
> Not sure what to use for 'fix version', I went with 1.9.0 so this remains on 
> the radar, but we can push it out as needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5980) Bad Join Query Plan Used

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5980:
--
Fix Version/s: (was: 1.12.0)

> Bad Join Query Plan Used
> 
>
> Key: OAK-5980
> URL: https://issues.apache.org/jira/browse/OAK-5980
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> For a join query, where selectors are joined over ischildnode but also can 
> use an index,
> the selectors sometimes use the index instead of the much less
> expensive parent join. Example:
> {noformat}
> select [a].* from [nt:unstructured] as [a]
> inner join [nt:unstructured] as [b] on ischildnode([b], [a]) 
> inner join [nt:unstructured] as [c] on ischildnode([c], [b]) 
> inner join [nt:unstructured] as [d] on ischildnode([d], [c]) 
> inner join [nt:unstructured] as [e] on ischildnode([e], [d]) 
> where [a].[classname] = 'letter' 
> and isdescendantnode([a], '/content') 
> and [c].[classname] = 'chapter' 
> and localname([b]) = 'chapters' 
> and [e].[classname] = 'list' 
> and localname([d]) = 'lists' 
> and [e].[path] = cast('/content/abc' as path)
> {noformat}
> The order of selectors is sometimes wrong (not e, d, c, b, a), but
> more importantly, selectors c and a use the index on className.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3219) Lucene IndexPlanner should also account for number of property constraints evaluated while giving cost estimation

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3219:
--
Fix Version/s: (was: 1.12.0)

> Lucene IndexPlanner should also account for number of property constraints 
> evaluated while giving cost estimation
> -
>
> Key: OAK-3219
> URL: https://issues.apache.org/jira/browse/OAK-3219
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Minor
>  Labels: performance
> Fix For: 1.14.0
>
>
> Currently the cost returned by Lucene index is a function of number of 
> indexed documents present in the index. If the number of indexed entries are 
> high then it might reduce chances of this index getting selected if some 
> property index also support of the property constraint.
> {noformat}
> /jcr:root/content/freestyle-cms/customers//element(*, cq:Page)
> [(jcr:content/@title = 'm' or jcr:like(jcr:content/@title, 'm%')) 
> and jcr:content/@sling:resourceType = '/components/page/customer’]
> {noformat}
> Consider above query with following index definition
> * A property index on resourceType
> * A Lucene index for cq:Page with properties {{jcr:content/title}}, 
> {{jcr:content/sling:resourceType}} indexed and also path restriction 
> evaluation enabled
> Now what the two indexes can help in
> # Property index
> ## Path restriction
> ## Property restriction on  {{sling:resourceType}}
> # Lucene index
> ## NodeType restriction
> ## Property restriction on  {{sling:resourceType}}
> ## Property restriction on  {{title}}
> ## Path restriction
> Now cost estimate currently works like this
> * Property index - {{f(indexedValueEstimate, estimateOfNodesUnderGivenPath)}}
> ** indexedValueEstimate - For 'sling:resourceType=foo' its the approximate 
> count for nodes having that as 'foo'
> ** estimateOfNodesUnderGivenPath - Its derived from an approximate estimation 
> of nodes present under given path
> * Lucene Index - {{f(totalIndexedEntries)}}
> As cost of Lucene is too simple it does not reflect the reality. Following 2 
> changes can be done to make it better
> * Given that Lucene index can handle multiple constraints compared (4) to 
> property index (2), the cost estimate returned by it should also reflect this 
> state. This can be done by setting costPerEntry to 1/(no of property 
> restriction evaluated)
> * Get the count for queried property value - This is similar to what 
> PropertyIndex does and assumes that Lucene can provide that information in 
> O(1) cost. In case of multiple supported property restriction this can be 
> minima of all



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4643) Support multiple readers in suggester, spellcheck and faceted search

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4643:
--
Fix Version/s: (was: 1.12.0)

> Support multiple readers in suggester, spellcheck and faceted search
> 
>
> Key: OAK-4643
> URL: https://issues.apache.org/jira/browse/OAK-4643
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> As part of OAK-4566 normal search has been modified to support multiple 
> readers. However for suggester, spellcheck and faceted search the logic is 
> still working with the assumption of single reader. 
> Those parts need to be adapted to support multiple readers



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5272) Expose BlobStore API to provide information whether blob id is content hashed

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5272:
--
Fix Version/s: (was: 1.12.0)

> Expose BlobStore API to provide information whether blob id is content hashed
> -
>
> Key: OAK-5272
> URL: https://issues.apache.org/jira/browse/OAK-5272
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob
>Reporter: Amit Jain
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> As per discussion in OAK-5253 it's better to have some information from the 
> BlobStore(s) whether the blob id can be solely relied upon for comparison.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7423) Document the proc tree

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7423:
--
Fix Version/s: (was: 1.12.0)

> Document the proc tree
> --
>
> Key: OAK-7423
> URL: https://issues.apache.org/jira/browse/OAK-7423
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
>  Labels: technical_debt
> Fix For: 1.14.0
>
>
> The proc tree, contributed in OAK-7416, lacks Javadoc and high-level 
> documentation. In particular, the exposed content structure should be 
> described in greater detail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3150) Update Lucene to 6.x series

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3150:
--
Fix Version/s: (was: 1.12.0)

> Update Lucene to 6.x series
> ---
>
> Key: OAK-3150
> URL: https://issues.apache.org/jira/browse/OAK-3150
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: technical_debt
> Fix For: 1.14.0
>
>
> We should look into updating the Lucene version to 6.x. Java 8 is the minimum 
> Java version required
> Note this is to be done for trunk only



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5917) Document enhancements in indexing in 1.6

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5917:
--
Fix Version/s: (was: 1.12.0)

> Document enhancements in indexing in 1.6
> 
>
> Key: OAK-5917
> URL: https://issues.apache.org/jira/browse/OAK-5917
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: doc
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> This task is meant to collect and refer work done in 1.6 release which needs 
> to be documented in Oak docs.
> Issues in lucene and query area 
> [jql|https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20fixVersion%20%3D%201.6.0%20and%20component%20in%20(lucene%2C%20query)%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC]
> Topics to cover
> * OAK-4412 - Lucene Hybrid Index (/)
> * OAK-4939 - Isolation of corrupted index  (/)
> * OAK-4974 - Enable configuring QueryEngineSettings via OSGi config 
> * OAK-3574 - Function based indexes
> * OAK-4400 - Correlate index with the index definition used to build it  (/)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5367) Strange path parsing

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5367:
--
Fix Version/s: (was: 1.12.0)

> Strange path parsing
> 
>
> Key: OAK-5367
> URL: https://issues.apache.org/jira/browse/OAK-5367
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: JcrPathParserTest.java
>
>
> Incorrect handling of path with "\{" was fixed in OAK-5260, but the behavior 
> of the JcrPathParser is still strange. For example:
> * the root node, "/", is mapped to "/", and the current node, "." is mapped 
> to "". But "/." is mapped to the current node (should be root node).
> * "/parent/./childA2" is mapped to "/parent/childA2" (which is fine), but 
> "/parent/.}/childA2" is also mapped to "/parent/childA2".
> * "\}\{" and "}\[" and "}}[" are mapped to the current node. So are ".[" and 
> "/[" and ".}". And "}\{test" is mapped to "}\{test", which is 
> inconsistent-weird.
> * "x\[1\]}" is mapped to "x".
> All that weirdness should be resolved. Some seem to be just weird, but some 
> look like they could become a problem at some point ("}\{").



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7263) oak-lucene should not depend on oak-store-document

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7263:
--
Fix Version/s: (was: 1.12.0)

> oak-lucene should not depend on oak-store-document
> --
>
> Key: OAK-7263
> URL: https://issues.apache.org/jira/browse/OAK-7263
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>
> {{oak-lucene}} has a hard dependency on {{oak-store-document}} and that looks 
> wrong to me. 
> {noformat}[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile 
> (default-compile) on project oak-lucene: Compilation failure: Compilation 
> failure: 
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[31,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneDocumentHolder.java:[37,46]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[33,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[34,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[38,47]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[106,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalProperty
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyBuilder
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java:[55,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[29,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/IndexedPaths.java:[33,31]
>  cannot find symbol
> [ERROR]   symbol: class JournalProperty
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[22,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[23,54]
>  package org.apache.jackrabbit.oak.plugins.document.spi does not exist
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[25,54]
>  cannot find symbol
> [ERROR]   symbol: class JournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyService.java:[33,12]
>  cannot find symbol
> [ERROR]   symbol:   class JournalPropertyBuilder
> [ERROR]   location: class 
> org.apache.jackrabbit.oak.plugins.index.lucene.hybrid.LuceneJournalPropertyService
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[50,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> /home/robert/Documents/sources/apache/jackrabbit-oak/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/hybrid/LuceneJournalPropertyBuilder.java:[61,5]
>  method does not override or implement a method from a supertype
> [ERROR] 
> 

[jira] [Updated] (OAK-7754) Option to disable BlobTracker

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7754:
--
Fix Version/s: (was: 1.12.0)

> Option to disable BlobTracker
> -
>
> Key: OAK-7754
> URL: https://issues.apache.org/jira/browse/OAK-7754
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob-plugins
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.14.0
>
>
> Enable an option to disable blob tracker completely for deployments where 
> DSGC is explicitly disabled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3658) Test failures: JackrabbitNodeTest#testRename and testRenameEventHandling

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3658:
--
Fix Version/s: (was: 1.12.0)

> Test failures: JackrabbitNodeTest#testRename and testRenameEventHandling
> 
>
> Key: OAK-3658
> URL: https://issues.apache.org/jira/browse/OAK-3658
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: jcr
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Minor
> Fix For: 1.14.0
>
>
> Tests fail regularly on trunk - {{JackrabbitNodeTest#testRename}} and 
> {{JackrabbitNodeTest#testRenameEventHandling}}.
> {noformat}
> Test set: org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest
> ---
> Tests run: 8, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.106 sec <<< 
> FAILURE!
> testRenameEventHandling(org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest)  
> Time elapsed: 0.01 sec  <<< ERROR!
> javax.jcr.nodetype.ConstraintViolationException: Item is protected.
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl$ItemWriteOperation.checkPreconditions(ItemImpl.java:98)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:270)
>   at 
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.rename(NodeImpl.java:1485)
>   at 
> org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRenameEventHandling(JackrabbitNodeTest.java:124)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at 
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
>   at 
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> testRename(org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest)  Time elapsed: 
> 0.007 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[a]> but was:<[rep:policy]>
>   at junit.framework.Assert.assertEquals(Assert.java:100)
>   at junit.framework.Assert.assertEquals(Assert.java:107)
>   at junit.framework.TestCase.assertEquals(TestCase.java:269)
>   at 
> org.apache.jackrabbit.oak.jcr.JackrabbitNodeTest.testRename(JackrabbitNodeTest.java:74)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at 

[jira] [Updated] (OAK-3919) Properly manage APIs / SPIs intended for public consumption

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3919:
--
Fix Version/s: (was: 1.12.0)

> Properly manage APIs / SPIs intended for public consumption
> ---
>
> Key: OAK-3919
> URL: https://issues.apache.org/jira/browse/OAK-3919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core
>Reporter: Michael Dürig
>Priority: Major
>  Labels: modularization, technical_debt
> Fix For: 1.14.0
>
>
> This is a follow up to OAK-3842, which removed package export declarations 
> for all packages that we either do not want to be used outside of Oak or that 
> are not stable enough yet. 
> This issue is to identify those APIs and SPIs of Oak that we actually *want* 
> to export and to refactor those such we *can* export them. 
> Candidates that are currently used from upstream projects I know of are:
> {code}
>   org.apache.jackrabbit.oak.plugins.observation
>   org.apache.jackrabbit.oak.spi.commit
>   org.apache.jackrabbit.oak.spi.state
>   org.apache.jackrabbit.oak.commons
>   org.apache.jackrabbit.oak.plugins.index.lucene
> {code}
> I suggest to create subtask for those we want to go forward with.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4760) Adjust default timeout values for RDBDocumentStore

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4760:
--
Fix Version/s: (was: 1.12.0)

> Adjust default timeout values for RDBDocumentStore
> --
>
> Key: OAK-4760
> URL: https://issues.apache.org/jira/browse/OAK-4760
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: core, rdbmk
>Reporter: Marcel Reutegger
>Assignee: Julian Reschke
>Priority: Minor
>  Labels: resilience
> Fix For: 1.14.0
>
>
> Some default values timeouts of the RDBDocumentStore driver do not work well 
> with the lease time we use in Oak.
> See also OAK-4739.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6421) Phase out JCR Locking support

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6421:
--
Fix Version/s: (was: 1.12.0)

> Phase out JCR Locking support
> -
>
> Key: OAK-6421
> URL: https://issues.apache.org/jira/browse/OAK-6421
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: jcr
>Reporter: Marcel Reutegger
>Priority: Major
> Fix For: 1.14.0
>
>
> Oak currently has a lot of gaps in its JCR Locking implementation (see 
> OAK-1962), which basically makes it non-compliant with the JCR specification.
> I propose we phase out the support for JCR Locking because a proper 
> implementation would be rather complex with a runtime behaviour that is very 
> different in a standalone deployment compared to a cluster. In the standalone 
> case a lock could be acquired very quickly, while in the distributed case, 
> the operations would be multiple orders of magnitude slower, depending on how 
> cluster nodes are geographically distributed.
> Applications that rely on strict lock semantics should use other mechanisms, 
> built explicitly for this purpose. E.g. Apache Zookeeper.
> To ease upgrade and migration to a different lock mechanism, the proposal is 
> to introduce a flag or configuration that controls the level of support for 
> JCR Locking:
> - DISABLED: the implementation does not support JCR Locking at all. Methods 
> will throw UnsupportedRepositoryOperationException when defined by the JCR 
> specification. 
> - DEPRECATED: the implementation behaves as right now, but logs a warn or 
> error message that JCR Locking does not work as specified and will be removed 
> in a future version of Oak.
> In a later release (e.g. 1.10) the current JCR Locking implementation would 
> be removed entirely and unconditionally throw an exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7212) Document the document order traversal option

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7212:
--
Fix Version/s: (was: 1.12.0)

> Document the document order traversal option
> 
>
> Key: OAK-7212
> URL: https://issues.apache.org/jira/browse/OAK-7212
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Document the doc-order-traversal option introduced with OAK-6353



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6412) Consider upgrading to newer Lucene versions

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6412:
--
Fix Version/s: (was: 1.12.0)

> Consider upgrading to newer Lucene versions
> ---
>
> Key: OAK-6412
> URL: https://issues.apache.org/jira/browse/OAK-6412
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> An year ago I had started prototyping the upgrade to Lucene 5 [1], in the 
> meantime version 6 (and 7 soon) has come out.
> I think it'd be very nice to upgrade Lucene version to the latest, this would 
> give us improvements in space consumption and runtime performance.
> In case we want to upgrade to 6.0 or later we need to consider upgrade 
> scenarios because Lucene Codecs are backward compatible with the previous 
> major release, so Lucene 6 can read Lucene 5 but not Lucene 4.x (4.7 in our 
> case) therefore we would need to detect that when reading an index and 
> trigger reindexing using the new format.
> Related to that there's also a patch to upgrade Solr index to version 5 (see 
> OAK-4318).
> [1] : https://github.com/tteofili/jackrabbit-oak/tree/lucene5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5369) Lucene Property Index: Syntax Error, cannot parse

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5369:
--
Fix Version/s: (was: 1.12.0)

> Lucene Property Index: Syntax Error, cannot parse
> -
>
> Key: OAK-5369
> URL: https://issues.apache.org/jira/browse/OAK-5369
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: lucene
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> The following query throws an exception in Apache Lucene:
> {noformat}
> /jcr:root//*[jcr:contains(., 'hello -- world')]
> 22.12.2016 16:42:54.511 *WARN* [qtp1944702753-3846] 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex query via 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex@1c0006db 
> failed.
> java.lang.RuntimeException: INVALID_SYNTAX_CANNOT_PARSE: Syntax Error, cannot 
> parse hello -- world:  
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1450)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.tokenToQuery(LucenePropertyIndex.java:1418)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$900(LucenePropertyIndex.java:180)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visitTerm(LucenePropertyIndex.java:1353)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$3.visit(LucenePropertyIndex.java:1307)
>   at 
> org.apache.jackrabbit.oak.query.fulltext.FullTextContains.accept(FullTextContains.java:63)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getFullTextQuery(LucenePropertyIndex.java:1303)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.getLuceneRequest(LucenePropertyIndex.java:791)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex.access$300(LucenePropertyIndex.java:180)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.loadDocs(LucenePropertyIndex.java:375)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:317)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$1.computeNext(LucenePropertyIndex.java:306)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor$1.hasNext(LucenePropertyIndex.java:1571)
>   at com.google.common.collect.Iterators$7.computeNext(Iterators.java:645)
>   at 
> com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
>   at 
> com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
>   at 
> org.apache.jackrabbit.oak.spi.query.Cursors$PathCursor.hasNext(Cursors.java:205)
>   at 
> org.apache.jackrabbit.oak.plugins.index.lucene.LucenePropertyIndex$LucenePathCursor.hasNext(LucenePropertyIndex.java:1595)
>   at 
> org.apache.jackrabbit.oak.query.ast.SelectorImpl.next(SelectorImpl.java:420)
>   at 
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.fetchNext(QueryImpl.java:828)
>   at 
> org.apache.jackrabbit.oak.query.QueryImpl$RowIterator.hasNext(QueryImpl.java:853)
>   at 
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.fetch(QueryResultImpl.java:98)
>   at 
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl$1.(QueryResultImpl.java:94)
>   at 
> org.apache.jackrabbit.oak.jcr.query.QueryResultImpl.getRows(QueryResultImpl.java:78)
> Caused by: 
> org.apache.lucene.queryparser.flexible.standard.parser.ParseException: Syntax 
> Error, cannot parse hello -- world:  
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.generateParseException(StandardSyntaxParser.java:1054)
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.jj_consume_token(StandardSyntaxParser.java:936)
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.Clause(StandardSyntaxParser.java:486)
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ModClause(StandardSyntaxParser.java:303)
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.ConjQuery(StandardSyntaxParser.java:234)
>   at 
> org.apache.lucene.queryparser.flexible.standard.parser.StandardSyntaxParser.DisjQuery(StandardSyntaxParser.java:204)
>   at 
> 

[jira] [Updated] (OAK-6769) Convert oak-search-mt to OSGi R6 annotations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6769:
--
Fix Version/s: (was: 1.12.0)

> Convert oak-search-mt to OSGi R6 annotations
> 
>
> Key: OAK-6769
> URL: https://issues.apache.org/jira/browse/OAK-6769
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7660) Refactor AzureCompact and Compact

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7660:
--
Fix Version/s: (was: 1.12.0)

> Refactor AzureCompact and Compact
> -
>
> Key: OAK-7660
> URL: https://issues.apache.org/jira/browse/OAK-7660
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
>  Labels: tech-debt, technical_debt, tooling
> Fix For: 1.14.0
>
>
> {{AzureCompact}} in {{oak-segment-azure}} follows closely the structure and 
> logic of {{Compact}} in {{oak-segment-tar}}. Since the only thing which 
> differs is the underlying persistence used (remote in Azure vs. local in TAR 
> files), the common logic should be extracted in a super-class, extended by 
> both. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7043) Collect SegmentStore stats as part of status zip

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7043:
--
Fix Version/s: (was: 1.12.0)

> Collect SegmentStore stats as part of status zip
> 
>
> Key: OAK-7043
> URL: https://issues.apache.org/jira/browse/OAK-7043
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: segment-tar
>Reporter: Chetan Mehrotra
>Priority: Major
>  Labels: monitoring, production
> Fix For: 1.14.0
>
>
> Many times while investigating issue we request customer to provide to size 
> of segmentstore and at times list of segmentstore directory. It would be 
> useful if there is an InventoryPrinter for SegmentStore which can include
> * Size of segment store 
> * Listing of segment store directory
> * Possibly tail of journal.log
> * Possibly some stats/info from index files stored in tar files



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4934) Query shapes for JCR Query

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4934:
--
Fix Version/s: (was: 1.12.0)

> Query shapes for JCR Query
> --
>
> Key: OAK-4934
> URL: https://issues.apache.org/jira/browse/OAK-4934
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: query
>Reporter: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> For certain requirements it would be good to have a notion/support to deduce 
> query shape [1]
> {quote}
>  A combination of query predicate, sort, and projection specifications.
> For the query predicate, only the structure of the predicate, including the 
> field names, are significant; the values in the query predicate are 
> insignificant. As such, a query predicate \{ type: 'food' \} is equivalent to 
> the query predicate \{ type: 'utensil' \} for a query shape.
> {quote}
> So transforming that to Oak the shape should represent a JCR-SQL2 query 
> string (xpath query gets transformed to SQL2) which is a *canonical* 
> representation of actual query ignoring the property restriction values. 
> Example we have 2 queries
> * SELECT   * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 
> 'published'
> * SELECT   * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 
> 'disabled'
> The query shape would be 
> SELECT * FROM [app:Asset] AS a WHERE  a.[jcr:content/metadata/status] = 'A'. 
> The plan for query having given shape would remain same irrespective of value 
> of property restrictions. Path restriction can cause some difference though
> The shape can then be used for
> * Stats Collection - Currently stats collection gets overflown if same query 
> with different value gets invoked
> * Allow configuring hints - See support in Mongo [2] for an example. One 
> specify via config that for a query of such and such shape this index should 
> be used
> * Less noisy diagnostics - If a query gets invoked with bad plan the QE can 
> log the warning once instead of logging it for each query invocation 
> involving different values.
> [1] https://docs.mongodb.com/manual/reference/glossary/#term-query-shape
> [2] https://docs.mongodb.com/manual/reference/command/planCacheSetFilter/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4814) Add orderby support for nodename index

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4814:
--
Fix Version/s: (was: 1.12.0)

> Add orderby support for nodename index
> --
>
> Key: OAK-4814
> URL: https://issues.apache.org/jira/browse/OAK-4814
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: query
>Affects Versions: 1.5.10
>Reporter: Ankush Malhotra
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.14.0
>
>
> In OAK-1752 you have implemented the index support for :nodeName. The JCR 
> Query explain tool shows that it is used for conditions like equals.
> But it is not used for ORDER BY name() .
> Is name() supported in order by clause? If yes then we would need to add 
> support for that in oak-lucene



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3336:
--
Fix Version/s: (was: 1.12.0)

> Abstract a full text index implementation to be extended by Lucene and Solr
> ---
>
> Key: OAK-3336
> URL: https://issues.apache.org/jira/browse/OAK-3336
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene, query, solr
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Current Lucene and Solr indexes implement quite a no. of features according 
> to their specific APIs, design and implementation. However in the long run, 
> while differences in APIs and implementations will / can of course stay, the 
> difference in design can make it hard to keep those features on par.
> It'd be therefore nice to make it possible to abstract as much of design and 
> implementation bits as possible in an abstract full text implementation which 
> Lucene and Solr would extend according to their specifics.
> An example advantage of this is that index time aggregation will be 
> implemented only once and therefore any bugfixes and improvements in that 
> area will be done in the abstract implementation rather than having to do 
> that in two places.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3717) Make it possible to declare SynonymFilter within Analyzer with WN dictionary

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3717:
--
Fix Version/s: (was: 1.12.0)

> Make it possible to declare SynonymFilter within Analyzer with WN dictionary
> 
>
> Key: OAK-3717
> URL: https://issues.apache.org/jira/browse/OAK-3717
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently one can compose Lucene Analyzers via 
> [composition|http://jackrabbit.apache.org/oak/docs/query/lucene.html#Create_analyzer_via_composition]
>  within an index definition. It'd be good to be able to also use 
> {{SynonymFIlter}} in there, eventually decorated with 
> {{WordNetSynonymParser}} to leverage WordNet synonym files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5897) Optimize like constraint support in Property Indexes

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5897:
--
Fix Version/s: (was: 1.12.0)

> Optimize like constraint support in Property Indexes
> 
>
> Key: OAK-5897
> URL: https://issues.apache.org/jira/browse/OAK-5897
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: property-index
>Reporter: Chetan Mehrotra
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Consider a query
> {noformat}
>  /jcr:root/content//element(*, nt:unstructured)[jcr:like(@resource, 
> '/content/foo/bar%')]
> {noformat}
> This currently gets translated into a range property restriction 
> {noformat}
>  property=[resource=[[/content/foo/bar.., ../content/foo/bas]]]
> {noformat}
> For such a query property index currently returns all nodes having "resource" 
> property i.e. all index data. This can be optimized to return only those 
> nodes where indexed value qualifies the range property restriction



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7207) Define porcelain and plumbing tools for the Segment Store

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7207:
--
Fix Version/s: (was: 1.12.0)

> Define porcelain and plumbing tools for the Segment Store
> -
>
> Key: OAK-7207
> URL: https://issues.apache.org/jira/browse/OAK-7207
> Project: Jackrabbit Oak
>  Issue Type: Wish
>  Components: segment-tar
>Reporter: Francesco Mari
>Priority: Major
>  Labels: production, tooling
> Fix For: 1.14.0
>
>
> In a spirit similar to 
> [Git|https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain]'s, 
> it would be beneficial to create porcelain and plumbing tooling for the 
> Segment Store.
> Plumbing tools expose lower level operations on the Segment Store. Knowledge 
> about the internals of the Segment Store is necessary to understand how 
> plumbing tools work. Plumbing tools communicate via a command line interface. 
> It must be easy to invoke plumbing tools from other tools (possibly by 
> shelling out). The output of plumbing tools must be easy to consume 
> programmatically.
> Porcelain tools are written for human consumption. Their interface must be 
> user-friendly and should be as much as possible backwards compatible. 
> Porcelain tools use plumbing ones to implement their features. It should be 
> possible to use the same porcelain tools with different versions of the 
> plumbing tools, as long as the plumbing tools "speak" through an interface 
> that remain sufficiently compatible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7372) Update FileDataStore recommendation

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7372:
--
Fix Version/s: (was: 1.12.0)

> Update FileDataStore recommendation
> ---
>
> Key: OAK-7372
> URL: https://issues.apache.org/jira/browse/OAK-7372
> Project: Jackrabbit Oak
>  Issue Type: Documentation
>  Components: doc
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> The BlobStore documentation currently mentions use of a FileDataStore only 
> for deployments when the data store is shared between multiple repository 
> instances. The documentation should be updated to also recommend the 
> FileDataStore when a repository has many binaries.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5144) use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5144:
--
Fix Version/s: (was: 1.12.0)

> use 'allNodeTypes' of ChangeSet for nodeType-aggregate-filter
> -
>
> Key: OAK-5144
> URL: https://issues.apache.org/jira/browse/OAK-5144
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: jcr
>Affects Versions: 1.5.14
>Reporter: Stefan Egli
>Priority: Major
> Fix For: 1.14.0
>
>
> With OAK-4940 the ChangeSet now contains all node types up to root that are 
> related to a change. This fact could be used by the nodeType-aggregate-filter 
> (OAK-5021), which would likely speed up this type of filter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5924) Prevent long running query from delaying refresh of index

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5924:
--
Fix Version/s: (was: 1.12.0)

> Prevent long running query from delaying refresh of index
> -
>
> Key: OAK-5924
> URL: https://issues.apache.org/jira/browse/OAK-5924
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
>
> Whenever the index gets updated {{IndexTracker}} detects the changes and open 
> new {{IndexNode}} and closes old index nodes. This flow would block untill 
> all old IndexNode are closed.
> IndexNode close itself relies on a writer lock. It can happen that a long 
> running query i.e. a query which is about to read a page of large is 
> currently executing on the old IndexNode instance. This query is trying load 
> 100k  docs and is very slow (due to loading of excerpt) then such a query 
> would prevent the IndexNode from getting closed. This in turn would prevent 
> the index from seeing latest data and become stale.
> To make query and indexing more resilient we should look if current IndexNode 
> being used for query is closing or not. If closing then query should open a 
> fresh searcher



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5655) TarMK: Analyse locality of reference

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5655:
--
Fix Version/s: (was: 1.12.0)

> TarMK: Analyse locality of reference 
> -
>
> Key: OAK-5655
> URL: https://issues.apache.org/jira/browse/OAK-5655
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: segment-tar
>Reporter: Michael Dürig
>Priority: Major
>  Labels: scalability
> Fix For: 1.14.0
>
> Attachments: compaction-time-vs-reposize.m, 
> compaction-time-vs.reposize.png, data00053a.tar-reads.png, offrc.jfr, 
> segment-per-path-compacted-nocache.png, 
> segment-per-path-compacted-nostringcache.png, segment-per-path-compacted.png, 
> segment-per-path.png, segment-reads.png
>
>
> We need to better understand the locality aspects of content stored in TarMK: 
> * How is related content spread over segments?
> * What content do we consider related? 
> * How does locality of related content develop over time when changes are 
> applied?
> * What changes do we consider typical?
> * What is the impact of compaction on locality? 
> * What is the impact of the deduplication caches on locality (during normal 
> operation and during compaction)?
> * How good are checkpoints deduplicated? Can we monitor this online?
> * ...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5706) Function based indexes with "like" conditions

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5706:
--
Fix Version/s: (was: 1.12.0)

> Function based indexes with "like" conditions
> -
>
> Key: OAK-5706
> URL: https://issues.apache.org/jira/browse/OAK-5706
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: indexing
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently, a function-based index is not used when using "like" conditions, 
> as follows:
> {noformat}
> /jcr:root//*[jcr:like(fn:lower-case(fn:name()), 'abc%')]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6768) Convert oak-remote to OSGi R6 annotations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6768:
--
Fix Version/s: (was: 1.12.0)

> Convert oak-remote to OSGi R6 annotations
> -
>
> Key: OAK-6768
> URL: https://issues.apache.org/jira/browse/OAK-6768
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: remoting
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3355) Test failure: SpellcheckTest.testSpellcheckMultipleWords

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3355:
--
Fix Version/s: (was: 1.12.0)

> Test failure: SpellcheckTest.testSpellcheckMultipleWords
> 
>
> Key: OAK-3355
> URL: https://issues.apache.org/jira/browse/OAK-3355
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
>Affects Versions: 1.0.24
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.14.0
>
>
> {{org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords}}
>  fails on Jenkins.
> Failure seen at builds: 389, 392, 395, 396, 562
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/396/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console
> {noformat}
> testSpellcheckMultipleWords(org.apache.jackrabbit.oak.jcr.query.SpellcheckTest)
>   Time elapsed: 0.907 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected:<[voting[ in] ontario]> but 
> was:<[voting[, voted,] ontario]>
>   at junit.framework.Assert.assertEquals(Assert.java:85)
>   at junit.framework.Assert.assertEquals(Assert.java:91)
>   at 
> org.apache.jackrabbit.oak.jcr.query.SpellcheckTest.testSpellcheckMultipleWords(SpellcheckTest.java:86)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7224) oak-run check should have an option to check the segments checksums

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7224:
--
Fix Version/s: (was: 1.12.0)

> oak-run check should have an option to check the segments checksums
> ---
>
> Key: OAK-7224
> URL: https://issues.apache.org/jira/browse/OAK-7224
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Minor
>  Labels: tooling
> Fix For: 1.14.0
>
>
> {{oak-run check}} does currently *not* check the checksums of the segments. 
> As a consequence, there is no quick way of determining the state of the 
> repository (corrupt/valid), after corrupting some random node record, as we 
> currently do in {{CheckRepositoryTestBase#corruptRecord}}. To determine that, 
> there needs to be an attempt to read the corrupt record as part of a 
> traversal.
> An easier way would be to have a new dedicated option for this (i.e., 
> {{--segments}}) which checks by default the content of segments against the 
> checksums from all the tar files in the specified location. Additionally, it 
> could accept as an argument a list of tar files, the segments of which to be 
> checked.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7684) fix maven warnings on oak-solr-osgi

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7684:
--
Fix Version/s: (was: 1.12.0)

> fix maven warnings on oak-solr-osgi
> ---
>
> Key: OAK-7684
> URL: https://issues.apache.org/jira/browse/OAK-7684
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: solr
>Reporter: Julian Reschke
>Assignee: Tommaso Teofili
>Priority: Minor
> Fix For: 1.14.0
>
>
> {noformat}
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/InStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/io/OutStream
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/CoordinateSequenceFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> NoClassDefFoundError: com/vividsolutions/jts/geom/GeometryFilter
> [WARNING] Bundle org.apache.jackrabbit:oak-solr-osgi:bundle:1.10-SNAPSHOT : 
> Unused Import-Package instructions: [com.sun.*]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7691) Remove deprecated ValueFactoryImpl methods

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7691:
--
Fix Version/s: (was: 1.12.0)

> Remove deprecated ValueFactoryImpl methods
> --
>
> Key: OAK-7691
> URL: https://issues.apache.org/jira/browse/OAK-7691
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: store-spi
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> The deprecated static methods on ValueFactoryImpl are not used anymore and 
> can be removed. See also OAK-7688.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7457) "Covariant return type change detected" warnings with java10

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7457:
--
Fix Version/s: (was: 1.12.0)

> "Covariant return type change detected" warnings with java10
> 
>
> Key: OAK-7457
> URL: https://issues.apache.org/jira/browse/OAK-7457
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: documentmk, segment-tar
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
> Fix For: 1.14.0
>
>
> We have quite a few warnings of type "Covariant return type change detected":
> {noformat}
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\TCPBroadcaster.java:327:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.flip() has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.flip()
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\UDPBroadcaster.java:135:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.limit(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\UDPBroadcaster.java:138:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\TCPBroadcaster.java:226:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\broadcast\InMemoryBroadcaster.java:35:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:519:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.limit(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:522:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-store-document\src\main\java\org\apache\jackrabbit\oak\plugins\document\persistentCache\PersistentCache.java:535:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataV12.java:196:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataV12.java:197:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.limit(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataUtils.java:57:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.position(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\data\SegmentDataUtils.java:58:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.limit(int) has been changed to java.nio.ByteBuffer 
> java.nio.ByteBuffer.limit(int)
> [INFO] 
> C:\projects\apache\oak\trunk\oak-segment-tar\src\main\java\org\apache\jackrabbit\oak\segment\file\tar\index\IndexWriter.java:110:
>  Covariant return type change detected: java.nio.Buffer 
> java.nio.ByteBuffer.position(int) has been changed to java.nio.ByteBuffer 
> 

[jira] [Updated] (OAK-5159) Killing the process may stop async index update to to 30 minutes, for DocumentStore (MongoDB, RDB)

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5159:
--
Fix Version/s: (was: 1.12.0)

> Killing the process may stop async index update to to 30 minutes, for 
> DocumentStore (MongoDB, RDB)
> --
>
> Key: OAK-5159
> URL: https://issues.apache.org/jira/browse/OAK-5159
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: indexing
>Reporter: Thomas Mueller
>Priority: Major
>  Labels: resilience
> Fix For: 1.14.0
>
>
> Same as OAK-2108, when using a DocumentStore based repository (MongoDB, 
> RDBMK). This is also a problem in the single-cluster-node case, not just when 
> using multiple cluster node.
> When killing a node that is running the sync index update, then this async 
> index update will not run for up to 15 minutes, because the lease time is set 
> to 15 minutes.
> We could probably use Oak / Sling Discovery to improve the situation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6773) Convert oak-store-composite to OSGi R6 annotations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6773:
--
Fix Version/s: (was: 1.12.0)

> Convert oak-store-composite to OSGi R6 annotations
> --
>
> Key: OAK-6773
> URL: https://issues.apache.org/jira/browse/OAK-6773
> Project: Jackrabbit Oak
>  Issue Type: Technical task
>  Components: composite
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: 1.14.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5121) review CommitInfo==null in BackgroundObserver with isExternal change

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5121:
--
Fix Version/s: (was: 1.12.0)

> review CommitInfo==null in BackgroundObserver with isExternal change
> 
>
> Key: OAK-5121
> URL: https://issues.apache.org/jira/browse/OAK-5121
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: core
>Affects Versions: 1.5.13
>Reporter: Stefan Egli
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.14.0
>
> Attachments: OAK-5121.patch
>
>
> OAK-4898 changes CommitInfo to be never null. This is the case outside of the 
> BackgroundObserver - but in the BackgroundObserver itself it is explicitly 
> set to null when compacting. 
> Once OAK-4898 is committed this task is about reviewing the implications in 
> BackgroundObserver wrt compaction and CommitInfo==null



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7382) Cloud datastore without local disk

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7382:
--
Fix Version/s: (was: 1.12.0)

> Cloud datastore without local disk
> --
>
> Key: OAK-7382
> URL: https://issues.apache.org/jira/browse/OAK-7382
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: blob, blob-cloud
>Reporter: Thomas Mueller
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently, the S3 datastores need local disk to work (not sure about the 
> Azure one).
> This should not be needed (not for upload, caching,...).
> Also, temporary files for garbage collection should not be needed (instead, 
> use temporary binaries, possibly written to S3 / Azure).
> Really everything should fit in a few MB of memory.
> For S3, it might be needed to read a few MB of data into memory, and then 
> possibly do a multipart upload:
>  
> https://stackoverflow.com/questions/8653146/can-i-stream-a-file-upload-to-s3-without-a-content-length-header



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-5950) XPath: stack overflow for large combination of "or" and "and"

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-5950:
--
Fix Version/s: (was: 1.12.0)

> XPath: stack overflow for large combination of "or" and "and"
> -
>
> Key: OAK-5950
> URL: https://issues.apache.org/jira/browse/OAK-5950
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: query
>Reporter: Thomas Mueller
>Priority: Critical
> Fix For: 1.14.0
>
>
> The following query returns in a stack overflow:
> {noformat}
> xpath2sql /jcr:root/home//element(*,rep:Authorizable)[(@a1=1 or @a2=1 or 
> @a3=1 or @a4=1 or @a5=1 or @a6=1 or @a7=1 or @a8=1)
>   and (@b1=1 or @b2=1 or @b3=1 or @b4=1 or @b5=1 or @b6=1 or @b7=1 or @b8=1)
>   and (@c1=1 or @c2=1 or @c3=1 or @c4=1 or @c5=1 or @c6=1 or @c7=1 or @c8=1)
>   and (@d1=1 or @d2=1 or @d3=1 or @d4=1 or @d5=1 or @d6=1 or @d7=1 or @d8=1)]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-7425) Add discovery mechanism for tooling implementations

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-7425:
--
Fix Version/s: (was: 1.12.0)

> Add discovery mechanism for tooling implementations
> ---
>
> Key: OAK-7425
> URL: https://issues.apache.org/jira/browse/OAK-7425
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
>  Labels: technical_debt
> Fix For: 1.14.0
>
> Attachments: 001.patch
>
>
> This issue proposes an idea for discovering implementations of tooling for 
> the Segment Store. Developing a tool for the Segment Store should include the 
> following step.
> * The tool compiles against the {{NodeStore}} API and the API exposed through 
> the oak-segment-tar-tool-api. In particular, the tool uses the 
> {{ToolingSupportFactory}} and related interfaces to instantiate a NodeStore 
> and, optionally, a {{NodeState}} for the proc tree.
> * The tool runs with an implementation-dependent uber-jar in the classpath. 
> The uber-jar includes the {{ToolingSupportFactory}} API, its implementation, 
> and every other class required for the implementation to work. No other JARs 
> is required to use the {{ToolingSupportFactory}} API. The tool uses the 
> Java's {{ServiceLoader}} to instantiate an implementation of 
> {{ToolingSupportFactory}}. The uber-jar is the {{oak-segment-tar-tool}} 
> module.
> The patch falls short of fully implementing the use case because 
> {{oak-segment-tar-tool-api}} is not versioned independently from Oak. This 
> can't happen at the moment because {{oak-store-spi}} and its dependencies are 
> not independently versioned either. The workflow described above could still 
> work, but only because the {{NodeStore}} and {{NodeState}} API are quite 
> stable. A cleaner solution to dependency management is required in the long 
> run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-4524) LucenePropertyIndexTest#longRepExcerpt sometimes failing

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-4524:
--
Fix Version/s: (was: 1.12.0)

> LucenePropertyIndexTest#longRepExcerpt sometimes failing
> 
>
> Key: OAK-4524
> URL: https://issues.apache.org/jira/browse/OAK-4524
> Project: Jackrabbit Oak
>  Issue Type: Test
>  Components: lucene
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
>Priority: Major
> Fix For: 1.14.0
>
>
> As reported by Julian on oak-dev@ it seems _longRepExcerpt_ is still failing 
> sometimes when query takes more than 10s e.g. see this [Jenkins 
> failure|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1000/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.lucene/LucenePropertyIndexTest/longRepExcerpt/].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6805) Support read-only flag to disable any internal write in DataStore

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6805:
--
Fix Version/s: (was: 1.12.0)

> Support read-only flag to disable any internal write in DataStore
> -
>
> Key: OAK-6805
> URL: https://issues.apache.org/jira/browse/OAK-6805
> Project: Jackrabbit Oak
>  Issue Type: Task
>  Components: blob-plugins
>Reporter: Amit Jain
>Assignee: Amit Jain
>Priority: Major
> Fix For: 1.14.0
>
>
> There should be support for a read-only flag to disable any internal writes 
> that happen in case the BlobStore has been initialized as read-only.
> Some example of internal write can be reference.key which is written as 
> introduced for S3/Azure in OAK-6802 and already existing for FileDataStore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6187) Index usage analysis (which index was used when and how)

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6187:
--
Fix Version/s: (was: 1.12.0)

> Index usage analysis (which index was used when and how)
> 
>
> Key: OAK-6187
> URL: https://issues.apache.org/jira/browse/OAK-6187
> Project: Jackrabbit Oak
>  Issue Type: New Feature
>  Components: query
>Reporter: Thomas Mueller
>Priority: Minor
> Fix For: 1.14.0
>
>
> In order to reduce space usage, unused indexes should be removed or trimmed. 
> Trimmed, because an index definition might contain "too much" (specially 
> Lucene indexes, which index multiple properties and can be very large).
> One solution is to 
> * log each query (avoiding duplicates), 
> * include which indexes were used,
> * from that generate the minimum index definitions,
> * compared with existing indexes, get the list of unused indexes and index 
> features since day X.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6919) SegmentCache might introduce unwanted memory references to SegmentId instances

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6919:
--
Fix Version/s: (was: 1.12.0)

> SegmentCache might introduce unwanted memory references to SegmentId instances
> --
>
> Key: OAK-6919
> URL: https://issues.apache.org/jira/browse/OAK-6919
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: segment-tar
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Fix For: 1.14.0
>
>
> {{SegmentCache}} contains, through the underlying Guava cache, hard 
> references to both {{SegmentId}} and {{Segment}} instances. Thus, 
> {{SegmentCache}} contributes to the computation of in-memory references that, 
> in turn, constitute the root references of the garbage collection algorithm.
> Further investigations are needed to assess this statement but, if 
> {{SegmentCache}} is proved to be problematic, there are some possible 
> solutions.
> For example, {{SegmentCache}} might be reworked to store references to 
> MSB/LSB pairs as keys, instead of to {{SegmentId}} instances. Moreover, 
> instead of referencing {{Segment}} instances as values, {{SegmentCache}} 
> might hold references to their underlying {{ByteBuffer}}. With these changes 
> in place, {{SegmentCache}} would not interfere with {{SegmentTracker}} and 
> the garbage collection algorithm.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6166) Support versioning in the composite node store

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6166:
--
Fix Version/s: (was: 1.12.0)

> Support versioning in the composite node store
> --
>
> Key: OAK-6166
> URL: https://issues.apache.org/jira/browse/OAK-6166
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: composite
>Reporter: Tomek Rękawek
>Priority: Minor
> Fix For: 1.14.0
>
>
> The mount info provider should affect the versioning code as well, so version 
> histories for the mounted paths are stored separately. Similarly to what we 
> have in the indexing, let's store the mounted version histories under:
> /jcr:system/jcr:versionStorage/:oak:mount-MOUNTNAME



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-3809) Test failure: FacetTest

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-3809:
--
Fix Version/s: (was: 1.12.0)

> Test failure: FacetTest
> ---
>
> Key: OAK-3809
> URL: https://issues.apache.org/jira/browse/OAK-3809
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: solr
> Environment: 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Tommaso Teofili
>Priority: Major
>  Labels: ci, jenkins, test, test-failure
> Fix For: 1.14.0
>
>
> {{org.apache.jackrabbit.oak.jcr.query.FacetTest}} keeps failing on Jenkins:
> {noformat}
> testFacetRetrievalMV(org.apache.jackrabbit.oak.jcr.query.FacetTest)  Time 
> elapsed: 5.927 sec  <<< FAILURE!
> junit.framework.ComparisonFailure: expected: (2), aem (1), apache (1), cosmetics (1), furniture (1)], tags:[repository 
> (2), software (2), aem (1), apache (1), cosmetics (1), furniture (1)], 
> tags:[repository (2), software (2), aem (1), apache (1), cosmetics (1), 
> furniture (1)], tags:[repository (2), software (2), aem (1), apache (1), 
> cosmetics (1), furniture (1)]]> but was:
>   at junit.framework.Assert.assertEquals(Assert.java:100)
>   at junit.framework.Assert.assertEquals(Assert.java:107)
>   at junit.framework.TestCase.assertEquals(TestCase.java:269)
>   at 
> org.apache.jackrabbit.oak.jcr.query.FacetTest.testFacetRetrievalMV(FacetTest.java:80)
> {noformat}
> Failure seen at builds: 628, 629, 630, 633, 634, 636, 642, 643, 644, 645, 
> 648, 651, 656, 659, 660, 663, 666
> See e.g. 
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/634/#showFailuresLink



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-6366) Detect unsupported combination of read and write concern

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-6366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-6366:
--
Fix Version/s: (was: 1.12.0)

> Detect unsupported combination of read and write concern
> 
>
> Key: OAK-6366
> URL: https://issues.apache.org/jira/browse/OAK-6366
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: mongomk
>Reporter: Marcel Reutegger
>Priority: Minor
> Fix For: 1.14.0
>
>
> With OAK-4069 Oak will try to use a majority read concern when connected to a 
> replica set. The implementation should be more careful when setting a 
> majority read concern automatically and take the write concern into account. 
> It is currently possible to end up with a system that has a user configured 
> write concern of 1 and a majority read concern. This results in a 
> non-functional system and should be prevented.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-8187) Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider and RestrictionProvider

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-8187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-8187:
--
Fix Version/s: (was: 1.12.0)

> Respect service ranking with AuthorizableNodeName, AuthorizableActionProvider 
> and RestrictionProvider
> -
>
> Key: OAK-8187
> URL: https://issues.apache.org/jira/browse/OAK-8187
> Project: Jackrabbit Oak
>  Issue Type: Bug
>  Components: core
>Reporter: angela
>Priority: Major
> Fix For: 1.14.0
>
>
> The way multiple {{AuthorizableNodeName}}, {{AuthorizableActionProvider}} and 
> {{RestrictionProvider}} service are handled by 
> {{SecurityProviderRegistration}} suffers from the same issues as was reported 
> for {{UserAuthenticationFactory}} (see OAK-8045). Once OAK-8045 is addressed 
> we should adopt the same behavior for the remaining bind/unbind methods for 
> the interfaces mentioned above.
> cc: [~stillalex]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (OAK-1150) NodeType index: don't index all primary and mixin types

[Davide Giannella (JIRA)]

 [ 
https://issues.apache.org/jira/browse/OAK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Davide Giannella updated OAK-1150:
--
Fix Version/s: (was: 1.12.0)

> NodeType index: don't index all primary and mixin types
> ---
>
> Key: OAK-1150
> URL: https://issues.apache.org/jira/browse/OAK-1150
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: property-index
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently, the nodetype index indexes all primary types and mixin types 
> (including nt:base I think).
> This results in many nodes in this index, which unnecessarily increases the 
> repository size, but doesn't really help executing queries (running a query 
> to get all nt:base nodes doesn't benefit much from using the nodetype index).
> It should also help reduce writes in updating the index, for example for 
> OAK-1099



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)