[jira] [Created] (OAK-9963) Performance degradation when reading system properties on each NodeImpl
Paul Chibulcuteanu created OAK-9963:
---
Summary: Performance degradation when reading system properties on
each NodeImpl
Key: OAK-9963
URL: https://issues.apache.org/jira/browse/OAK-9963
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 1.22.11
Reporter: Paul Chibulcuteanu
Reading system properties on each NodeImpl causes performance issues especially
on Java 8.
Code:
{code:java}
public NodeImpl(T dlg, SessionContext sessionContext) {
super(dlg, sessionContext);
logWarnStringSizeThreshold = Integer.getInteger(
OakJcrConstants.WARN_LOG_STRING_SIZE_THRESHOLD_KEY,
OakJcrConstants.DEFAULT_WARN_LOG_STRING_SIZE_THRESHOLD_VALUE);
}
{code}
One more important point on system property lookup in Oak. There is a huge
difference between running the code on Java 8 and 11.
The following test looks up a system property with 32 concurrent threads. Each
reading the system property 10M times.
{code:java}
@Test
public void run() throws Exception {
List threads = new ArrayList<>();
for (int i = 0; i < 32; i++) {
threads.add(new Thread(this::getProperty));
}
Stopwatch sw = Stopwatch.createStarted();
threads.forEach(Thread::start);
for (Thread t : threads) {
t.join();
}
System.out.println("time: " + sw);
}
private void getProperty() {
for (int i = 0; i < 10_000_000; i++) {
System.getProperty("foo");
}
}
{code}
On my machine the outputs are:
Java 8: ~20 seconds
Java 11: 0.5 seconds
Reason is how Properties implementation changed with Java 11. It is now using a
ConcurrentHashMap.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-9906) Add parameter to provide custom logback.xml to oak-run
[ https://issues.apache.org/jira/browse/OAK-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-9906: Description: Currently the logback.xml configuration of oak-run is embedded in the jar. Providing an extra argument with a custom logback.xml file would aid debugging. was: Currently the logback.xml configuration of oak-run is embedded in the jar. Providing a extra argument with a custom logback.xml file would aid debugging. > Add parameter to provide custom logback.xml to oak-run > -- > > Key: OAK-9906 > URL: https://issues.apache.org/jira/browse/OAK-9906 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Affects Versions: 1.44.0 >Reporter: Paul Chibulcuteanu >Priority: Major > > Currently the logback.xml configuration of oak-run is embedded in the jar. > Providing an extra argument with a custom logback.xml file would aid > debugging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-9906) Add parameter to provide custom logback.xml to oak-run
[ https://issues.apache.org/jira/browse/OAK-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-9906: Description: Currently the logback.xml configuration of oak-run is embedded in the jar. Providing an extra parameter with a custom logback.xml file would aid debugging. was: Currently the logback.xml configuration of oak-run is embedded in the jar. Providing an extra argument with a custom logback.xml file would aid debugging. > Add parameter to provide custom logback.xml to oak-run > -- > > Key: OAK-9906 > URL: https://issues.apache.org/jira/browse/OAK-9906 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Affects Versions: 1.44.0 >Reporter: Paul Chibulcuteanu >Priority: Major > > Currently the logback.xml configuration of oak-run is embedded in the jar. > Providing an extra parameter with a custom logback.xml file would aid > debugging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-9906) Add parameter to provide custom logback.xml to oak-run
Paul Chibulcuteanu created OAK-9906: --- Summary: Add parameter to provide custom logback.xml to oak-run Key: OAK-9906 URL: https://issues.apache.org/jira/browse/OAK-9906 Project: Jackrabbit Oak Issue Type: Improvement Components: oak-run Affects Versions: 1.44.0 Reporter: Paul Chibulcuteanu Currently the logback.xml configuration of oak-run is embedded in the jar. Providing a extra argument with a custom logback.xml file would aid debugging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-9504) Increase default timeout for elasticsearch index update
Paul Chibulcuteanu created OAK-9504:
---
Summary: Increase default timeout for elasticsearch index update
Key: OAK-9504
URL: https://issues.apache.org/jira/browse/OAK-9504
Project: Jackrabbit Oak
Issue Type: Improvement
Components: elastic-search, indexing
Affects Versions: 1.40.0
Reporter: Paul Chibulcuteanu
Currently we have the following retry configuration for elastichsearch:
{code}
public static final String BULK_RETRIES = "bulkRetries";
public static final int BULK_RETRIES_DEFAULT = 3;
public static final String BULK_RETRIES_BACKOFF = "bulkRetriesBackoff";
public static final long BULK_RETRIES_BACKOFF_DEFAULT = 200;
{code}
This does not really protect against network hiccups which can take longer. I
would suggest either 5 retries with 500 backoff or 3 retries with 1s backoff.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-9503) List documents on elastic search bulk update failure
Paul Chibulcuteanu created OAK-9503:
---
Summary: List documents on elastic search bulk update failure
Key: OAK-9503
URL: https://issues.apache.org/jira/browse/OAK-9503
Project: Jackrabbit Oak
Issue Type: Improvement
Components: elastic-search, indexing
Affects Versions: 1.40.0
Reporter: Paul Chibulcuteanu
Currently, if there is a failure to update elasticsearch indexes such as:
{code}
[pool-12-thread-1]
org.apache.jackrabbit.oak.plugins.index.elastic.index.ElasticBulkProcessorHandler
ElasticIndex Update Bulk Failure : Bulk with id 1 threw an error
java.net.ConnectException: Timeout connecting to [:]
at
org.apache.http.nio.pool.RouteSpecificPool.timeout(RouteSpecificPool.java:169)
[org.apache.jackrabbit.oak-search-elastic:1.40.0.T20210628142906-c91e018]
at
org.apache.http.nio.pool.AbstractNIOConnPool.requestTimeout(AbstractNIOConnPool.java:628)
[org.apache.jackrabbit.oak-search-elastic:1.40.0.T20210628142906-c91e018]
at
org.apache.http.nio.pool.AbstractNIOConnPool$InternalSessionRequestCallback.timeout(AbstractNIOConnPool.java:894)
[org.apache.jackrabbit.oak-search-elastic:1.40.0.T20210628142906-c91e018]
at
org.apache.http.impl.nio.reactor.SessionRequestImpl.timeout(SessionRequestImpl.java:184)
[org.apache.jackrabbit.oak-search-elastic:1.40.0.T20210628142906-c91e018]
at
org.apache.http.impl.nio.reactor.DefaultConnectingIOReactor.processTimeouts(DefaultConnectingIOReactor.java:214)
[org.apache.jackrabbit.oak-search-elastic:1.40.0.T20210628142906-c91e018]
{code}
there is no way of knowing if there is any data loss or not. We should enahance
this exception to include the list of documents that were part of the bulk
update
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-9488) Extra logging in org.apache.jackrabbit.oak.run.DataStoreCommand
Paul Chibulcuteanu created OAK-9488:
---
Summary: Extra logging in
org.apache.jackrabbit.oak.run.DataStoreCommand
Key: OAK-9488
URL: https://issues.apache.org/jira/browse/OAK-9488
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-azure
Reporter: Paul Chibulcuteanu
Running datastore command to retrieve the index binaries blob IDs from Azure
with following options:
{code}
16.06.2021 20:49:50.452 *INFO* [main] o.a.j.oak.run.DataStoreCommand - Command
line arguments used for datastore command [--dump-ref --out-dir /opt/out_dir
--azureds /DataStore.config --verboseRootPath /oak:index/
--verbosePathInclusionRegex /*/:data,/*/:suggest-data --verbose]
16.06.2021 20:49:50.454 *INFO* [main] o.a.j.oak.run.DataStoreCommand - System
properties and vm options passed [-Dsegment.timeout.interval=60,
-Dsegment.timeout.execution=325]
{code}
can sometimes take minutes. This operation is usually fast(a few seconds).
The log of the command only displays little info about what is happening:
{code}
16.06.2021 20:49:50.839 *INFO* [pool-3-thread-1] o.a.j.o.plugins.blob.FileCache
- Cache built with [0] files from file system in [0] seconds
16.06.2021 20:54:45.901 *INFO* [main] o.a.j.oak.run.DataStoreCommand - Starting
dump of blob references by traversing
{code}
There is no information on where the 5 minutes is spent. It could be a network
hiccup, maybe Azure connectivity issues, or too many sessions opened, but there
is no way to find out. We should add extra logging in
_org.apache.jackrabbit.oak.run.DataStoreCommand_ in order to be able to
investigate such slowness cases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9379) Disable ElasticIndexProviderService via a system property
[
https://issues.apache.org/jira/browse/OAK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-9379:
Description:
Disable _ElasticIndexProviderService_ when a system property is passed and make
sure elastic indexes return infinity cost in that case.
E.g:
{code}
-Doak.elastic.disabled=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
was:
Disable _ElasticIndexProviderService_ when a system property is passed elastic
and make sure elastic indexes return infinity cost.
E.g:
{code}
-Doak.elastic.disabled=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
> Disable ElasticIndexProviderService via a system property
> -
>
> Key: OAK-9379
> URL: https://issues.apache.org/jira/browse/OAK-9379
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: search-elastic
>Affects Versions: 1.38.0
>Reporter: Paul Chibulcuteanu
>Priority: Major
>
> Disable _ElasticIndexProviderService_ when a system property is passed and
> make sure elastic indexes return infinity cost in that case.
> E.g:
> {code}
> -Doak.elastic.disabled=true
> {code}
> Additionally, a unit test should be written to test query execution when both
> ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
> and elastic indexes return infinity cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9379) Disable ElasticIndexProviderService via a system property
[
https://issues.apache.org/jira/browse/OAK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-9379:
Description:
Disable _ElasticIndexProviderService_ when a system property is passed elastic
and make sure elastic indexes return infinity cost.
E.g:
{code}
-Doak.elastic.disabled=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
was:
Disable _ElasticIndexProviderService_ when a system property is passed elastic
and make sure elastic indexes return infinity cost.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
> Disable ElasticIndexProviderService via a system property
> -
>
> Key: OAK-9379
> URL: https://issues.apache.org/jira/browse/OAK-9379
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: search-elastic
>Affects Versions: 1.38.0
>Reporter: Paul Chibulcuteanu
>Priority: Major
>
> Disable _ElasticIndexProviderService_ when a system property is passed
> elastic and make sure elastic indexes return infinity cost.
> E.g:
> {code}
> -Doak.elastic.disabled=true
> {code}
> Additionally, a unit test should be written to test query execution when both
> ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
> and elastic indexes return infinity cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9379) Disable ElasticIndexProviderService via a system property
[
https://issues.apache.org/jira/browse/OAK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-9379:
Description:
Disable _ElasticIndexProviderService_ when a system property is passed elastic
and make sure elastic indexes return infinity cost.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
was:
Disable _ElasticIndexProviderService_ when a system property is passed.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
> Disable ElasticIndexProviderService via a system property
> -
>
> Key: OAK-9379
> URL: https://issues.apache.org/jira/browse/OAK-9379
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: search-elastic
>Affects Versions: 1.38.0
>Reporter: Paul Chibulcuteanu
>Priority: Major
>
> Disable _ElasticIndexProviderService_ when a system property is passed
> elastic and make sure elastic indexes return infinity cost.
> E.g:
> {code}
> -Doak.elastic.disableElasticIndexProvider=true
> {code}
> Additionally, a unit test should be written to test query execution when both
> ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
> and elastic indexes return infinity cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-9379) Disable ElasticIndexProviderService via a system property
[
https://issues.apache.org/jira/browse/OAK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-9379:
Description:
Disable _ElasticIndexProviderService_ when a system property is passed.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
and elastic indexes return infinity cost.
was:
Disable _ElasticIndexProviderService_ when a system property is passed.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
> Disable ElasticIndexProviderService via a system property
> -
>
> Key: OAK-9379
> URL: https://issues.apache.org/jira/browse/OAK-9379
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: search-elastic
>Affects Versions: 1.38.0
>Reporter: Paul Chibulcuteanu
>Priority: Major
>
> Disable _ElasticIndexProviderService_ when a system property is passed.
> E.g:
> {code}
> -Doak.elastic.disableElasticIndexProvider=true
> {code}
> Additionally, a unit test should be written to test query execution when both
> ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
> and elastic indexes return infinity cost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-9379) Disable ElasticIndexProviderService via a system property
Paul Chibulcuteanu created OAK-9379:
---
Summary: Disable ElasticIndexProviderService via a system property
Key: OAK-9379
URL: https://issues.apache.org/jira/browse/OAK-9379
Project: Jackrabbit Oak
Issue Type: Improvement
Components: search-elastic
Affects Versions: 1.38.0
Reporter: Paul Chibulcuteanu
Disable _ElasticIndexProviderService_ when a system property is passed.
E.g:
{code}
-Doak.elastic.disableElasticIndexProvider=true
{code}
Additionally, a unit test should be written to test query execution when both
ES & lucene indexes are present and _ElasticIndexProviderService_ is disabled
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8921) Create repositoryId in case it doesn't exist as part of DataStoreCommand
[
https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043426#comment-17043426
]
Paul Chibulcuteanu commented on OAK-8921:
-
[~amitjain], thanks for the suggestions. [~ngupta], what about this proposal:
add a flag to the command to ignore repositoryId presence and disable the check
in case this flag is set?
> Create repositoryId in case it doesn't exist as part of DataStoreCommand
>
>
> Key: OAK-8921
> URL: https://issues.apache.org/jira/browse/OAK-8921
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: blob, blob-cloud
>Reporter: Paul Chibulcuteanu
>Priority: Minor
> Attachments: OAK-8921-1.patch
>
>
> As part of the _DataStoreCommand_ there is the assumption that the
> _repositoryId_ is always present when the consistency check is run.
> This is not always the case, especially when oak in not initialised but the
> nodestore & datastore are already created.
> Existing code:
> {code}
> String repositoryId = ClusterRepositoryInfo.getId(fixture.getStore());
> checkNotNull(repositoryId);
> {code}
> Proposal:
> Create repositoryId in case it doesn't exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8921) Create repositoryId in case it doesn't exist as part of DataStoreCommand
[
https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-8921:
Attachment: OAK-8921-1.patch
> Create repositoryId in case it doesn't exist as part of DataStoreCommand
>
>
> Key: OAK-8921
> URL: https://issues.apache.org/jira/browse/OAK-8921
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: blob, blob-cloud
>Reporter: Paul Chibulcuteanu
>Priority: Minor
> Attachments: OAK-8921-1.patch
>
>
> As part of the _DataStoreCommand_ there is the assumption that the
> _repositoryId_ is always present when the consistency check is run.
> This is not always the case, especially when oak in not initialised but the
> nodestore & datastore are already created.
> Existing code:
> {code}
> String repositoryId = ClusterRepositoryInfo.getId(fixture.getStore());
> checkNotNull(repositoryId);
> {code}
> Proposal:
> Create repositoryId in case it doesn't exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8921) Create repositoryId in case it doesn't exist as part of DataStoreCommand
[
https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-8921:
Description:
As part of the _DataStoreCommand_ there is the assumption that the
_repositoryId_ is always present when the consistency check is run.
This is not always the case, especially when oak in not initialised but the
nodestore & datastore are already created.
Existing code:
{code}
String repositoryId = ClusterRepositoryInfo.getId(fixture.getStore());
checkNotNull(repositoryId);
{code}
Proposal:
Create repositoryId in case it doesn't exist.
> Create repositoryId in case it doesn't exist as part of DataStoreCommand
>
>
> Key: OAK-8921
> URL: https://issues.apache.org/jira/browse/OAK-8921
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: blob, blob-cloud
>Reporter: Paul Chibulcuteanu
>Priority: Minor
>
> As part of the _DataStoreCommand_ there is the assumption that the
> _repositoryId_ is always present when the consistency check is run.
> This is not always the case, especially when oak in not initialised but the
> nodestore & datastore are already created.
> Existing code:
> {code}
> String repositoryId = ClusterRepositoryInfo.getId(fixture.getStore());
> checkNotNull(repositoryId);
> {code}
> Proposal:
> Create repositoryId in case it doesn't exist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8921) Create repositoryId in case it doesn't exist as part of DataStoreCommand
[ https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-8921: Summary: Create repositoryId in case it doesn't exist as part of DataStoreCommand (was: Create repositoryId in case it doesn't exist) > Create repositoryId in case it doesn't exist as part of DataStoreCommand > > > Key: OAK-8921 > URL: https://issues.apache.org/jira/browse/OAK-8921 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob, blob-cloud >Reporter: Paul Chibulcuteanu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8921) Create repositoryId in case it doesn't exist
[ https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-8921: Component/s: blob-cloud > Create repositoryId in case it doesn't exist > > > Key: OAK-8921 > URL: https://issues.apache.org/jira/browse/OAK-8921 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob, blob-cloud >Reporter: Paul Chibulcuteanu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8921) Create repositoryId in case it doesn't exist
[ https://issues.apache.org/jira/browse/OAK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-8921: Component/s: (was: mongomk) blob > Create repositoryId in case it doesn't exist > > > Key: OAK-8921 > URL: https://issues.apache.org/jira/browse/OAK-8921 > Project: Jackrabbit Oak > Issue Type: Task > Components: blob >Reporter: Paul Chibulcuteanu >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8921) Create repositoryId in case it doesn't exist
Paul Chibulcuteanu created OAK-8921: --- Summary: Create repositoryId in case it doesn't exist Key: OAK-8921 URL: https://issues.apache.org/jira/browse/OAK-8921 Project: Jackrabbit Oak Issue Type: Task Components: mongomk Reporter: Paul Chibulcuteanu -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8011) Benchmark on QUERY_DURATION metrics implemented in OAK-7904
[
https://issues.apache.org/jira/browse/OAK-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16756186#comment-16756186
]
Paul Chibulcuteanu commented on OAK-8011:
-
[~tmueller], I ran some benchmark tests locally with the two mentioned cases:
* specifying the oak.query.timerDisabled system prop
* without specifying the oak.query.timerDisabled system prop
The results show that there is no impact on performance. I used the LoginTest
the most. I would wait for your reply before closing this issue.
Here are the results and various modes run
{code}
LoginTest, Timer enabled, Oak-Composite-Store FIXTURE,1 minute:
java -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Store1 611 615 649 703 874
92
LoginTest, Timer disabled, Oak-Composite-Store FIXTURE, 1 minute:
java -Doak.query.timerDisabled -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Store1 595 621 647 719 889
91
LoginTest, Timer enabled, Oak-Composite-Store FIXTURE,10 minutes:
java -Dwarmup=5 -Druntime=600 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Store1 606 615 662 7911000
867
LoginTest, Timer disabled, Oak-Composite-Store FIXTURE, 10 minutes:
java -Doak.query.timerDisabled -Dwarmup=5 -Druntime=600 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Store1 620 653 705 7881218
840
LoginTest, Timer enabled, Oak-Composite-Memory-Store FIXTURE, 10 minutes:
java -Dwarmup=5 -Druntime=600 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Memory-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Memory-Store 1 583 593 621 7341335
923
LoginTest, Timer disabled, Oak-Composite-Memory-Store FIXTURE, 10 minutes:
java -Doak.query.timerDisabled -Dwarmup=5 -Druntime=600 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
LoginTest Oak-Composite-Memory-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# LoginTestC min 10% 50% 90% max
N
Oak-Composite-Memory-Store 1 578 590 611 669 913
961
GetPrincipalTest, Timer enabled, Oak-Composite-Store FIXTURE, 1 minute:
java -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
GetPrincipalTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# GetPrincipalTest C min 10% 50% 90% max
N
Setup 1 users
Oak-Composite-Store1 106 112 123 143 188
478
GetPrincipalTest, Timer disabled, Oak-Composite-Store FIXTURE, 1 minute:
java -Doak.query.timerDisabled -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
GetPrincipalTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# GetPrincipalTest C min 10% 50% 90% max
N
Setup 1 users
Oak-Composite-Store1 105 116 124 142 173
473
OrderedIndexQueryStandardIndexTest, Timer enabled, Oak-Composite-Store FIXTURE,
1 minute:
java -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar org.apache.jackrabbit.oak.run.Main benchmark
OrderedIndexQueryStandardIndexTest Oak-Composite-Store
Apache Jackrabbit Oak 1.12-SNAPSHOT
# OrderedIndexQueryStandardI C min 10% 50% 90% max
N
Oak-Composite-Store1 0 0 0 0 12
1262384
OrderedIndexQueryStandardIndexTest, Timer disabled, Oak-Composite-Store
FIXTURE, 1 minute:
java -Doak.query.timerDisabled -Dwarmup=5 -Druntime=60 -Dprofile=true -cp
oak-benchmarks-1.12-SNAPSHOT.jar
[jira] [Resolved] (OAK-7904) Exporting query duration per index metrics with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu resolved OAK-7904. - Resolution: Fixed Assignee: Thomas Mueller (was: Paul Chibulcuteanu) Opened OAK-8011 for measuring the overhead of measuring. Fixed in trunk [r1852102|http://svn.apache.org/r1852102]. > Exporting query duration per index metrics with Sling Metrics / DropWizard > -- > > Key: OAK-7904 > URL: https://issues.apache.org/jira/browse/OAK-7904 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Thomas Mueller >Priority: Major > Fix For: 1.12, 1.9.10 > > Attachments: OAK-7904.0.patch, OAK-7904.1.patch > > > Purpose of this task is to evaluate & create metric which calculates the > average duration of query for each index. > This metric can be later used to evaluate which index(s) need to be optimised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8011) Benchmark on QUERY_DURATION metrics implemented in OAK-7904
[
https://issues.apache.org/jira/browse/OAK-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-8011:
Fix Version/s: 1.12
> Benchmark on QUERY_DURATION metrics implemented in OAK-7904
> ---
>
> Key: OAK-8011
> URL: https://issues.apache.org/jira/browse/OAK-8011
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: indexing, query
>Reporter: Paul Chibulcuteanu
>Priority: Major
> Fix For: 1.12
>
>
> As part of OAK-7904, there are some possible performance concerns on adding
> additional metrics in code which is executed a lot.
> See [~tmueller]'s comment:
> {code}
> Some comments on overhead of measuring:
> We measure here very common, and very fast operations. I don't know how fast
> next() could be, but if everything is in memory, it could be faster than 600
> ns. I measured the fastest measured operation was processed at 0.091904
> milliseconds , that would be 91904 nanoseconds. Measures was this divided by
> 256, so just 359 nanoseconds.
> System.nanoTime() can be slower than that, according to this older article it
> can be 650 nanoseconds. We need to call it twice to measure, so 1'300
> nanoseconds. Meaning, measuring in the worst case seens so far slows down the
> operation by factor 4.6 (worst case seen so far).
> What we could do is use org.apache.jackrabbit.oak.stats Clock.Fast, which has
> a much lower overhead than calling System.nanoTime(). The name "Fast" is
> somewhat of a misnomer: the clock isn't really faster than other clocks, it's
> just less overhead. So getting the current time is fast. Resolution is low,
> but that wouldn't be a problem in our case, it's just that most of the time,
> operations would be 0 ns, and rarely 100s of ns. On average, that would even
> out (same as with the sampling it is using right now). The problems with
> Clock.Fast are:
> Hard to get a hand on this instance.
> It uses a thread pool executor service, which is problematic. If the same
> service is used by other threads that take milliseconds, then the clock is
> extremely inaccurate. I would be better to use a simple, separate daemon
> thread.
> {code}
> Seeing that there is the possibility to enable/disable the metrics stats two
> separate benchmark tests can be run:
> * specifying the _oak.query.timerDisabled_ system prop
> * without specifying the _oak.query.timerDisabled_ system prop
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8011) Benchmark on QUERY_DURATION metrics implemented in OAK-7904
Paul Chibulcuteanu created OAK-8011:
---
Summary: Benchmark on QUERY_DURATION metrics implemented in
OAK-7904
Key: OAK-8011
URL: https://issues.apache.org/jira/browse/OAK-8011
Project: Jackrabbit Oak
Issue Type: Task
Reporter: Paul Chibulcuteanu
As part of OAK-7904, there are some possible performance concerns on adding
additional metrics in code which is executed a lot.
See [~tmueller]'s comment:
{code}
Some comments on overhead of measuring:
We measure here very common, and very fast operations. I don't know how fast
next() could be, but if everything is in memory, it could be faster than 600
ns. I measured the fastest measured operation was processed at 0.091904
milliseconds , that would be 91904 nanoseconds. Measures was this divided by
256, so just 359 nanoseconds.
System.nanoTime() can be slower than that, according to this older article it
can be 650 nanoseconds. We need to call it twice to measure, so 1'300
nanoseconds. Meaning, measuring in the worst case seens so far slows down the
operation by factor 4.6 (worst case seen so far).
What we could do is use org.apache.jackrabbit.oak.stats Clock.Fast, which has a
much lower overhead than calling System.nanoTime(). The name "Fast" is somewhat
of a misnomer: the clock isn't really faster than other clocks, it's just less
overhead. So getting the current time is fast. Resolution is low, but that
wouldn't be a problem in our case, it's just that most of the time, operations
would be 0 ns, and rarely 100s of ns. On average, that would even out (same as
with the sampling it is using right now). The problems with Clock.Fast are:
Hard to get a hand on this instance.
It uses a thread pool executor service, which is problematic. If the same
service is used by other threads that take milliseconds, then the clock is
extremely inaccurate. I would be better to use a simple, separate daemon thread.
{code}
Seeing that there is the possibility to enable/disable the metrics stats two
separate benchmark tests can be run:
* specifying the _oak.query.timerDisabled_ system prop
* without specifying the _oak.query.timerDisabled_ system prop
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8011) Benchmark on QUERY_DURATION metrics implemented in OAK-7904
[
https://issues.apache.org/jira/browse/OAK-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-8011:
Component/s: query
indexing
> Benchmark on QUERY_DURATION metrics implemented in OAK-7904
> ---
>
> Key: OAK-8011
> URL: https://issues.apache.org/jira/browse/OAK-8011
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: indexing, query
>Reporter: Paul Chibulcuteanu
>Priority: Major
>
> As part of OAK-7904, there are some possible performance concerns on adding
> additional metrics in code which is executed a lot.
> See [~tmueller]'s comment:
> {code}
> Some comments on overhead of measuring:
> We measure here very common, and very fast operations. I don't know how fast
> next() could be, but if everything is in memory, it could be faster than 600
> ns. I measured the fastest measured operation was processed at 0.091904
> milliseconds , that would be 91904 nanoseconds. Measures was this divided by
> 256, so just 359 nanoseconds.
> System.nanoTime() can be slower than that, according to this older article it
> can be 650 nanoseconds. We need to call it twice to measure, so 1'300
> nanoseconds. Meaning, measuring in the worst case seens so far slows down the
> operation by factor 4.6 (worst case seen so far).
> What we could do is use org.apache.jackrabbit.oak.stats Clock.Fast, which has
> a much lower overhead than calling System.nanoTime(). The name "Fast" is
> somewhat of a misnomer: the clock isn't really faster than other clocks, it's
> just less overhead. So getting the current time is fast. Resolution is low,
> but that wouldn't be a problem in our case, it's just that most of the time,
> operations would be 0 ns, and rarely 100s of ns. On average, that would even
> out (same as with the sampling it is using right now). The problems with
> Clock.Fast are:
> Hard to get a hand on this instance.
> It uses a thread pool executor service, which is problematic. If the same
> service is used by other threads that take milliseconds, then the clock is
> extremely inaccurate. I would be better to use a simple, separate daemon
> thread.
> {code}
> Seeing that there is the possibility to enable/disable the metrics stats two
> separate benchmark tests can be run:
> * specifying the _oak.query.timerDisabled_ system prop
> * without specifying the _oak.query.timerDisabled_ system prop
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7904) Exporting query duration per index metrics with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746302#comment-16746302 ] Paul Chibulcuteanu commented on OAK-7904: - [~tmueller], I've added [^OAK-7904.1.patch] which for now only measures the execution time. > Exporting query duration per index metrics with Sling Metrics / DropWizard > -- > > Key: OAK-7904 > URL: https://issues.apache.org/jira/browse/OAK-7904 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Fix For: 1.9.10, 1.12 > > Attachments: OAK-7904.0.patch, OAK-7904.1.patch > > > Purpose of this task is to evaluate & create metric which calculates the > average duration of query for each index. > This metric can be later used to evaluate which index(s) need to be optimised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7904) Exporting query duration per index metrics with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7904: Attachment: OAK-7904.1.patch > Exporting query duration per index metrics with Sling Metrics / DropWizard > -- > > Key: OAK-7904 > URL: https://issues.apache.org/jira/browse/OAK-7904 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Fix For: 1.9.10, 1.12 > > Attachments: OAK-7904.0.patch, OAK-7904.1.patch > > > Purpose of this task is to evaluate & create metric which calculates the > average duration of query for each index. > This metric can be later used to evaluate which index(s) need to be optimised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu resolved OAK-7907. - Resolution: Won't Fix QUERY_COUNT doesn't need to be explicitly defined as a standalone metric since QUERY_DURATION.count provides the number of queries run. > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch, OAK-7907_v2.patch, OAK-7907_v3.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693452#comment-16693452 ] Paul Chibulcuteanu commented on OAK-7907: - [~teofili], [~catholicon], I've found an easier to fix this issue punctually. See [^OAK-7907_v3.patch]. Because RepositoryStats MBean was using QUERY_DURATION,QUERY_AVERAGE, QUERY_COUNT, but was not exposing the later, I've made it a a standalone metric which calculates the total number of queries run. This would not solve the conversation on figuring out how to properly provide a _statisticsProvider_ to be used for other metrics, like: https://issues.apache.org/jira/browse/OAK-7904 > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch, OAK-7907_v2.patch, OAK-7907_v3.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7907: Attachment: OAK-7907_v3.patch > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch, OAK-7907_v2.patch, OAK-7907_v3.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689634#comment-16689634 ] Paul Chibulcuteanu commented on OAK-7907: - Thanks [~teofili]. I think it's a good idea to have the util methods for updating query metrics under QueryStatsMBean. I guess we will add more when the time comes(for Histograms, Gauges, etc.) I tested out your patch a bit and it seems that statisticsProvider is _null_ in this case, thus resulting in metrics not being collected. Does making _statisticsProvider_ static has something to do with this? Besides that some unused imports from _QueryEngineImpl_ and _QueryEngineSettingsService_ should be removed. > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch, OAK-7907_v2.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16689516#comment-16689516 ] Paul Chibulcuteanu commented on OAK-7907: - [~teofili], can you please have a look? [^OAK-7907_v1.patch] > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7907: Attachment: OAK-7907_v1.patch > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > Attachments: OAK-7907_v1.patch > > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
Paul Chibulcuteanu created OAK-7907: --- Summary: Exporting total query count with Sling Metrics / DropWizard Key: OAK-7907 URL: https://issues.apache.org/jira/browse/OAK-7907 Project: Jackrabbit Oak Issue Type: Bug Components: indexing, query Reporter: Paul Chibulcuteanu Purpose of this task is to evaluate & create a metric which presents the number of queries run in AEM. metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu reassigned OAK-7907: --- Assignee: Paul Chibulcuteanu > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Assignee: Paul Chibulcuteanu >Priority: Major > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7907: Description: Purpose of this task is to evaluate & create a metric which presents the number of queries run in Oak. metric name: QUERY-COUNT was: Purpose of this task is to evaluate & create a metric which presents the number of queries run. metric name: QUERY-COUNT > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Priority: Major > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run in Oak. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7907) Exporting total query count with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7907: Description: Purpose of this task is to evaluate & create a metric which presents the number of queries run. metric name: QUERY-COUNT was: Purpose of this task is to evaluate & create a metric which presents the number of queries run in AEM. metric name: QUERY-COUNT > Exporting total query count with Sling Metrics / DropWizard > --- > > Key: OAK-7907 > URL: https://issues.apache.org/jira/browse/OAK-7907 > Project: Jackrabbit Oak > Issue Type: Bug > Components: indexing, query >Reporter: Paul Chibulcuteanu >Priority: Major > > Purpose of this task is to evaluate & create a metric which presents the > number of queries run. > metric name: QUERY-COUNT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7904) Exporting query duration per index metrics with Sling Metrics / DropWizard
[ https://issues.apache.org/jira/browse/OAK-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Chibulcuteanu updated OAK-7904: Issue Type: Task (was: Bug) > Exporting query duration per index metrics with Sling Metrics / DropWizard > -- > > Key: OAK-7904 > URL: https://issues.apache.org/jira/browse/OAK-7904 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, query >Reporter: Paul Chibulcuteanu >Priority: Major > Fix For: 1.9.10 > > > Purpose of this task is to evaluate & create metric which calculates the > average duration of query for each index. > This metric can be later used to evaluate which index(s) need to be optimised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7904) Exporting query duration per index metrics with Sling Metrics / DropWizard
Paul Chibulcuteanu created OAK-7904: --- Summary: Exporting query duration per index metrics with Sling Metrics / DropWizard Key: OAK-7904 URL: https://issues.apache.org/jira/browse/OAK-7904 Project: Jackrabbit Oak Issue Type: Bug Components: indexing, query Reporter: Paul Chibulcuteanu Fix For: 1.9.10 Purpose of this task is to evaluate & create metric which calculates the average duration of query for each index. This metric can be later used to evaluate which index(s) need to be optimised. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7610) Active blob deletion fails on composite setups
[
https://issues.apache.org/jira/browse/OAK-7610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-7610:
Description:
Because there are two CheckpointManager MBeans present on the composite
nodestore setup, active blob deletion fails with the following message:
{code}
Unable to get checkpoint mbean. Multiple services of required type found.
{code}
The two Mbeans:
{code}
Composite node store checkpoint management (CheckpointManager)
Document node store checkpoint management (CheckpointManager)
{code}
Following condition is not satisfied on this setup:
{code}
if (services.size() == 1) {
return services.get(0).getOldestCheckpointCreationTimestamp();
{code}
https://github.com/apache/jackrabbit-oak/blob/5ef49f07ea244907dc1f4458ebee269f0437d934/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/ActiveDeletedBlobCollectorMBeanImpl.java#L327-L330
was:
Because there are two CheckpointManager MBeans present on the composite
nodestore setup, active blob deletion fails with the following message:
{code}
Unable to get checkpoint mbean. Multiple services of required type found.
{code}
The two Mbeans:
{code}
Composite node store checkpoint management (CheckpointManager)
Document node store checkpoint management (CheckpointManager)
{code}
Following condition is not satisfied on this setup:
{code}
if (services.size() == 1) {
return services.get(0).getOldestCheckpointCreationTimestamp();
{code}
> Active blob deletion fails on composite setups
> --
>
> Key: OAK-7610
> URL: https://issues.apache.org/jira/browse/OAK-7610
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: composite, indexing, lucene
>Affects Versions: 1.9.5
>Reporter: Paul Chibulcuteanu
>Priority: Major
> Fix For: 1.9.6
>
>
> Because there are two CheckpointManager MBeans present on the composite
> nodestore setup, active blob deletion fails with the following message:
> {code}
> Unable to get checkpoint mbean. Multiple services of required type found.
> {code}
> The two Mbeans:
> {code}
> Composite node store checkpoint management (CheckpointManager)
> Document node store checkpoint management (CheckpointManager)
> {code}
> Following condition is not satisfied on this setup:
> {code}
> if (services.size() == 1) {
> return services.get(0).getOldestCheckpointCreationTimestamp();
> {code}
> https://github.com/apache/jackrabbit-oak/blob/5ef49f07ea244907dc1f4458ebee269f0437d934/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/ActiveDeletedBlobCollectorMBeanImpl.java#L327-L330
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7610) Active blob deletion fails on composite setups
Paul Chibulcuteanu created OAK-7610:
---
Summary: Active blob deletion fails on composite setups
Key: OAK-7610
URL: https://issues.apache.org/jira/browse/OAK-7610
Project: Jackrabbit Oak
Issue Type: Bug
Components: composite, indexing, lucene
Affects Versions: 1.9.5
Reporter: Paul Chibulcuteanu
Fix For: 1.9.6
Because there are two CheckpointManager MBeans present on the composite
nodestore setup, active blob deletion fails with the following message:
{code}
Unable to get checkpoint mbean. Multiple services of required type found.
{code}
The two Mbeans:
{code}
Composite node store checkpoint management (CheckpointManager)
Document node store checkpoint management (CheckpointManager)
{code}
Following condition is not satisfied on this setup:
{code}
if (services.size() == 1) {
return services.get(0).getOldestCheckpointCreationTimestamp();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-6844) Consistency checker Directory value is always ":data"
Paul Chibulcuteanu created OAK-6844:
---
Summary: Consistency checker Directory value is always ":data"
Key: OAK-6844
URL: https://issues.apache.org/jira/browse/OAK-6844
Project: Jackrabbit Oak
Issue Type: Improvement
Components: lucene
Affects Versions: 1.7.9
Reporter: Paul Chibulcuteanu
Priority: Minor
Fix For: 1.8
When running a _fullCheck_ consistency check from the Lucene Index statistics
MBean, the _Directory_ results is always _:data_
See below:
{code}
/oak:index/lucene => VALID
Size : 42.3 MB
Directory : :data
Size : 42.3 MB
Num docs : 159132
CheckIndex status : true
Time taken : 3.544 s
{code}
I'm not really sure what information should be put here, but the _:data_ value
is confusing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-6534) Compute indexPaths from index definitions json
[
https://issues.apache.org/jira/browse/OAK-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119499#comment-16119499
]
Paul Chibulcuteanu edited comment on OAK-6534 at 8/9/17 6:54 AM:
-
[~chetanm], yes this would be fine. This way, if one wants to reindex
everything present in the --index-definitions-file then --index-paths should
not be provided.
was (Author: chibulcu):
[~chetanm], yes this would be fine. This way, if one wants to reindex
everything present in the _--index-definitions-file_ then _--index-paths_
should not be provided.
> Compute indexPaths from index definitions json
> --
>
> Key: OAK-6534
> URL: https://issues.apache.org/jira/browse/OAK-6534
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> Currently while adding/updating indexes via {{--index-definitions-file}}
> (OAK-6471) the index paths are always determined by {{--index-paths}} option.
> If there are more index definitions present in the json file then those would
> be ignored.
> To avoid confusion following approach should be implemented
> * If {{--index-paths}} is specified then use that
> * If not and {{--index-definitions-file}} is provided then compute index
> paths from that
> * If both are specified then {{--index-paths}} takes precendence (no merging
> done)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6534) Compute indexPaths from index definitions json
[
https://issues.apache.org/jira/browse/OAK-6534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16119499#comment-16119499
]
Paul Chibulcuteanu commented on OAK-6534:
-
[~chetanm], yes this would be fine. This way, if one wants to reindex
everything present in the _--index-definitions-file_ then _--index-paths_
should not be provided.
> Compute indexPaths from index definitions json
> --
>
> Key: OAK-6534
> URL: https://issues.apache.org/jira/browse/OAK-6534
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.8
>
>
> Currently while adding/updating indexes via {{--index-definitions-file}}
> (OAK-6471) the index paths are always determined by {{--index-paths}} option.
> If there are more index definitions present in the json file then those would
> be ignored.
> To avoid confusion following approach should be implemented
> * If {{--index-paths}} is specified then use that
> * If not and {{--index-definitions-file}} is provided then compute index
> paths from that
> * If both are specified then {{--index-paths}} takes precendence (no merging
> done)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6409) Oak-run indexing: improved (user friendly) output
[ https://issues.apache.org/jira/browse/OAK-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091414#comment-16091414 ] Paul Chibulcuteanu commented on OAK-6409: - [~chetanm], the logs/output look good IMO and everything requested is implemented. > Oak-run indexing: improved (user friendly) output > - > > Key: OAK-6409 > URL: https://issues.apache.org/jira/browse/OAK-6409 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: indexing >Reporter: Thomas Mueller >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > The oak-run indexing (OAK-6081) output should be human readable, and if > possible minimal. Detailed output should be written to a log file, but stdout > should be easy for a user to understand. For example some header info when > starting, where to find the detailed output, then one line every 3 seconds > about the progress (in %, number of nodes read, ETA), and when done some info > on what to do next. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6377) Text extraction with oak-run and tika requires fake string in the command to work
[
https://issues.apache.org/jira/browse/OAK-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-6377:
Description:
According to the [text-extraction documentation|
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
there is currently no need to set a segmentstore for the extract command.
{code}
java -cp tika-app-1.15.jar:oak-run.jar \
org.apache.jackrabbit.oak.run.Main tika \
--data-file binary-stats.csv \
--store-path ./store \
--fds-path /path/to/datastore --extract
{code}
The command parser expects a string option so the workaround for this would be
to provide a fake string at the end.
e.g:
{code}
java -cp .. --extract fakestore
{code}
was:
According to the [text-extraction documentation|
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
there is currently no need to set a segmentstore for the extract command.
{code}
java -cp tika-app-1.15.jar:oak-run.jar \
org.apache.jackrabbit.oak.run.Main tika \
--data-file binary-stats.csv \
--store-path ./store \
--fds-path /path/to/datastore extract
{code}
The command parser expects a string option so the workaround for this would be
to provide a fake string at the end.
e.g:
{code}
java -cp .. --extract fakestore
{code}
> Text extraction with oak-run and tika requires fake string in the command to
> work
> -
>
> Key: OAK-6377
> URL: https://issues.apache.org/jira/browse/OAK-6377
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene, run
>Affects Versions: 1.8, 1.7.2
>Reporter: Paul Chibulcuteanu
>Priority: Minor
>
> According to the [text-extraction documentation|
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
> there is currently no need to set a segmentstore for the extract command.
> {code}
> java -cp tika-app-1.15.jar:oak-run.jar \
> org.apache.jackrabbit.oak.run.Main tika \
> --data-file binary-stats.csv \
> --store-path ./store \
> --fds-path /path/to/datastore --extract
> {code}
> The command parser expects a string option so the workaround for this would
> be to provide a fake string at the end.
> e.g:
> {code}
> java -cp .. --extract fakestore
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6377) Text extraction with oak-run and tika requires fake string in the command to work
[
https://issues.apache.org/jira/browse/OAK-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Chibulcuteanu updated OAK-6377:
Description:
According to the [text-extraction documentation|
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
there is currently no need to set a segmentstore for the extract command.
{code}
java -cp tika-app-1.15.jar:oak-run.jar \
org.apache.jackrabbit.oak.run.Main tika \
--data-file binary-stats.csv \
--store-path ./store \
--fds-path /path/to/datastore extract
{code}
The command parser expects a string option so the workaround for this would be
to provide a fake string at the end.
e.g:
{code}
java -cp .. --extract fakestore
{code}
was:
According to the [text-extraction documentation|
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
there is currently no need to set a segmentstore for the extract command.
The command parser expects a string option so the workaround for this would be
to provide a fake string at the end.
e.g:
{code}
java -cp .. --extract fakestore
{code}
> Text extraction with oak-run and tika requires fake string in the command to
> work
> -
>
> Key: OAK-6377
> URL: https://issues.apache.org/jira/browse/OAK-6377
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene, run
>Affects Versions: 1.8, 1.7.2
>Reporter: Paul Chibulcuteanu
>Priority: Minor
>
> According to the [text-extraction documentation|
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
> there is currently no need to set a segmentstore for the extract command.
> {code}
> java -cp tika-app-1.15.jar:oak-run.jar \
> org.apache.jackrabbit.oak.run.Main tika \
> --data-file binary-stats.csv \
> --store-path ./store \
> --fds-path /path/to/datastore extract
> {code}
> The command parser expects a string option so the workaround for this would
> be to provide a fake string at the end.
> e.g:
> {code}
> java -cp .. --extract fakestore
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6377) Text extraction with oak-run and tika requires fake string in the command to work
Paul Chibulcuteanu created OAK-6377:
---
Summary: Text extraction with oak-run and tika requires fake
string in the command to work
Key: OAK-6377
URL: https://issues.apache.org/jira/browse/OAK-6377
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene, run
Affects Versions: 1.7.2, 1.8
Reporter: Paul Chibulcuteanu
Priority: Minor
According to the [text-extraction documentation|
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-doc/src/site/markdown/query/pre-extract-text.md#step-3---perform-the-text-extraction]
there is currently no need to set a segmentstore for the extract command.
The command parser expects a string option so the workaround for this would be
to provide a fake string at the end.
e.g:
{code}
java -cp .. --extract fakestore
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6341) oak-run redirects reindexing info to STDERR
Paul Chibulcuteanu created OAK-6341: --- Summary: oak-run redirects reindexing info to STDERR Key: OAK-6341 URL: https://issues.apache.org/jira/browse/OAK-6341 Project: Jackrabbit Oak Issue Type: Bug Components: lucene, run Affects Versions: 1.7.1, 1.8 Reporter: Paul Chibulcuteanu Priority: Minor Reindexing run via oak-run tool redirects all the important reindexing information to STDERR. This is due to https://github.com/apache/jackrabbit-oak/blob/trunk/oak-run/src/main/resources/logback.xml#L55-L57 In this particular case, the information should be redirected to STDOUT since it is important information related to reindexing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6117) Enable lucene indexing via oak-run
[
https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022427#comment-16022427
]
Paul Chibulcuteanu edited comment on OAK-6117 at 5/24/17 8:18 AM:
--
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time. See: OAK-6260
Currently there is no information about reindexing duration when using oak-run
tool/
was (Author: chibulcu):
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time. See: OAK-6260
> Enable lucene indexing via oak-run
> --
>
> Key: OAK-6117
> URL: https://issues.apache.org/jira/browse/OAK-6117
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: lucene, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.8, 1.7.1
>
>
> This is first step of OAK-6081 where we need to enable performing Lucene
> indexing via oak-run. The indexing approach would be very close to what we
> already have with minimal changes done.
> Once this is done it should be possible to connect oak-run against an
> existing setup and let it reindexing specific set of indexes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6117) Enable lucene indexing via oak-run
[
https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022427#comment-16022427
]
Paul Chibulcuteanu edited comment on OAK-6117 at 5/24/17 8:17 AM:
--
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time. See: OAK-6260
was (Author: chibulcu):
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time.
> Enable lucene indexing via oak-run
> --
>
> Key: OAK-6117
> URL: https://issues.apache.org/jira/browse/OAK-6117
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: lucene, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.8, 1.7.1
>
>
> This is first step of OAK-6081 where we need to enable performing Lucene
> indexing via oak-run. The indexing approach would be very close to what we
> already have with minimal changes done.
> Once this is done it should be possible to connect oak-run against an
> existing setup and let it reindexing specific set of indexes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6117) Enable lucene indexing via oak-run
[
https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022427#comment-16022427
]
Paul Chibulcuteanu edited comment on OAK-6117 at 5/24/17 8:15 AM:
--
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time.
was (Author: chibulcu):
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time:
https://jira.corp.adobe.com/browse/GRANITE-17329
> Enable lucene indexing via oak-run
> --
>
> Key: OAK-6117
> URL: https://issues.apache.org/jira/browse/OAK-6117
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: lucene, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.8, 1.7.1
>
>
> This is first step of OAK-6081 where we need to enable performing Lucene
> indexing via oak-run. The indexing approach would be very close to what we
> already have with minimal changes done.
> Once this is done it should be possible to connect oak-run against an
> existing setup and let it reindexing specific set of indexes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6117) Enable lucene indexing via oak-run
[
https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16022427#comment-16022427
]
Paul Chibulcuteanu commented on OAK-6117:
-
[~chetanm], it would be a good improvement to display the reindexing time in
the following format:
{code}
Reindexing completed for indexes: [/oak:index/lucene*(137748)] in 35.96 s
(35958 ms)
{code}
including the total time in ms. This way it would be consistent with current
way of displaying the reindexing total time:
https://jira.corp.adobe.com/browse/GRANITE-17329
> Enable lucene indexing via oak-run
> --
>
> Key: OAK-6117
> URL: https://issues.apache.org/jira/browse/OAK-6117
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: lucene, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.8, 1.7.1
>
>
> This is first step of OAK-6081 where we need to enable performing Lucene
> indexing via oak-run. The indexing approach would be very close to what we
> already have with minimal changes done.
> Once this is done it should be possible to connect oak-run against an
> existing setup and let it reindexing specific set of indexes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (OAK-6117) Enable lucene indexing via oak-run
[
https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017287#comment-16017287
]
Paul Chibulcuteanu edited comment on OAK-6117 at 5/19/17 11:56 AM:
---
[~chetanm], in the current form, does this mean that the repository needs to be
offline for both mongo and tar?
Later edit: In OAK-6081 it is mentioned that for Documentstore
{quote}
DocumentNodeStore setup it would be possible to connect oak-run to a live
cluster and it would take care of indexing
{quote}
was (Author: chibulcu):
[~chetanm], in the current form, does this mean that the repository needs to be
offline for both mongo and tar?
> Enable lucene indexing via oak-run
> --
>
> Key: OAK-6117
> URL: https://issues.apache.org/jira/browse/OAK-6117
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: lucene, run
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: 1.8, 1.7.1
>
>
> This is first step of OAK-6081 where we need to enable performing Lucene
> indexing via oak-run. The indexing approach would be very close to what we
> already have with minimal changes done.
> Once this is done it should be possible to connect oak-run against an
> existing setup and let it reindexing specific set of indexes
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (OAK-6117) Enable lucene indexing via oak-run
[ https://issues.apache.org/jira/browse/OAK-6117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017287#comment-16017287 ] Paul Chibulcuteanu commented on OAK-6117: - [~chetanm], in the current form, does this mean that the repository needs to be offline for both mongo and tar? > Enable lucene indexing via oak-run > -- > > Key: OAK-6117 > URL: https://issues.apache.org/jira/browse/OAK-6117 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene, run >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.1 > > > This is first step of OAK-6081 where we need to enable performing Lucene > indexing via oak-run. The indexing approach would be very close to what we > already have with minimal changes done. > Once this is done it should be possible to connect oak-run against an > existing setup and let it reindexing specific set of indexes -- This message was sent by Atlassian JIRA (v6.3.15#6346)
