[jira] [Commented] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074227#comment-16074227 ] Chetan Mehrotra commented on OAK-6419: -- Its not uuid style as of now. See OAK-3529 for details. As of now for DocumentNodeStore it maps to cluster instance id which is just numeric integer. However thats implementation detail > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074222#comment-16074222 ] Torgeir Veimo commented on OAK-6419: It depends on what the id looks like. If it's a uuid style id, then it's no better than just using the id of the node in question. When you generate a document slug, you want an id that is short, eg. 5-12 digits. > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6419) unique id generator
[ https://issues.apache.org/jira/browse/OAK-6419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16074203#comment-16074203 ] Chetan Mehrotra commented on OAK-6419: -- You can use Clusterable api [1] to get current instance id which can be used to create a unique id. Would that serve your needs? [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/spi/state/Clusterable.java > unique id generator > --- > > Key: OAK-6419 > URL: https://issues.apache.org/jira/browse/OAK-6419 > Project: Jackrabbit Oak > Issue Type: New Feature >Reporter: Torgeir Veimo >Priority: Minor > Labels: counters, locking, sequence > > It would be great to have a way to safely generate unique id's for node > names, with oak configured in a cluster configuration. > This is useful for creating unique slug names for documents, and ensuring > unique names for node siblings, or node names repository wide. > It could be implemented as a sequence generator, or similar to how mongodb > generates object ids; https://docs.mongodb.org/manual/reference/object-id/. > With the older jackrabbit implementation it is possible to have a sequence > guaranteed to provide unique id's, using enforceable locks. With oak theres > no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6419) unique id generator
Torgeir Veimo created OAK-6419: -- Summary: unique id generator Key: OAK-6419 URL: https://issues.apache.org/jira/browse/OAK-6419 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Torgeir Veimo Priority: Minor It would be great to have a way to safely generate unique id's for node names, with oak configured in a cluster configuration. This is useful for creating unique slug names for documents, and ensuring unique names for node siblings, or node names repository wide. It could be implemented as a sequence generator, or similar to how mongodb generates object ids; https://docs.mongodb.org/manual/reference/object-id/. With the older jackrabbit implementation it is possible to have a sequence guaranteed to provide unique id's, using enforceable locks. With oak theres no such guarantee when used in a clustered configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-6416:
---
Fix Version/s: 1.7.4
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Affects Versions: 1.7.3
>Reporter: Hudson
> Fix For: 1.8, 1.7.4
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6418) CONTAINS SQL2 parameter does not work
Marco Piovesana created OAK-6418:
Summary: CONTAINS SQL2 parameter does not work
Key: OAK-6418
URL: https://issues.apache.org/jira/browse/OAK-6418
Project: Jackrabbit Oak
Issue Type: Bug
Components: jcr
Affects Versions: 1.6.1
Reporter: Marco Piovesana
Query result is wrong when using the "CONTAINS" operator. See the following
test example:
{code:borderStyle=solid}
@Test
public void shouldFindOneElement() throws Exception {
File driveFile = new File("/tmp/oakTest", "oakrepo");
File repositoryFile = new File(driveFile, "repository");
File dataStoreFile = new File(driveFile, "datastore");
BlobStore blobStore = new
FileBlobStore(dataStoreFile.getAbsolutePath());
FileStore fileStore =
FileStoreBuilder.fileStoreBuilder(repositoryFile).withBlobStore(blobStore).build();
SegmentNodeStore segmentNodeStore =
SegmentNodeStoreBuilders.builder(fileStore).build();
Jcr jcr = new Jcr(segmentNodeStore).with(new InitialContent()).with(new
SecurityProviderImpl());
Repository repository = jcr.createRepository();
Session session = repository.login(ADMIN_CREDENTIALS);
Node myNode = session.getRootNode().addNode("myNode");
myNode.setProperty("text", "hello_world");
session.save();
QueryManager qm = session.getWorkspace().getQueryManager();
Query q = qm.createQuery("select * from [nt:base] where
CONTAINS([text],'hello_world')", Query.JCR_SQL2);
QueryResult execute = q.execute();
long foundNodes = execute.getNodes().getSize();
session.logout();
fileStore.close();
((JackrabbitRepository) repository).shutdown();
assertEquals(1L, foundNodes);
}
{code}
The test fails because the query return 0 results while it should return 1. It
works fine if instead of executing:
{code} select * from [nt:base] where CONTAINS([text],'hello_world') {code}
I run it using the LIKE operator:
{code} select * from [nt:base] where [text] LIKE 'hello_world' {code}
I also tried to run the same test inside the
_org.apache.jackrabbit.oak.jcr.query.QueryTest.java_, but there it works fine.
Here the test i run:
{code}
@Test
public void shouldFindNodeUsingContainsOperator() throws
RepositoryException {
Session session = getAdminSession();
Node hello = session.getRootNode().addNode("hello");
hello.setProperty("text", "hello_world");
session.save();
QueryManager qm = session.getWorkspace().getQueryManager();
Query q = qm.createQuery("select * from [nt:base] where
CONTAINS([text],'hello_world')", Query.JCR_SQL2);
QueryResult r = q.execute();
NodeIterator nodes = r.getNodes();
assertEquals(1, nodes.getSize());
}
{code}
Marco.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073652#comment-16073652
]
Hudson commented on OAK-6416:
-
Previously failing build now is OK.
Passed run: [Jackrabbit Oak
#504|https://builds.apache.org/job/Jackrabbit%20Oak/504/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/504/console]
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Affects Versions: 1.7.3
>Reporter: Hudson
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073563#comment-16073563
]
Hudson commented on OAK-6416:
-
Build is still failing.
Failed run: [Jackrabbit Oak
#503|https://builds.apache.org/job/Jackrabbit%20Oak/503/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/503/console]
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Affects Versions: 1.7.3
>Reporter: Hudson
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6416:
--
Affects Version/s: 1.7.3
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Affects Versions: 1.7.3
>Reporter: Hudson
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6416:
--
Fix Version/s: 1.8
Component/s: segment-tar
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration, segment-tar
>Affects Versions: 1.7.3
>Reporter: Hudson
> Fix For: 1.8
>
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6416) Test failure: MapRecordTest.testOak1104
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6416:
--
Summary: Test failure: MapRecordTest.testOak1104 (was: Build Jackrabbit
Oak #499 failed)
> Test failure: MapRecordTest.testOak1104
> ---
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6416) Build Jackrabbit Oak #499 failed
[
https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6416:
--
Description:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #499 has failed.
First failed run: [Jackrabbit Oak
#499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
The initial build failure is:
{noformat}
[ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
elapsed: 0.014 s <<< ERROR!
java.lang.NullPointerException
at
org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
{noformat}
was:
Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
The build Jackrabbit Oak #499 has failed.
First failed run: [Jackrabbit Oak
#499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> Build Jackrabbit Oak #499 failed
>
>
> Key: OAK-6416
> URL: https://issues.apache.org/jira/browse/OAK-6416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: continuous integration
>Reporter: Hudson
>
> Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/
> The build Jackrabbit Oak #499 has failed.
> First failed run: [Jackrabbit Oak
> #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console
> log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console]
> The initial build failure is:
> {noformat}
> [ERROR] testOak1104(org.apache.jackrabbit.oak.segment.MapRecordTest) Time
> elapsed: 0.014 s <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.jackrabbit.oak.segment.MapRecordTest.testOak1104(MapRecordTest.java:93)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (OAK-6416) Build Jackrabbit Oak #499 failed
[ https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073506#comment-16073506 ] Hudson commented on OAK-6416: - Build is still failing. Failed run: [Jackrabbit Oak #502|https://builds.apache.org/job/Jackrabbit%20Oak/502/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/502/console] > Build Jackrabbit Oak #499 failed > > > Key: OAK-6416 > URL: https://issues.apache.org/jira/browse/OAK-6416 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #499 has failed. > First failed run: [Jackrabbit Oak > #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-4732) (Slightly) prioritise reads over writes
[
https://issues.apache.org/jira/browse/OAK-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Dulceanu updated OAK-4732:
-
Attachment: OAK-4732.patch
[~mduerig], I attached an updated version of your patch. Can you please take a
look at it?
> (Slightly) prioritise reads over writes
>
>
> Key: OAK-4732
> URL: https://issues.apache.org/jira/browse/OAK-4732
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: segment-tar
>Reporter: Michael Dürig
>Assignee: Andrei Dulceanu
>Priority: Minor
> Labels: Performance, scalability
> Fix For: 1.8, 1.7.4
>
> Attachments: OAK-4732.patch
>
>
> When fetching the current root from the {{SegmentNodeStore}} an older
> revision will be returned when a commit is being processed concurrently. I
> think it would make sense to wait for a short time in this case increasing
> the chance of returning an up to date state. The idea is that this would
> lower the rebasing work that need to be done later on should the returned
> root be used for further modifications.
> An interesting value for the wait time is to use the median (or more general
> a percentile) of the commit time of the last say 1000 commits. This would
> mean that (for the median) we have a 50% chance of getting up to date date.
> For a 90% percentile we would have longer wait times but then a 90% chance of
> getting up to date date.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (OAK-5048) Upgrade to Tika 1.15 version
[ https://issues.apache.org/jira/browse/OAK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-5048. -- Resolution: Fixed Fix Version/s: 1.7.4 Done with 1800749 > Upgrade to Tika 1.15 version > > > Key: OAK-5048 > URL: https://issues.apache.org/jira/browse/OAK-5048 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > Oak Lucene indes is currently using Tika 1.5 version while current latest > release of Apache Tika is 1.14, I think there're lots of "interesting" bugs > fixed, and possibly improvements (performance, more accurate text extraction, > etc.) we could get at almost 0 cost by just bumping the version number. > Release notes https://tika.apache.org/1.15/index.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6414) Use Tika config to determine non indexed mimeTypes
[ https://issues.apache.org/jira/browse/OAK-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6414. -- Resolution: Fixed Reapplied the reverted commit as part of 1800749 > Use Tika config to determine non indexed mimeTypes > -- > > Key: OAK-6414 > URL: https://issues.apache.org/jira/browse/OAK-6414 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > With OAK-2895 support was added to avoid loading of binary content whose > mimeType have been excluded from indexing via configuring EmptyParser against > them. That approach used a lazyInputStream and relied on the fact that Tika > would not access the stream if none of the parser is going to touch that file. > However as seen while upgrading to Tika 1.15 now Tika would [check that the > InputStream support marking or > not|https://github.com/apache/tika/commit/896c46a0c652de436da0e4f25bfa53a7d83ae02f]. > > To support this change we need to change the logic on Oak side to explicit > check by reading tika-config.xml to see which all mimeType have been > configured with EmptyParser -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6416) Build Jackrabbit Oak #499 failed
[ https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073450#comment-16073450 ] Hudson commented on OAK-6416: - Build is still failing. Failed run: [Jackrabbit Oak #501|https://builds.apache.org/job/Jackrabbit%20Oak/501/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/501/console] > Build Jackrabbit Oak #499 failed > > > Key: OAK-6416 > URL: https://issues.apache.org/jira/browse/OAK-6416 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #499 has failed. > First failed run: [Jackrabbit Oak > #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (OAK-6410) NPE when removing inexistent property from checked in node
[
https://issues.apache.org/jira/browse/OAK-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073294#comment-16073294
]
Marcel Reutegger edited comment on OAK-6410 at 7/4/17 9:55 AM:
---
Merged into branch:
- 1.6: http://svn.apache.org/r1800741
was (Author: mreutegg):
Merged into branches:
- 1.6: http://svn.apache.org/r1800741
> NPE when removing inexistent property from checked in node
> --
>
> Key: OAK-6410
> URL: https://issues.apache.org/jira/browse/OAK-6410
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Ioan-Cristian Linte
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.8, 1.7.3, 1.6.3
>
>
> While running AEM 6.3 which uses oak 1.6.1 the following exception was seen
> in the logs:
> Stacktrace:
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$37.checkPreconditions(NodeImpl.java:1449)
> 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.NodeImpl.internalRemoveProperty(NodeImpl.java:1444)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.setProperty(NodeImpl.java:354)
> ... AEM Code
> I have reproduced the NPE with the following code:
> {code:java}
> Node parent = session.getRootNode().addNode("parent", "nt:unstructured");
> Node child = parent.addNode("child", "nt:unstructured");
> child.addMixin("mix:versionable");
> session.save();
> session.getWorkspace().getVersionManager().checkin(child.getPath());
> Node node = (Node) session.getItem("/parent/child");
> node.setProperty("inexistent", (Value) null);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6410) NPE when removing inexistent property from checked in node
[
https://issues.apache.org/jira/browse/OAK-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6410:
--
Affects Version/s: (was: 1.4)
(was: 1.2)
(was: 1.0)
Labels: (was: candidate_oak_1_0 candidate_oak_1_2
candidate_oak_1_4)
Versions 1.4 and older are not affected. With those versions the implementation
throws a VersionException because the node is checked in. In my view this is
legitimate as well. The JavaDoc says: "throws VersionException - if this node
is read-only due to a checked-in node and this implementation performs this
validation immediately."
> NPE when removing inexistent property from checked in node
> --
>
> Key: OAK-6410
> URL: https://issues.apache.org/jira/browse/OAK-6410
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.6.0
>Reporter: Ioan-Cristian Linte
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.8, 1.7.3, 1.6.3
>
>
> While running AEM 6.3 which uses oak 1.6.1 the following exception was seen
> in the logs:
> Stacktrace:
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$37.checkPreconditions(NodeImpl.java:1449)
> 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.NodeImpl.internalRemoveProperty(NodeImpl.java:1444)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.setProperty(NodeImpl.java:354)
> ... AEM Code
> I have reproduced the NPE with the following code:
> {code:java}
> Node parent = session.getRootNode().addNode("parent", "nt:unstructured");
> Node child = parent.addNode("child", "nt:unstructured");
> child.addMixin("mix:versionable");
> session.save();
> session.getWorkspace().getVersionManager().checkin(child.getPath());
> Node node = (Node) session.getItem("/parent/child");
> node.setProperty("inexistent", (Value) null);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (OAK-6241) Build Jackrabbit Oak #314 failed
[ https://issues.apache.org/jira/browse/OAK-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-6241: - Fix Version/s: (was: OAK-5872) > Build Jackrabbit Oak #314 failed > > > Key: OAK-6241 > URL: https://issues.apache.org/jira/browse/OAK-6241 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #314 has failed. > First failed run: [Jackrabbit Oak > #314|https://builds.apache.org/job/Jackrabbit%20Oak/314/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/314/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6245) Build Jackrabbit Oak #317 failed
[ https://issues.apache.org/jira/browse/OAK-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-6245: - Fix Version/s: (was: OAK-6100) > Build Jackrabbit Oak #317 failed > > > Key: OAK-6245 > URL: https://issues.apache.org/jira/browse/OAK-6245 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #317 has failed. > First failed run: [Jackrabbit Oak > #317|https://builds.apache.org/job/Jackrabbit%20Oak/317/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/317/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6417) Change log level for tests in oak-remote to INFO
[ https://issues.apache.org/jira/browse/OAK-6417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6417. -- Resolution: Fixed Fix Version/s: 1.7.4 Done that with 1800743 > Change log level for tests in oak-remote to INFO > > > Key: OAK-6417 > URL: https://issues.apache.org/jira/browse/OAK-6417 > Project: Jackrabbit Oak > Issue Type: Task > Components: remoting >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Fix For: 1.8, 1.7.4 > > > Currently the logs due to RemoteServerIT are logged to console at debug level > which creates lots of noise. This happens due to absence of any logback.xml > and hence debug logs get enabled by default and logged to console. > As a fix we should add a logback-test.xml like present in other modules -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (OAK-6417) Change log level for tests in oak-remote to INFO
Chetan Mehrotra created OAK-6417: Summary: Change log level for tests in oak-remote to INFO Key: OAK-6417 URL: https://issues.apache.org/jira/browse/OAK-6417 Project: Jackrabbit Oak Issue Type: Task Components: remoting Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 1.8 Currently the logs due to RemoteServerIT are logged to console at debug level which creates lots of noise. This happens due to absence of any logback.xml and hence debug logs get enabled by default and logged to console. As a fix we should add a logback-test.xml like present in other modules -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6416) Build Jackrabbit Oak #499 failed
[ https://issues.apache.org/jira/browse/OAK-6416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073386#comment-16073386 ] Hudson commented on OAK-6416: - Build is still failing. Failed run: [Jackrabbit Oak #500|https://builds.apache.org/job/Jackrabbit%20Oak/500/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/500/console] > Build Jackrabbit Oak #499 failed > > > Key: OAK-6416 > URL: https://issues.apache.org/jira/browse/OAK-6416 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson > > Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ > The build Jackrabbit Oak #499 has failed. > First failed run: [Jackrabbit Oak > #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (OAK-6414) Use Tika config to determine non indexed mimeTypes
[ https://issues.apache.org/jira/browse/OAK-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra reopened OAK-6414: -- Reopening as last commit caused compile time failure due to usage of Tika 1.15 specific api. So need to commit both change in same commit > Use Tika config to determine non indexed mimeTypes > -- > > Key: OAK-6414 > URL: https://issues.apache.org/jira/browse/OAK-6414 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > With OAK-2895 support was added to avoid loading of binary content whose > mimeType have been excluded from indexing via configuring EmptyParser against > them. That approach used a lazyInputStream and relied on the fact that Tika > would not access the stream if none of the parser is going to touch that file. > However as seen while upgrading to Tika 1.15 now Tika would [check that the > InputStream support marking or > not|https://github.com/apache/tika/commit/896c46a0c652de436da0e4f25bfa53a7d83ae02f]. > > To support this change we need to change the logic on Oak side to explicit > check by reading tika-config.xml to see which all mimeType have been > configured with EmptyParser -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OAK-6410) NPE when removing inexistent property from checked in node
[
https://issues.apache.org/jira/browse/OAK-6410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-6410:
--
Labels: candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 (was:
candidate_oak_1_0 candidate_oak_1_2 candidate_oak_1_4 candidate_oak_1_6)
Fix Version/s: 1.6.3
Merged into branches:
- 1.6: http://svn.apache.org/r1800741
> NPE when removing inexistent property from checked in node
> --
>
> Key: OAK-6410
> URL: https://issues.apache.org/jira/browse/OAK-6410
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
>Affects Versions: 1.0, 1.2, 1.4, 1.6.0
>Reporter: Ioan-Cristian Linte
>Assignee: Marcel Reutegger
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2, candidate_oak_1_4
> Fix For: 1.8, 1.7.3, 1.6.3
>
>
> While running AEM 6.3 which uses oak 1.6.1 the following exception was seen
> in the logs:
> Stacktrace:
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl$37.checkPreconditions(NodeImpl.java:1449)
> 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.NodeImpl.internalRemoveProperty(NodeImpl.java:1444)
> at
> org.apache.jackrabbit.oak.jcr.session.NodeImpl.setProperty(NodeImpl.java:354)
> ... AEM Code
> I have reproduced the NPE with the following code:
> {code:java}
> Node parent = session.getRootNode().addNode("parent", "nt:unstructured");
> Node child = parent.addNode("child", "nt:unstructured");
> child.addMixin("mix:versionable");
> session.save();
> session.getWorkspace().getVersionManager().checkin(child.getPath());
> Node node = (Node) session.getItem("/parent/child");
> node.setProperty("inexistent", (Value) null);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OAK-6416) Build Jackrabbit Oak #499 failed
Hudson created OAK-6416: --- Summary: Build Jackrabbit Oak #499 failed Key: OAK-6416 URL: https://issues.apache.org/jira/browse/OAK-6416 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson Jenkins CI failure: https://builds.apache.org/view/J/job/Jackrabbit%20Oak/ The build Jackrabbit Oak #499 has failed. First failed run: [Jackrabbit Oak #499|https://builds.apache.org/job/Jackrabbit%20Oak/499/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/499/console] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (OAK-6413) FileCache getIfPresent doesn't update cache hit/miss counters
[
https://issues.apache.org/jira/browse/OAK-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Jain reassigned OAK-6413:
--
Assignee: Amit Jain
> FileCache getIfPresent doesn't update cache hit/miss counters
> -
>
> Key: OAK-6413
> URL: https://issues.apache.org/jira/browse/OAK-6413
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: blob
>Affects Versions: 1.6.1
>Reporter: Ioan-Cristian Linte
>Assignee: Amit Jain
>Priority: Minor
>
> {{FileCache.getIfPresent}} bypasses cache access if key is not in cache and
> CacheStats for "DataStore-DownloadCache" MBean will always have 100% hit rate
> even when Blobs will be downloaded from the BlobStore backend by
> {{AbstractSharedCachingDataStore}} because of the miss in the cache.
> I suggest the following change:
> {{FileCache.getIfPresent}} to call {{CacheLIRS.getIfPresent}} which will
> update the cache stats (miss and hit counters).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (OAK-5048) Upgrade to Tika 1.15 version
[ https://issues.apache.org/jira/browse/OAK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072625#comment-16072625 ] Chetan Mehrotra edited comment on OAK-5048 at 7/4/17 6:30 AM: -- bq. if we wrap the LazyInputStream in a regular BufferedInputStream Can be done but then it kind of defeats the purpose of the [change|https://github.com/apache/tika/commit/896c46a0c652de436da0e4f25bfa53a7d83ae02f] done in Tika. Approach I am now taking (OAK-6414) is to read the tika-config in code and see which all mime types are configured with EmptyParser and then avoid hitting Tika layer for them all together. This makes the implementation more deterministic. was (Author: chetanm): bq. if we wrap the LazyInputStream in a regular BufferedInputStream Can be done but then it kind of defeats the purpose of the [change|https://github.com/apache/tika/commit/896c46a0c652de436da0e4f25bfa53a7d83ae02f] done in Tika. Approach I am now taking is to read the tika-config in code and see which all mime types are configured with EmptyParser and then avoid hitting Tika layer for them all together. This makes the implementation more deterministic. > Upgrade to Tika 1.15 version > > > Key: OAK-5048 > URL: https://issues.apache.org/jira/browse/OAK-5048 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Tommaso Teofili >Assignee: Chetan Mehrotra > Fix For: 1.8 > > > Oak Lucene indes is currently using Tika 1.5 version while current latest > release of Apache Tika is 1.14, I think there're lots of "interesting" bugs > fixed, and possibly improvements (performance, more accurate text extraction, > etc.) we could get at almost 0 cost by just bumping the version number. > Release notes https://tika.apache.org/1.15/index.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6415) Use dynamic service loader by default
[ https://issues.apache.org/jira/browse/OAK-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6415. -- Resolution: Not A Problem Fix Version/s: 1.7.4 Added a test with 1800727 which indicated that there is no change in default behaviour due to the way we construct Tika parser in code. Hence resolving as a Not A Problem > Use dynamic service loader by default > - > > Key: OAK-6415 > URL: https://issues.apache.org/jira/browse/OAK-6415 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > As mentioned in TIKA-1700 the Tika now by default creates a static > ServiceLoader (earlier which was dynamic). For Oak we need to ensure that > loader is dynamic -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (OAK-6414) Use Tika config to determine non indexed mimeTypes
[ https://issues.apache.org/jira/browse/OAK-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-6414. -- Resolution: Fixed Fix Version/s: 1.7.4 Implemented the new approach as mentioned in description with 1800726 > Use Tika config to determine non indexed mimeTypes > -- > > Key: OAK-6414 > URL: https://issues.apache.org/jira/browse/OAK-6414 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: lucene >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8, 1.7.4 > > > With OAK-2895 support was added to avoid loading of binary content whose > mimeType have been excluded from indexing via configuring EmptyParser against > them. That approach used a lazyInputStream and relied on the fact that Tika > would not access the stream if none of the parser is going to touch that file. > However as seen while upgrading to Tika 1.15 now Tika would [check that the > InputStream support marking or > not|https://github.com/apache/tika/commit/896c46a0c652de436da0e4f25bfa53a7d83ae02f]. > > To support this change we need to change the logic on Oak side to explicit > check by reading tika-config.xml to see which all mimeType have been > configured with EmptyParser -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (OAK-6346) Set baseline plugin comparison version to 1.6.0
[ https://issues.apache.org/jira/browse/OAK-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16073175#comment-16073175 ] Marcel Reutegger commented on OAK-6346: --- bq. That will depends on for how long we want to keep compatibility. Only previous version or longer? What I mean is, updating the comparison version is crucial when a new branch is created because otherwise the baseline plugin will not flag a required version update of an exported package anymore. Consider a package P exported with 1.0.0 in Oak 1.6. For Oak 1.7.1 we add a new method to a provider type interface and bump the version to 1.1.0 as indicated by the baseline tool. For 1.7.2 we add another method to the same interface. Now the baseline tool will not complain, because it uses 1.6 as the basis for the comparison. Compared to 1.6 two methods were added, which requires a bump of 1.0.0 to 1.1.0. But this is already the case and everything is fine. The problem starts when we branch for 1.8, release it and don't update the base version for comparison in trunk. In this case the baseline tool won't require a version bump of P when yet another method is added to the mentioned interface in Oak 1.9.1. Code compiled against 1.9.1 and later 1.10 will claim it runs fine even with 1.8, which is not true. > Set baseline plugin comparison version to 1.6.0 > --- > > Key: OAK-6346 > URL: https://issues.apache.org/jira/browse/OAK-6346 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.8 > > Attachments: OAK-6346-v1.patch > > > The purpose of baseline plugin is to ensure that any change in api get > reflected in exported version of the package. Currently the baseline plugin > compares against the immediate previous version. > This causes issue with unstable branches where new features are being > implemented and which evolve over few minor release on the trunk. In such > cases its possible that a new method expose in 1.7.1 gets removed later in > 1.7.2 (as happened in OAK-6337). > It would be better to configure baseline plugin to check against releases > from stable branch so that we can ensure that package versions are properly > aligned against stable versions -- This message was sent by Atlassian JIRA (v6.4.14#64029)
