[jira] [Commented] (OAK-7256) Query: option to wait for indexes to be updated
[
https://issues.apache.org/jira/browse/OAK-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361788#comment-16361788
]
Chetan Mehrotra commented on OAK-7256:
--
[~edivad] The issue you are referring to is OAK-3606
> Query: option to wait for indexes to be updated
> ---
>
> Key: OAK-7256
> URL: https://issues.apache.org/jira/browse/OAK-7256
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Priority: Minor
> Fix For: 1.10
>
>
> Sometimes (rarely, but still) queries should include the very latest changes,
> even if the index is updated asynchronously. For example when running unit
> test: data is added, and then a query is run to check if the data is there.
> The problem with asynchronous indexes is, you don't know exactly how long you
> have to wait. Often the index is updated quickly, and sometimes it takes a
> few seconds.
> What about extending the query syntax as follows:
> Wait for all indexes (no matter which index is used for this query) - this
> would be used rarely, just for testing:
> {noformat}
> /jcr:root/*
> option(wait for all indexes timeout 60)
> {noformat}
> Wait for just those indexes (well, usually it's just one, but sometimes it's
> multiple) that are needed for the given query. This query could also be used
> in an application that strictly needs the very latest results, even for
> fulltext queries. The "timeout" would mean "wait at most 10 seconds, and if
> not up-to-date then throw an exeption", while "max 10" would mean "wait at
> most 10 seconds, but still run the query in any case".
> {noformat}
> /jcr:root/content//*[jcr:contains(., 'hello')]
> option(wait for indexes max 10)
> {noformat}
> The query would wait, and once the indexes are up-to-date, return the
> requested result.
> So the syntax is (both SQL-2 and XPath):
> {noformat}
> option(wait for [all] indexes
> { max | timeout }
> [, ] )
> {noformat}
> So other options can also be used (option traversal fail,...).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7260) oak-run throws IllegalStateException in backup mode
[
https://issues.apache.org/jira/browse/OAK-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Ryan updated OAK-7260:
---
Description:
I try to run {{oak-run}} to back up my repository according to the [online
documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
this:
{{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
./repo.bak}}
When I do this I get an {{IllegalStateException}}:
{{java.lang.IllegalStateException: Attempt to read external blob with
}}{{blobId }}
{{[ 3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188 ]}}
{{without specifying BlobStore}}
It is unclear how to proceed, based on the documentation. It doesn't tell me
how to specify a blob store path. Expected behavior should be:
# Tool help gives correct options for correct usage
# Online documentation gives correct options for correct usage
# Tool handles exception gracefully instead of throwing stack trace
Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
custom configuration. I tested with {{oak-run}} built from sources as well as
multiple downloaded versions, all gave the same behavior. Path to repository
is correct and I verified the blob actually does exist in the blob store.
was:
I try to run {{oak-run}} to back up my repository according to the [online
documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
this:
{{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
./repo.bak}}
When I do this I get an {{IllegalStateException}}:
{{java.lang.IllegalStateException: Attempt to read external blob
with}}{{blobId}}{{[3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188]
without}}{{specifying BlobStore}}
It is unclear how to proceed, based on the documentation. It doesn't tell me
how to specify a blob store path. Expected behavior should be:
# Tool help gives correct options for correct usage
# Online documentation gives correct options for correct usage
# Tool handles exception gracefully instead of throwing stack trace
Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
custom configuration. I tested with {{oak-run}} built from sources as well as
multiple downloaded versions, all gave the same behavior. Path to repository
is correct and I verified the blob actually does exist in the blob store.
> oak-run throws IllegalStateException in backup mode
> ---
>
> Key: OAK-7260
> URL: https://issues.apache.org/jira/browse/OAK-7260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Matt Ryan
>Priority: Minor
> Attachments: OAK-7260-stacktrace.txt
>
>
> I try to run {{oak-run}} to back up my repository according to the [online
> documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
> this:
> {{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
> ./repo.bak}}
> When I do this I get an {{IllegalStateException}}:
> {{java.lang.IllegalStateException: Attempt to read external blob with
> }}{{blobId }}
> {{[ 3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188
> ]}}
> {{without specifying BlobStore}}
>
> It is unclear how to proceed, based on the documentation. It doesn't tell me
> how to specify a blob store path. Expected behavior should be:
> # Tool help gives correct options for correct usage
> # Online documentation gives correct options for correct usage
> # Tool handles exception gracefully instead of throwing stack trace
>
> Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
> custom configuration. I tested with {{oak-run}} built from sources as well
> as multiple downloaded versions, all gave the same behavior. Path to
> repository is correct and I verified the blob actually does exist in the blob
> store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7260) oak-run throws IllegalStateException in backup mode
[
https://issues.apache.org/jira/browse/OAK-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361632#comment-16361632
]
Matt Ryan commented on OAK-7260:
I also found documentation
[here|https://jackrabbit.apache.org/oak/docs/nodestore/segment/overview.html#backup]
that differs from the source I mentioned in the description. Which one is
official? Should one be retired or made to point to the other?
> oak-run throws IllegalStateException in backup mode
> ---
>
> Key: OAK-7260
> URL: https://issues.apache.org/jira/browse/OAK-7260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Matt Ryan
>Priority: Minor
> Attachments: OAK-7260-stacktrace.txt
>
>
> I try to run {{oak-run}} to back up my repository according to the [online
> documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
> this:
> {{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
> ./repo.bak}}
> When I do this I get an {{IllegalStateException}}:
> {{java.lang.IllegalStateException: Attempt to read external blob
> with}}{{blobId}}{{[3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188]
> without}}{{specifying BlobStore}}
>
> It is unclear how to proceed, based on the documentation. It doesn't tell me
> how to specify a blob store path. Expected behavior should be:
> # Tool help gives correct options for correct usage
> # Online documentation gives correct options for correct usage
> # Tool handles exception gracefully instead of throwing stack trace
>
> Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
> custom configuration. I tested with {{oak-run}} built from sources as well
> as multiple downloaded versions, all gave the same behavior. Path to
> repository is correct and I verified the blob actually does exist in the blob
> store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7260) oak-run throws IllegalStateException in backup mode
[
https://issues.apache.org/jira/browse/OAK-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Ryan updated OAK-7260:
---
Attachment: OAK-7260-stacktrace.txt
> oak-run throws IllegalStateException in backup mode
> ---
>
> Key: OAK-7260
> URL: https://issues.apache.org/jira/browse/OAK-7260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Matt Ryan
>Priority: Minor
> Attachments: OAK-7260-stacktrace.txt
>
>
> I try to run {{oak-run}} to back up my repository according to the [online
> documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
> this:
> {{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
> ./repo.bak}}
> When I do this I get an {{IllegalStateException}}:
> {{java.lang.IllegalStateException: Attempt to read external blob
> with}}{{blobId}}{{[3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188]
> without}}{{specifying BlobStore}}
>
> It is unclear how to proceed, based on the documentation. It doesn't tell me
> how to specify a blob store path. Expected behavior should be:
> # Tool help gives correct options for correct usage
> # Online documentation gives correct options for correct usage
> # Tool handles exception gracefully instead of throwing stack trace
>
> Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
> custom configuration. I tested with {{oak-run}} built from sources as well
> as multiple downloaded versions, all gave the same behavior. Path to
> repository is correct and I verified the blob actually does exist in the blob
> store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7260) oak-run throws IllegalStateException in backup mode
[
https://issues.apache.org/jira/browse/OAK-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361629#comment-16361629
]
Matt Ryan commented on OAK-7260:
Attached stack trace [^OAK-7260-stacktrace.txt].
> oak-run throws IllegalStateException in backup mode
> ---
>
> Key: OAK-7260
> URL: https://issues.apache.org/jira/browse/OAK-7260
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: oak-run
>Reporter: Matt Ryan
>Priority: Minor
> Attachments: OAK-7260-stacktrace.txt
>
>
> I try to run {{oak-run}} to back up my repository according to the [online
> documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
> this:
> {{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
> ./repo.bak}}
> When I do this I get an {{IllegalStateException}}:
> {{java.lang.IllegalStateException: Attempt to read external blob
> with}}{{blobId}}{{[3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188]
> without}}{{specifying BlobStore}}
>
> It is unclear how to proceed, based on the documentation. It doesn't tell me
> how to specify a blob store path. Expected behavior should be:
> # Tool help gives correct options for correct usage
> # Online documentation gives correct options for correct usage
> # Tool handles exception gracefully instead of throwing stack trace
>
> Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
> custom configuration. I tested with {{oak-run}} built from sources as well
> as multiple downloaded versions, all gave the same behavior. Path to
> repository is correct and I verified the blob actually does exist in the blob
> store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7260) oak-run throws IllegalStateException in backup mode
Matt Ryan created OAK-7260:
--
Summary: oak-run throws IllegalStateException in backup mode
Key: OAK-7260
URL: https://issues.apache.org/jira/browse/OAK-7260
Project: Jackrabbit Oak
Issue Type: Bug
Components: oak-run
Reporter: Matt Ryan
I try to run {{oak-run}} to back up my repository according to the [online
documentation|https://jackrabbit.apache.org/oak/docs/command_line.html], like
this:
{{java -mx4g -jar oak-run-1.10-SNAPSHOT.jar backup repository/segmentstore
./repo.bak}}
When I do this I get an {{IllegalStateException}}:
{{java.lang.IllegalStateException: Attempt to read external blob
with}}{{blobId}}{{[3e15c88da9b46267141b60826c0734007c3e5a5f804c953edb0280eda680a9be#174188]
without}}{{specifying BlobStore}}
It is unclear how to proceed, based on the documentation. It doesn't tell me
how to specify a blob store path. Expected behavior should be:
# Tool help gives correct options for correct usage
# Online documentation gives correct options for correct usage
# Tool handles exception gracefully instead of throwing stack trace
Configuration: Default Oak setup with SegmentNodeStore and FileDataStore, no
custom configuration. I tested with {{oak-run}} built from sources as well as
multiple downloaded versions, all gave the same behavior. Path to repository
is correct and I verified the blob actually does exist in the blob store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7255) Upgrade jackson dependencies to version 2.9.4
[ https://issues.apache.org/jira/browse/OAK-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361243#comment-16361243 ] Julian Reschke edited comment on OAK-7255 at 2/12/18 6:58 PM: -- We probably have them in more - I didn't check yet. EDIT: Oak 1.6 seems to be a version older than the reported vulnerable range. was (Author: reschke): We probably have them in more - I didn't check yet. > Upgrade jackson dependencies to version 2.9.4 > - > > Key: OAK-7255 > URL: https://issues.apache.org/jira/browse/OAK-7255 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-http, solr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_oak_1_8 > Fix For: 1.9.0, 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7255) Upgrade jackson dependencies to version 2.9.4
[ https://issues.apache.org/jira/browse/OAK-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361243#comment-16361243 ] Julian Reschke commented on OAK-7255: - We probably have them in more - I didn't check yet. > Upgrade jackson dependencies to version 2.9.4 > - > > Key: OAK-7255 > URL: https://issues.apache.org/jira/browse/OAK-7255 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-http, solr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_oak_1_8 > Fix For: 1.9.0, 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7256) Query: option to wait for indexes to be updated
[
https://issues.apache.org/jira/browse/OAK-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361239#comment-16361239
]
Davide Giannella commented on OAK-7256:
---
there was an issue that was asking for a way to know if a node was being
indexed or not. I cannot find it any more. The main aim was probably to be used
from the testing side, where a test could add a node and ask (jmx?) whether
such node was indexed before running any query. Maybe it's an approach we could
resume thinking rather than waiting for a timeout from query which is somewhere
close to put a timeout within the test code itself.
> Query: option to wait for indexes to be updated
> ---
>
> Key: OAK-7256
> URL: https://issues.apache.org/jira/browse/OAK-7256
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
>Reporter: Thomas Mueller
>Priority: Minor
> Fix For: 1.10
>
>
> Sometimes (rarely, but still) queries should include the very latest changes,
> even if the index is updated asynchronously. For example when running unit
> test: data is added, and then a query is run to check if the data is there.
> The problem with asynchronous indexes is, you don't know exactly how long you
> have to wait. Often the index is updated quickly, and sometimes it takes a
> few seconds.
> What about extending the query syntax as follows:
> Wait for all indexes (no matter which index is used for this query) - this
> would be used rarely, just for testing:
> {noformat}
> /jcr:root/*
> option(wait for all indexes timeout 60)
> {noformat}
> Wait for just those indexes (well, usually it's just one, but sometimes it's
> multiple) that are needed for the given query. This query could also be used
> in an application that strictly needs the very latest results, even for
> fulltext queries. The "timeout" would mean "wait at most 10 seconds, and if
> not up-to-date then throw an exeption", while "max 10" would mean "wait at
> most 10 seconds, but still run the query in any case".
> {noformat}
> /jcr:root/content//*[jcr:contains(., 'hello')]
> option(wait for indexes max 10)
> {noformat}
> The query would wait, and once the indexes are up-to-date, return the
> requested result.
> So the syntax is (both SQL-2 and XPath):
> {noformat}
> option(wait for [all] indexes
> { max | timeout }
> [, ] )
> {noformat}
> So other options can also be used (option traversal fail,...).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7255) Upgrade jackson dependencies to version 2.9.4
[ https://issues.apache.org/jira/browse/OAK-7255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16361222#comment-16361222 ] Davide Giannella commented on OAK-7255: --- so we have the CVE in 1.8 and not previous versions? > Upgrade jackson dependencies to version 2.9.4 > - > > Key: OAK-7255 > URL: https://issues.apache.org/jira/browse/OAK-7255 > Project: Jackrabbit Oak > Issue Type: Task > Components: oak-http, solr >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Labels: candidate_oak_1_8 > Fix For: 1.9.0, 1.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5418) Test failure: TomcatIT.testTomcat()
[ https://issues.apache.org/jira/browse/OAK-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5418: Fix Version/s: (was: 1.4.20) 1.4.21 > Test failure: TomcatIT.testTomcat() > --- > > Key: OAK-5418 > URL: https://issues.apache.org/jira/browse/OAK-5418 > Project: Jackrabbit Oak > Issue Type: Test > Components: continuous integration, examples >Affects Versions: 1.4 >Reporter: Hudson >Assignee: Chetan Mehrotra >Priority: Major > Labels: test-failure, ubuntu > Fix For: 1.4.21 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=DOCUMENT_NS,profile=unittesting #1357 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=DOCUMENT_NS,profile=unittesting > #1357|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=DOCUMENT_NS,profile=unittesting/1357/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5566) TestFailure: remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty
[ https://issues.apache.org/jira/browse/OAK-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5566: Fix Version/s: (was: 1.4.20) 1.4.21 > TestFailure: > remote.http.handler.RemoteServerIT.testPatchLastRevisionAddMultiReferenceProperty > -- > > Key: OAK-5566 > URL: https://issues.apache.org/jira/browse/OAK-5566 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, remoting >Reporter: Hudson >Priority: Major > Labels: test-failure, ubuntu > Fix For: 1.4.21 > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting #1396 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting > #1396|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=DOCUMENT_RDB,profile=integrationTesting/1396/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5458) Test failure: RepositoryBootIT.repositoryLogin
[ https://issues.apache.org/jira/browse/OAK-5458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5458: Fix Version/s: (was: 1.4.20) 1.4.21 > Test failure: RepositoryBootIT.repositoryLogin > -- > > Key: OAK-5458 > URL: https://issues.apache.org/jira/browse/OAK-5458 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, examples >Affects Versions: 1.4, 1.5.18 >Reporter: Hudson >Assignee: Chetan Mehrotra >Priority: Major > Labels: test-failure, ubuntu > Fix For: 1.10, 1.6.10, 1.4.21 > > Attachments: unit-tests-1379.log > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.8 > (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting #1369 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.8 (latest),nsfixtures=SEGMENT_MK,profile=integrationTesting > #1369|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1369/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.8%20(latest),nsfixtures=SEGMENT_MK,profile=integrationTesting/1369/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-5470) Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2
[ https://issues.apache.org/jira/browse/OAK-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5470: Fix Version/s: (was: 1.4.20) 1.4.21 > Test failure: SecurityProviderRegistrationTest.testSecurityConfigurations2 > -- > > Key: OAK-5470 > URL: https://issues.apache.org/jira/browse/OAK-5470 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration, pojosr >Affects Versions: 1.2.23, 1.4.13 >Reporter: Hudson >Priority: Major > Labels: test-failure, windows > Fix For: 1.2.29, 1.4.21 > > Attachments: sysout-1380.log, unit-tests-build-1371.log, > unit-tests.log > > > Jenkins CI failure: > https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/ > The build Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK 1.7 > (latest),nsfixtures=SEGMENT_TAR,profile=unittesting #1371 has failed. > First failed run: [Apache Jackrabbit Oak matrix/Ubuntu Slaves=ubuntu,jdk=JDK > 1.7 (latest),nsfixtures=SEGMENT_TAR,profile=unittesting > #1371|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/] > [console > log|https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/Ubuntu%20Slaves=ubuntu,jdk=JDK%201.7%20(latest),nsfixtures=SEGMENT_TAR,profile=unittesting/1371/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6976) CopyOnWriteDirectory_Segment_Test failure
[
https://issues.apache.org/jira/browse/OAK-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-6976:
Fix Version/s: 1.4.21
> CopyOnWriteDirectory_Segment_Test failure
> -
>
> Key: OAK-6976
> URL: https://issues.apache.org/jira/browse/OAK-6976
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.18
>Reporter: Marcel Reutegger
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.2.29, 1.0.42, 1.4.21
>
>
> This test only exists in branches 1.4 and older and was introduced as part of
> OAK-5238. The test fails every now and then with (stack trace from 1.4):
> {noformat}
> java.lang.IllegalStateException: This builder does not exist: child-0
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:150)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.CopyOnWriteDirectory_Segment_Test.writeTree(CopyOnWriteDirectory_Segment_Test.java:158)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.CopyOnWriteDirectory_Segment_Test.copyOnWrite(CopyOnWriteDirectory_Segment_Test.java:111)
> {noformat}
> Please note that it fails more likely when the update.limit is set to 100,
> which is the case for the maven build.
> I also ported the test to 1.6 and running it with the new segment-tar looks
> OK. I don't know if this is because the copy-on-write or the segment-tar
> implementation is different than in 1.4.
> The affected versions are currently only set to 1.4.18, because there were no
> releases off the 1.2 and 1.0 branches since OAK-5238 was backported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-5963) Disable S3 proactive caching by default
[ https://issues.apache.org/jira/browse/OAK-5963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated OAK-5963: Fix Version/s: (was: 1.4.20) 1.4.21 > Disable S3 proactive caching by default > --- > > Key: OAK-5963 > URL: https://issues.apache.org/jira/browse/OAK-5963 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: blob >Reporter: Amit Jain >Assignee: Amit Jain >Priority: Major > Labels: candidate_oak_1_2, candidate_oak_1_4 > Fix For: 1.2.29, 1.4.21 > > > The older JR2 CachingDataStore which is extended by S3DataStore enables > proactive caching by default which leads to many binaries being downloaded > twice. This should be disabled by default in Oak. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-6976) CopyOnWriteDirectory_Segment_Test failure
[
https://issues.apache.org/jira/browse/OAK-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manfred Baedke updated OAK-6976:
Fix Version/s: (was: 1.4.20)
> CopyOnWriteDirectory_Segment_Test failure
> -
>
> Key: OAK-6976
> URL: https://issues.apache.org/jira/browse/OAK-6976
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.4.18
>Reporter: Marcel Reutegger
>Assignee: Chetan Mehrotra
>Priority: Major
> Fix For: 1.2.29, 1.0.42
>
>
> This test only exists in branches 1.4 and older and was introduced as part of
> OAK-5238. The test fails every now and then with (stack trace from 1.4):
> {noformat}
> java.lang.IllegalStateException: This builder does not exist: child-0
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:150)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:506)
> at
> org.apache.jackrabbit.oak.plugins.memory.MemoryNodeBuilder.setProperty(MemoryNodeBuilder.java:515)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.CopyOnWriteDirectory_Segment_Test.writeTree(CopyOnWriteDirectory_Segment_Test.java:158)
> at
> org.apache.jackrabbit.oak.plugins.index.lucene.CopyOnWriteDirectory_Segment_Test.copyOnWrite(CopyOnWriteDirectory_Segment_Test.java:111)
> {noformat}
> Please note that it fails more likely when the update.limit is set to 100,
> which is the case for the maven build.
> I also ported the test to 1.6 and running it with the new segment-tar looks
> OK. I don't know if this is because the copy-on-write or the segment-tar
> implementation is different than in 1.4.
> The affected versions are currently only set to 1.4.18, because there were no
> releases off the 1.2 and 1.0 branches since OAK-5238 was backported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360873#comment-16360873
]
Julian Reschke edited comment on OAK-5506 at 2/12/18 3:43 PM:
--
FWIW, I just noticed that the various (R)DBs vary in their behavior:
- H2DB and Derby roundtrip any string
- PostgreSQL rejects the invalid string early
- DB2 and Oracle fail the same way as segment store (they persist the
replacement character)
- MySQL and SQLServer fail the same way as DB2 and Oracle, but here it's the
RDBDocumentStore's fault, because the ID column is binary, and we transform to
byte sequences ourselves
...will file individual tickets...
was (Author: reschke):
FWIW, I just noticed that the various (R)DBs vary in their behavior:
- H2DB and Derby roundtrip any string
- PostgreSQL rejects the invalid string early
- DB2 and Oracle fail the same way as segment store (they persist the
replacement character)
- MySQL and SQLServer fail the same as DB2 and Oracle, but here it's the
RDBDocumentStore's fault, because the ID column is binary, and we transform to
byte sequences ourselves
...will file individual tickets...
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff,
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.diff,
> OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360873#comment-16360873
]
Julian Reschke edited comment on OAK-5506 at 2/12/18 3:26 PM:
--
FWIW, I just noticed that the various (R)DBs vary in their behavior:
- H2DB and Derby roundtrip any string
- PostgreSQL rejects the invalid string early
- DB2 and Oracle fail the same way as segment store (they persist the
replacement character)
- MySQL and SQLServer fail the same as DB2 and Oracle, but here it's the
RDBDocumentStore's fault, because the ID column is binary, and we transform to
byte sequences ourselves
...will file individual tickets...
was (Author: reschke):
FWIW, I just noticed that the various (R)DBs vary in their behavior:
- H2DB and Derby roundtrip any string
- PostgreSQL rejects the invalid string early
- DB2 and Oracle fail the same way as segment store (they persist the
replacement character)
- MySQL and SQLServer fail the same as DB2 and Oracle, but here it's the
RDBDocumentStore's fault, because the ID column is binary, and we transform to
byte sequences ourselves
...will file individual tickets
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff,
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.diff,
> OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-5506) reject item names with unpaired surrogates early
[
https://issues.apache.org/jira/browse/OAK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16360873#comment-16360873
]
Julian Reschke commented on OAK-5506:
-
FWIW, I just noticed that the various (R)DBs vary in their behavior:
- H2DB and Derby roundtrip any string
- PostgreSQL rejects the invalid string early
- DB2 and Oracle fail the same way as segment store (they persist the
replacement character)
- MySQL and SQLServer fail the same as DB2 and Oracle, but here it's the
RDBDocumentStore's fault, because the ID column is binary, and we transform to
byte sequences ourselves
...will file individual tickets
> reject item names with unpaired surrogates early
>
>
> Key: OAK-5506
> URL: https://issues.apache.org/jira/browse/OAK-5506
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: core, jcr, segment-tar
>Affects Versions: 1.5.18
>Reporter: Julian Reschke
>Priority: Minor
> Fix For: 1.10
>
> Attachments: OAK-5506-01.patch, OAK-5506-02.patch, OAK-5506-4.diff,
> OAK-5506-bench.diff, OAK-5506-jcr-level.diff, OAK-5506-name-conversion.diff,
> OAK-5506-segment.diff, OAK-5506-segment2.diff, OAK-5506-segment3.diff,
> OAK-5506.diff, ValidNamesTest.java
>
>
> Apparently, the following node name is accepted:
>{{"foo\ud800"}}
> but a subsequent {{getPath()}} call fails:
> {noformat}
> javax.jcr.InvalidItemStateException: This item [/test_node/foo?] does not
> exist anymore
> at
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:86)
> at
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:615)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:205)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
> at
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.getPath(ItemImpl.java:140)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.getPath(NodeImpl.java:106)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.nameTest(ValidNamesTest.java:271)
> at
> org.apache.jackrabbit.oak.jcr.ValidNamesTest.testUnpairedSurrogate(ValidNamesTest.java:259)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source){noformat}
> (test case follows)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7259) Improve SegmentNodeStoreStats to include number of commits per thread and threads currently waiting on the semaphore
Andrei Dulceanu created OAK-7259:
Summary: Improve SegmentNodeStoreStats to include number of
commits per thread and threads currently waiting on the semaphore
Key: OAK-7259
URL: https://issues.apache.org/jira/browse/OAK-7259
Project: Jackrabbit Oak
Issue Type: Improvement
Components: segment-tar
Reporter: Andrei Dulceanu
Assignee: Andrei Dulceanu
Fix For: 1.9.0, 1.10
When investigating the performance of {{segment-tar}}, the source of the
writes (commits) is a very useful indicator of the cause.
To better understand which threads are currently writing in the repository and
which are blocked on the semaphore, we need to improve
{{SegmentNodeStoreStats}} to:
* expose the number of commits executed per thread
* expose threads currently waiting on the semaphore
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
