[jira] [Commented] (OAK-3606) Improvements for IndexStatsMBean usage
[ https://issues.apache.org/jira/browse/OAK-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247284#comment-15247284 ] Andrei Dulvac commented on OAK-3606: Any ETA on this ticket? > Improvements for IndexStatsMBean usage > -- > > Key: OAK-3606 > URL: https://issues.apache.org/jira/browse/OAK-3606 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.3.9 >Reporter: Thierry Ygé > Attachments: adding_new_MBean.patch, > new_mbean_interface_and_implementation.patch > > > When running integration tests, it is common to have the need to wait for the > async indexes to have been executed. So that the test can successfully > validate operations that depend on the search result. > With the current IndexStatsMBean implementation it cannot return the start > time of the last successful indexing. It provide a "LastIndexedTime" which is > not sufficient to know if changes made recently are now indexed. > The idea is to set the start time as value of a new attribute (i.e > "StartLastSuccessIndexedTime") to the IndexStatsMBean. > Then create a new Mbean that calculate from all existing IndexStatsMBean (as > multiple are possible now) the oldest "StartLastSuccessIndexedTime". > That will allow integration tests to be able to wait until that oldest > "StartLastSuccessIndexedTime" is greater than the time it started to wait. > Attached is a sample patch containing the necessary changes (for a Oak core > 1.4.0-SNAPSHOT). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247280#comment-15247280
]
Andrei Dulvac commented on OAK-3694:
[~edivad], this is still an issue. Should this be reopened for 1.6?
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119403#comment-15119403
]
Andrei Dulvac commented on OAK-3694:
In my opinion, this logic should be delegated to oak and provided to users, as
this logic could change at any time. Also, I think it's ok to rely on querying
to see if a node was indexed, but does not seem sensible to me to ask the
client to do that.
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3694) As a user, I want to know when a node that I've created has been indexed.
[
https://issues.apache.org/jira/browse/OAK-3694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119403#comment-15119403
]
Andrei Dulvac edited comment on OAK-3694 at 1/27/16 3:10 PM:
-
In my opinion, this logic should be delegated to oak and provided to users, as
this logic could change at any time. Also, I think it's ok to rely on querying
to see if a node was indexed in the internal implementation, but does not seem
sensible to me to ask the client to do that.
was (Author: andrei.dulvac):
In my opinion, this logic should be delegated to oak and provided to users, as
this logic could change at any time. Also, I think it's ok to rely on querying
to see if a node was indexed, but does not seem sensible to me to ask the
client to do that.
> As a user, I want to know when a node that I've created has been indexed.
> -
>
> Key: OAK-3694
> URL: https://issues.apache.org/jira/browse/OAK-3694
> Project: Jackrabbit Oak
> Issue Type: Story
>Reporter: Valentin Olteanu
>Assignee: Chetan Mehrotra
> Fix For: 1.4
>
>
> As a user, I want to know when a node that I've created has been indexed so
> that I can start using it.
> Generalization: As a user, I want to know when everything created before
> timestamp T0 has been indexed.
> Ideal solution: MBean operation {{bool isIndexedBefore(long timestamp)}} that
> returns {{true}} if everything created before {{timestamp}} has been indexed
> (by all indexers).
> Current options:
> # check IndexStatsMBean for Start and Done to determine if a cycle has
> started after adding the node and has finished. Issue: there can be multiple
> async indexers. OAK-3606 proposes a solution.
> # add a node and search for it until it is retrieved. Issue: must add
> different nodes for different indexers and wait for all.
> These options are not precise (give false positives) and are not resilient to
> changes in indexing strategy (e.g. adding one more indexer breaks the
> checks).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulvac updated OAK-2723:
---
Description:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much. That means that through the
{{readers}} field, there's a reference to these _graphs_, which means they
can't be GC'ed.
The construction of {{FileStore}} is from oak-run:
bq. FileStore store = new FileStore(directory, 256, TAR_STORAGE_MEMORY_MAPPED);
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
was:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much. That means that through the
{{readers}} field, there's a reference to these _graphs_, which means they
can't be GC'ed.
The construction of {fileStore}} is from oak-run:
bq. FileStore store = new FileStore(directory, 256, TAR_STORAGE_MEMORY_MAPPED);
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Fix For: 1.3.0
>
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much. That means that through
> the {{readers}} field, there's a reference to these _graphs_, which means
> they can't be GC'ed.
> The construction of {{FileStore}} is from oak-run:
> bq. FileStore store = new FileStore(directory, 256,
> TAR_STORAGE_MEMORY_MAPPED);
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483072#comment-14483072
]
Andrei Dulvac edited comment on OAK-2723 at 4/7/15 12:21 PM:
-
Attached patch created with {{git format-patch HEAD~1}}
Apply with {{patch -p1 -i 0001-TarReader-fix-for-precomputed-graph.patch}}
was (Author: andrei.dulvac):
Attached patch created with {{git format-patch HEAD~1}}
Apply with {{patch -p1 -i 0001-fixes-FACILITIES-97.patch}}
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Fix For: 1.3.0
>
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much. That means that through
> the {{readers}} field, there's a reference to these _graphs_, which means
> they can't be GC'ed.
> The construction of {fileStore}} is from oak-run:
> bq. FileStore store = new FileStore(directory, 256,
> TAR_STORAGE_MEMORY_MAPPED);
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulvac updated OAK-2723:
---
Description:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much. That means that through the
{{readers}} field, there's a reference to these _graphs_, which means they
can't be GC'ed.
The construction of {fileStore}} is from oak-run:
bq. FileStore store = new FileStore(directory, 256, TAR_STORAGE_MEMORY_MAPPED);
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
was:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much. That means that through the
{{readers}} field, there's a reference to these _graphs_, which means they
can't be GC'ed.
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much. That means that through
> the {{readers}} field, there's a reference to these _graphs_, which means
> they can't be GC'ed.
> The construction of {fileStore}} is from oak-run:
> bq. FileStore store = new FileStore(directory, 256,
> TAR_STORAGE_MEMORY_MAPPED);
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulvac updated OAK-2723:
---
Description:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much. That means that through the
{{readers}} field, there's a reference to these _graphs_, which means they
can't be GC'ed.
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
was:
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much.
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much. That means that through
> the {{readers}} field, there's a reference to these _graphs_, which means
> they can't be GC'ed.
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulvac updated OAK-2723:
---
Attachment: 0001-TarReader-fix-for-precomputed-graph.patch
Attached patch created with {{git format-patch HEAD~1}}
Apply with {{patch -p1 -i 0001-fixes-FACILITIES-97.patch}}
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much.
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
[
https://issues.apache.org/jira/browse/OAK-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483073#comment-14483073
]
Andrei Dulvac commented on OAK-2723:
If you need a memory dump, I can provide that offline, it's not possible (or
desirable) to attach it in jira.
> FileStore does not scale because of precomputed graph on TarReader
> --
>
> Key: OAK-2723
> URL: https://issues.apache.org/jira/browse/OAK-2723
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-core
>Affects Versions: 1.1.8
>Reporter: Andrei Dulvac
> Attachments: 0001-TarReader-fix-for-precomputed-graph.patch
>
>
> The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
> file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
> {{TarReader}} for each.
> The problem is {{TarReader}} keeps a reference to a precomputed _graph_
> {{ByteBuffer}}, which is not really used that much.
> The effect is you need more that 6GB of Ram just to instantiate the
> {{FileStore}} object.
> The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2723) FileStore does not scale because of precomputed graph on TarReader
Andrei Dulvac created OAK-2723:
--
Summary: FileStore does not scale because of precomputed graph on
TarReader
Key: OAK-2723
URL: https://issues.apache.org/jira/browse/OAK-2723
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-core
Affects Versions: 1.1.8
Reporter: Andrei Dulvac
The {{FileStore}} keeps a reference to all {{TarReader}} object, one per each
file. In my test, for an ~350 Gb repository, that was ~1100 tar files, with a
{{TarReader}} for each.
The problem is {{TarReader}} keeps a reference to a precomputed _graph_
{{ByteBuffer}}, which is not really used that much.
The effect is you need more that 6GB of Ram just to instantiate the
{{FileStore}} object.
The attached patch fixes this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2098) oak-tarmk-failover doesn't compile - "cannot find symbol" in SegmentLoaderHandler
[
https://issues.apache.org/jira/browse/OAK-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133743#comment-14133743
]
Andrei Dulvac commented on OAK-2098:
Ping [~baedke] because 41916b6 introduced the issue.
> oak-tarmk-failover doesn't compile - "cannot find symbol" in
> SegmentLoaderHandler
> -
>
> Key: OAK-2098
> URL: https://issues.apache.org/jira/browse/OAK-2098
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.1
> Environment: java 7 or 6
>Reporter: Andrei Dulvac
> Labels: failover, oak
>
> `$ mvn clean install` in the root of the project fails because
> oak-tarmk-failover fails to build.
> Introduced by 41916b6. Ln 104:
> {code}
> catch (FileStore.FileStoreCorruptException e) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-2098) oak-tarmk-failover doesn't compile - "cannot find symbol" in SegmentLoaderHandler
Andrei Dulvac created OAK-2098:
--
Summary: oak-tarmk-failover doesn't compile - "cannot find symbol"
in SegmentLoaderHandler
Key: OAK-2098
URL: https://issues.apache.org/jira/browse/OAK-2098
Project: Jackrabbit Oak
Issue Type: Bug
Components: run
Affects Versions: 1.1
Environment: java 7 or 6
Reporter: Andrei Dulvac
`$ mvn clean install` in the root of the project fails because
oak-tarmk-failover fails to build.
Introduced by 41916b6. Ln 104:
{code}
catch (FileStore.FileStoreCorruptException e) {
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2012) oak run benchmark has bad imports
[
https://issues.apache.org/jira/browse/OAK-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084619#comment-14084619
]
Andrei Dulvac commented on OAK-2012:
[~anchela], it looks like you've changed those.
> oak run benchmark has bad imports
> -
>
> Key: OAK-2012
> URL: https://issues.apache.org/jira/browse/OAK-2012
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.1
>Reporter: Andrei Dulvac
> Labels: benchmark
>
> The oak run benchmark doesn't work for mongo anymore, there are wrong imports
> for EveryonePrincipal, which was moved from
> org/apache/jackrabbit/oak/security/principal/ to
> org/apache/jackrabbit/oak/spi/security/principal by OAK-90 without changing
> the imports in some benchmark tests:
> {code}
> java -jar target/oak-run*-SNAPSHOT-oak.jar benchmark GetNodeWithAdmin
> Oak-MongoNS
> Apache Jackrabbit Oak 1.1-SNAPSHOT
> # GetNodeWithAdmin C min 10% 50% 90% max
> N
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/jackrabbit/core/security/principal/EveryonePrincipal
> at
> org.apache.jackrabbit.oak.benchmark.GetNodeTest.beforeSuite(GetNodeTest.java:75)
> at
> org.apache.jackrabbit.oak.benchmark.AbstractTest.setUp(AbstractTest.java:113)
> at
> org.apache.jackrabbit.oak.benchmark.GetNodeTest.setUp(GetNodeTest.java:34)
> at
> org.apache.jackrabbit.oak.benchmark.AbstractTest.runTest(AbstractTest.java:151)
> at
> org.apache.jackrabbit.oak.benchmark.AbstractTest.run(AbstractTest.java:138)
> at
> org.apache.jackrabbit.oak.benchmark.GetNodeTest.run(GetNodeTest.java:34)
> at
> org.apache.jackrabbit.oak.benchmark.BenchmarkRunner.main(BenchmarkRunner.java:296)
> at org.apache.jackrabbit.oak.run.Main.main(Main.java:122)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.jackrabbit.core.security.principal.EveryonePrincipal
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
> ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (OAK-2012) oak run benchmark has bad imports
Andrei Dulvac created OAK-2012:
--
Summary: oak run benchmark has bad imports
Key: OAK-2012
URL: https://issues.apache.org/jira/browse/OAK-2012
Project: Jackrabbit Oak
Issue Type: Bug
Components: run
Affects Versions: 1.1
Reporter: Andrei Dulvac
The oak run benchmark doesn't work for mongo anymore, there are wrong imports
for EveryonePrincipal, which was moved from
org/apache/jackrabbit/oak/security/principal/ to
org/apache/jackrabbit/oak/spi/security/principal by OAK-90 without changing the
imports in some benchmark tests:
{code}
java -jar target/oak-run*-SNAPSHOT-oak.jar benchmark GetNodeWithAdmin
Oak-MongoNS
Apache Jackrabbit Oak 1.1-SNAPSHOT
# GetNodeWithAdmin C min 10% 50% 90% max
N
Exception in thread "main" java.lang.NoClassDefFoundError:
org/apache/jackrabbit/core/security/principal/EveryonePrincipal
at
org.apache.jackrabbit.oak.benchmark.GetNodeTest.beforeSuite(GetNodeTest.java:75)
at
org.apache.jackrabbit.oak.benchmark.AbstractTest.setUp(AbstractTest.java:113)
at
org.apache.jackrabbit.oak.benchmark.GetNodeTest.setUp(GetNodeTest.java:34)
at
org.apache.jackrabbit.oak.benchmark.AbstractTest.runTest(AbstractTest.java:151)
at
org.apache.jackrabbit.oak.benchmark.AbstractTest.run(AbstractTest.java:138)
at
org.apache.jackrabbit.oak.benchmark.GetNodeTest.run(GetNodeTest.java:34)
at
org.apache.jackrabbit.oak.benchmark.BenchmarkRunner.main(BenchmarkRunner.java:296)
at org.apache.jackrabbit.oak.run.Main.main(Main.java:122)
Caused by: java.lang.ClassNotFoundException:
org.apache.jackrabbit.core.security.principal.EveryonePrincipal
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 8 more
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
