[jira] [Commented] (OAK-8107) Build Jackrabbit Oak #1994 failed
[ https://issues.apache.org/jira/browse/OAK-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787147#comment-16787147 ] Hudson commented on OAK-8107: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2001|https://builds.apache.org/job/Jackrabbit%20Oak/2001/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2001/console] > Build Jackrabbit Oak #1994 failed > - > > Key: OAK-8107 > URL: https://issues.apache.org/jira/browse/OAK-8107 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1994 has failed. > First failed run: [Jackrabbit Oak > #1994|https://builds.apache.org/job/Jackrabbit%20Oak/1994/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1994/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8107) Build Jackrabbit Oak #1994 failed
[ https://issues.apache.org/jira/browse/OAK-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16787067#comment-16787067 ] Hudson commented on OAK-8107: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #2000|https://builds.apache.org/job/Jackrabbit%20Oak/2000/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/2000/console] > Build Jackrabbit Oak #1994 failed > - > > Key: OAK-8107 > URL: https://issues.apache.org/jira/browse/OAK-8107 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1994 has failed. > First failed run: [Jackrabbit Oak > #1994|https://builds.apache.org/job/Jackrabbit%20Oak/1994/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1994/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786981#comment-16786981 ] Marcel Reutegger commented on OAK-8111: --- A few comments: The cast to DocumentNodeStore is unnecessary because the builder already returns a DocumentNodeStore. I would also add the state close to the clusterId in the list of clusterIds. This makes it more obvious which one can be used to run the recovery. The command cannot run in read-write mode on an active clusterId. See my patch: [^OAK-8111-2.diff]. > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-8111: -- Attachment: OAK-8111-2.diff > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111-2.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8119) Let similarity search rerank use distance as exact score
[ https://issues.apache.org/jira/browse/OAK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786963#comment-16786963 ] Tommaso Teofili commented on OAK-8119: -- fixed in r1854991. > Let similarity search rerank use distance as exact score > > > Key: OAK-8119 > URL: https://issues.apache.org/jira/browse/OAK-8119 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > > Currently the reranking algorithm for feature vector similarity search uses > an additive scoring mechanism so that the final score is the sum of the > original LSH query and the query - document feature vector distance. It turns > out that since LSH is supposed to approximate the fv distance it'd be more > effective to just use the exact distance as the final score instead of > performing the mentioned sum. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8119) Let similarity search rerank use distance as exact score
Tommaso Teofili created OAK-8119: Summary: Let similarity search rerank use distance as exact score Key: OAK-8119 URL: https://issues.apache.org/jira/browse/OAK-8119 Project: Jackrabbit Oak Issue Type: Task Components: lucene Reporter: Tommaso Teofili Assignee: Tommaso Teofili Currently the reranking algorithm for feature vector similarity search uses an additive scoring mechanism so that the final score is the sum of the original LSH query and the query - document feature vector distance. It turns out that since LSH is supposed to approximate the fv distance it'd be more effective to just use the exact distance as the final score instead of performing the mentioned sum. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8118) Index selected properties to enhance feature vector similarity search results
[ https://issues.apache.org/jira/browse/OAK-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786955#comment-16786955 ] Tommaso Teofili commented on OAK-8118: -- fixed in r1854990. > Index selected properties to enhance feature vector similarity search results > - > > Key: OAK-8118 > URL: https://issues.apache.org/jira/browse/OAK-8118 > Project: Jackrabbit Oak > Issue Type: Task > Components: lucene >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12, 1.10.2 > > > To improve the accuracy of results of the feature vector similarity search we > could include tokens from some configured properties to be treated as > keywords or tags. > Such tags would be used in the query to reduce the number of false positives > and improve the precision of search results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8118) Index selected properties to enhance feature vector similarity search results
Tommaso Teofili created OAK-8118: Summary: Index selected properties to enhance feature vector similarity search results Key: OAK-8118 URL: https://issues.apache.org/jira/browse/OAK-8118 Project: Jackrabbit Oak Issue Type: Task Components: lucene Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.12, 1.10.2 To improve the accuracy of results of the feature vector similarity search we could include tokens from some configured properties to be treated as keywords or tags. Such tags would be used in the query to reduce the number of false positives and improve the precision of search results. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-8072) Aggregate jcr:content result nodes as their parent
[ https://issues.apache.org/jira/browse/OAK-8072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-8072. -- Resolution: Fixed > Aggregate jcr:content result nodes as their parent > --- > > Key: OAK-8072 > URL: https://issues.apache.org/jira/browse/OAK-8072 > Project: Jackrabbit Oak > Issue Type: Task > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.12, 1.11.0 > > > Until the time we'll be able to work on the index time aggregation for Solr, > we should make it possible to aggregate search results of > _/foo/bar/jcr:content_ nodes as their parents _/foo/bar_ as that's what > nowadays often done in Lucene index configuration and therefore useful for > feature parity. > We can disabled this as soon as we switch oak-solr to depend on oak-search > and therefore Solr index gains the index time aggregation feature > consequently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8107) Build Jackrabbit Oak #1994 failed
[ https://issues.apache.org/jira/browse/OAK-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786891#comment-16786891 ] Hudson commented on OAK-8107: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1999|https://builds.apache.org/job/Jackrabbit%20Oak/1999/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1999/console] > Build Jackrabbit Oak #1994 failed > - > > Key: OAK-8107 > URL: https://issues.apache.org/jira/browse/OAK-8107 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1994 has failed. > First failed run: [Jackrabbit Oak > #1994|https://builds.apache.org/job/Jackrabbit%20Oak/1994/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1994/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7027) Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
[
https://issues.apache.org/jira/browse/OAK-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786849#comment-16786849
]
Francesco Mari commented on OAK-7027:
-
The first version of the patch contains a lot of changes, but most of those
changes have been mechanically performed. The core of the patch changes the
following:
* Add the possibility to configure a different instance of StandbyHeadReader,
StandbySegmentReader, StandbyReferencesReader, and StandbyBlobReader (let's
call these objects the standby server backend) in StandbyServer.
* Add a Builder for StandbyServerSync. This builder allows to configure the
standby server backend, too. The methods on the Builder related to the standby
server backend are package-private, as I intend those to be used for testing
purposes only.
* Move the failing test in a new test class, SlowServerIT. The test class is in
the o.a.j.o.segment.standby.server, so it's allowed to access the methods to
configure the standby server backend.
* SlowServerIT leverages a custom standby server backend that adds a delay when
a blob is read. This makes the timeout on the client expire, thus validating
the use case correctly.
[~dulceanu], can you have a look at the patch, please?
> Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
>
>
> Key: OAK-7027
> URL: https://issues.apache.org/jira/browse/OAK-7027
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Major
> Labels: test-failure
> Attachments: OAK-7027-01.patch
>
>
> Seen on an internal Windows Jenkins node:
> h3. Regression
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
> h3. Error Message
> {noformat}
> Values should be different. Actual: { root = { ... } }
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.AssertionError: Values should be different. Actual: { root = { ...
> } }
> at
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout(ExternalPrivateStoreIT.java:87)
> {noformat}
> h3. Standard Output
> {noformat}
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit3041268421527563090,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit3041268421527563090, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit3041268421527563090\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 4cea1684-ef05-44f5-a869-3ef2df6e0c9a to
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit4470899745425503556,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit4470899745425503556, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit4470899745425503556\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 8d19c7dc-8b48-4e10-a58d-31c15c93f2fe to
> target\junit2834122541179880349\junit4470899745425503556\data0a.tar
> 22:41:13.646 INFO [main] DataStoreTestBase.java:127Test begin:
> testSyncFailingDueToTooShortTimeout
>
[jira] [Updated] (OAK-8117) NPE when adding ACE with restrictions and remapped namespaces
[
https://issues.apache.org/jira/browse/OAK-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8117:
Attachment: OAK-8117-test.patch
> NPE when adding ACE with restrictions and remapped namespaces
> -
>
> Key: OAK-8117
> URL: https://issues.apache.org/jira/browse/OAK-8117
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-8117-test.patch, OAK-8117.patch
>
>
> [~stillalex], just ran into an NPE when adding an ACE including some
> restriction. The reason is a tiny bug in the {{ACL}} implementation that
> mistakenly uses the _oakName_ to retrieve the value/values from the passed
> restriction map. It should obviously use the key of the map, which
> corresponds to the _jcrName_. in other words: the bug only shows up when
> running tests with re-mapped namespaces.
> proposed fix attached. will attach a test case illustrating the issue later
> on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8117) NPE when adding ACE with restrictions and remapped namespaces
[
https://issues.apache.org/jira/browse/OAK-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8117:
Fix Version/s: 1.11.0
1.12
> NPE when adding ACE with restrictions and remapped namespaces
> -
>
> Key: OAK-8117
> URL: https://issues.apache.org/jira/browse/OAK-8117
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Fix For: 1.12, 1.11.0
>
> Attachments: OAK-8117-test.patch, OAK-8117.patch
>
>
> [~stillalex], just ran into an NPE when adding an ACE including some
> restriction. The reason is a tiny bug in the {{ACL}} implementation that
> mistakenly uses the _oakName_ to retrieve the value/values from the passed
> restriction map. It should obviously use the key of the map, which
> corresponds to the _jcrName_. in other words: the bug only shows up when
> running tests with re-mapped namespaces.
> proposed fix attached. will attach a test case illustrating the issue later
> on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7027) Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
[
https://issues.apache.org/jira/browse/OAK-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-7027:
Attachment: OAK-7027-01.patch
> Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
>
>
> Key: OAK-7027
> URL: https://issues.apache.org/jira/browse/OAK-7027
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Major
> Labels: test-failure
> Attachments: OAK-7027-01.patch
>
>
> Seen on an internal Windows Jenkins node:
> h3. Regression
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
> h3. Error Message
> {noformat}
> Values should be different. Actual: { root = { ... } }
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.AssertionError: Values should be different. Actual: { root = { ...
> } }
> at
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout(ExternalPrivateStoreIT.java:87)
> {noformat}
> h3. Standard Output
> {noformat}
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit3041268421527563090,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit3041268421527563090, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit3041268421527563090\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 4cea1684-ef05-44f5-a869-3ef2df6e0c9a to
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit4470899745425503556,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit4470899745425503556, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit4470899745425503556\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 8d19c7dc-8b48-4e10-a58d-31c15c93f2fe to
> target\junit2834122541179880349\junit4470899745425503556\data0a.tar
> 22:41:13.646 INFO [main] DataStoreTestBase.java:127Test begin:
> testSyncFailingDueToTooShortTimeout
> 22:41:13.646 INFO [main] SegmentNodeStore.java:120 Creating segment
> node store SegmentNodeStoreBuilder{blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore]}
> 22:41:13.646 INFO [main] LockBasedScheduler.java:155 Initializing
> SegmentNodeStore with the commitFairLock option enabled.
> 22:41:13.708 DEBUG [main] StandbyServer.java:248Binding was
> successful
> 22:41:13.708 DEBUG [main] TarWriter.java:185Writing segment
> 4a5183bd-bcdf-41ab-a557-6f19143bbc91 to
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.739 DEBUG [main] TarRevisions.java:240 TarMK journal
> update null -> 4a5183bd-bcdf-41ab-a557-6f19143bbc91.000c
> 22:41:13.755 DEBUG [standby-1] GetHeadRequestEncoder.java:33 Sending request
> from client 9aa63ed8-347b-4f00-ae7c-f984e0623e90 for current head
> 22:41:13.755 DEBUG [primary-1] ClientFilterHandler.java:53 Client
> /127.0.0.1:65480 is allowed
> 22:41:13.755 DEBUG [primary-1] RequestDecoder.java:42 Parsed 'get
[jira] [Resolved] (OAK-8102) LoginModule error metrics
[ https://issues.apache.org/jira/browse/OAK-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Deparvu resolved OAK-8102. --- Resolution: Fixed Fix Version/s: 1.11.0 thanks for the review [~anchela]! fixed with http://svn.apache.org/viewvc?rev=1854982=rev > LoginModule error metrics > - > > Key: OAK-8102 > URL: https://issues.apache.org/jira/browse/OAK-8102 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, security >Reporter: Alex Deparvu >Assignee: Alex Deparvu >Priority: Major > Fix For: 1.12, 1.11.0 > > > I'd like to add a counter for the number of login errors (but not login > failures like bad username/pass, actual errors). > More specifically it would cover errors which prevent users from accessing > the system even with a correct user/pass. Events in the login process that > would need to be looked at in the logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8117) NPE when adding ACE with restrictions and remapped namespaces
[
https://issues.apache.org/jira/browse/OAK-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated OAK-8117:
Attachment: OAK-8117.patch
> NPE when adding ACE with restrictions and remapped namespaces
> -
>
> Key: OAK-8117
> URL: https://issues.apache.org/jira/browse/OAK-8117
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, security
>Reporter: angela
>Assignee: angela
>Priority: Major
> Attachments: OAK-8117.patch
>
>
> [~stillalex], just ran into an NPE when adding an ACE including some
> restriction. The reason is a tiny bug in the {{ACL}} implementation that
> mistakenly uses the _oakName_ to retrieve the value/values from the passed
> restriction map. It should obviously use the key of the map, which
> corresponds to the _jcrName_. in other words: the bug only shows up when
> running tests with re-mapped namespaces.
> proposed fix attached. will attach a test case illustrating the issue later
> on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-8117) NPE when adding ACE with restrictions and remapped namespaces
angela created OAK-8117:
---
Summary: NPE when adding ACE with restrictions and remapped
namespaces
Key: OAK-8117
URL: https://issues.apache.org/jira/browse/OAK-8117
Project: Jackrabbit Oak
Issue Type: Bug
Components: core, security
Reporter: angela
Assignee: angela
[~stillalex], just ran into an NPE when adding an ACE including some
restriction. The reason is a tiny bug in the {{ACL}} implementation that
mistakenly uses the _oakName_ to retrieve the value/values from the passed
restriction map. It should obviously use the key of the map, which corresponds
to the _jcrName_. in other words: the bug only shows up when running tests with
re-mapped namespaces.
proposed fix attached. will attach a test case illustrating the issue later on.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (OAK-7027) Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
[
https://issues.apache.org/jira/browse/OAK-7027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari reassigned OAK-7027:
---
Assignee: Francesco Mari
> Test failure: ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
>
>
> Key: OAK-7027
> URL: https://issues.apache.org/jira/browse/OAK-7027
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar, tarmk-standby
>Reporter: Michael Dürig
>Assignee: Francesco Mari
>Priority: Major
> Labels: test-failure
>
> Seen on an internal Windows Jenkins node:
> h3. Regression
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout
> h3. Error Message
> {noformat}
> Values should be different. Actual: { root = { ... } }
> {noformat}
> h3. Stacktrace
> {noformat}
> java.lang.AssertionError: Values should be different. Actual: { root = { ...
> } }
> at
> org.apache.jackrabbit.oak.segment.standby.ExternalPrivateStoreIT.testSyncFailingDueToTooShortTimeout(ExternalPrivateStoreIT.java:87)
> {noformat}
> h3. Standard Output
> {noformat}
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit3041268421527563090,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit3041268421527563090, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit3041268421527563090\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 4cea1684-ef05-44f5-a869-3ef2df6e0c9a to
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.646 INFO [main] FileStoreBuilder.java:340 Creating file
> store FileStoreBuilder{version=1.8-SNAPSHOT,
> directory=target\junit2834122541179880349\junit4470899745425503556,
> blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore], maxFileSize=1,
> segmentCacheSize=0, stringCacheSize=0, templateCacheSize=0,
> stringDeduplicationCacheSize=15000, templateDeduplicationCacheSize=3000,
> nodeDeduplicationCacheSize=1, memoryMapping=false,
> gcOptions=SegmentGCOptions{paused=false, estimationDisabled=false,
> gcSizeDeltaEstimation=1073741824, retryCount=5, forceTimeout=60,
> retainedGenerations=2, gcType=FULL}}
> 22:41:13.646 INFO [main] FileStore.java:241TarMK opened at
> target\junit2834122541179880349\junit4470899745425503556, mmap=false, size=0
> B (0 bytes)
> 22:41:13.646 DEBUG [main] FileStore.java:247TAR files:
> TarFiles{readers=[],writer=target\junit2834122541179880349\junit4470899745425503556\data0a.tar}
> 22:41:13.646 DEBUG [main] TarWriter.java:185Writing segment
> 8d19c7dc-8b48-4e10-a58d-31c15c93f2fe to
> target\junit2834122541179880349\junit4470899745425503556\data0a.tar
> 22:41:13.646 INFO [main] DataStoreTestBase.java:127Test begin:
> testSyncFailingDueToTooShortTimeout
> 22:41:13.646 INFO [main] SegmentNodeStore.java:120 Creating segment
> node store SegmentNodeStoreBuilder{blobStore=DataStore backed BlobStore
> [org.apache.jackrabbit.core.data.FileDataStore]}
> 22:41:13.646 INFO [main] LockBasedScheduler.java:155 Initializing
> SegmentNodeStore with the commitFairLock option enabled.
> 22:41:13.708 DEBUG [main] StandbyServer.java:248Binding was
> successful
> 22:41:13.708 DEBUG [main] TarWriter.java:185Writing segment
> 4a5183bd-bcdf-41ab-a557-6f19143bbc91 to
> target\junit2834122541179880349\junit3041268421527563090\data0a.tar
> 22:41:13.739 DEBUG [main] TarRevisions.java:240 TarMK journal
> update null -> 4a5183bd-bcdf-41ab-a557-6f19143bbc91.000c
> 22:41:13.755 DEBUG [standby-1] GetHeadRequestEncoder.java:33 Sending request
> from client 9aa63ed8-347b-4f00-ae7c-f984e0623e90 for current head
> 22:41:13.755 DEBUG [primary-1] ClientFilterHandler.java:53 Client
> /127.0.0.1:65480 is allowed
> 22:41:13.755 DEBUG [primary-1] RequestDecoder.java:42 Parsed 'get head'
> message
> 22:41:13.755 DEBUG
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[
https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786710#comment-16786710
]
Julian Reschke commented on OAK-8111:
-
[^OAK-8111.diff] - new patch that makes {{--clusterId}} a required parameter.
> Create read-only DocumentNodeStore for oak-run recovery dry run
> ---
>
> Key: OAK-8111
> URL: https://issues.apache.org/jira/browse/OAK-8111
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.12
>
> Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff,
> OAK-8111.diff
>
>
> The oak-run recovery command always creates a read-write DocumentNodeStore
> even when the dryRun flag is set. In dryRun mode, the command should create a
> read-only DocumentNodeStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8111: Attachment: OAK-8111.diff > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff, > OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[
https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786539#comment-16786539
]
Julian Reschke edited comment on OAK-8111 at 3/7/19 12:10 PM:
--
{quote}The clusterId will be arbitrary when started without --clusterId and in
read-write mode. When all clusterIds are active, this won't do anything useful
but only create a new clusterId and run recovery for it.
{quote}
Well, it's not entirely arbitrary, but I see what you mean.
So let's make {{--clusterId}} required for this command. Will update that patch.
was (Author: reschke):
bq. The clusterId will be arbitrary when started without --clusterId and in
read-write mode. When all clusterIds are active, this won't do anything useful
but only create a new clusterId and run recovery for it.
Well, it's not entirely arbitrary, but I see what you mean.
So let's make --clusterId required for this command. Will update that patch.
> Create read-only DocumentNodeStore for oak-run recovery dry run
> ---
>
> Key: OAK-8111
> URL: https://issues.apache.org/jira/browse/OAK-8111
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: oak-run
>Reporter: Marcel Reutegger
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_10, candidate_oak_1_8
> Fix For: 1.12
>
> Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff
>
>
> The oak-run recovery command always creates a read-write DocumentNodeStore
> even when the dryRun flag is set. In dryRun mode, the command should create a
> read-only DocumentNodeStore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8102) LoginModule error metrics
[
https://issues.apache.org/jira/browse/OAK-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786640#comment-16786640
]
Alex Deparvu commented on OAK-8102:
---
on second thought I'll leave out the {{LoginException}} change. it doesn't make
sense anymore in the context of 'failure only'
> LoginModule error metrics
> -
>
> Key: OAK-8102
> URL: https://issues.apache.org/jira/browse/OAK-8102
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.12
>
>
> I'd like to add a counter for the number of login errors (but not login
> failures like bad username/pass, actual errors).
> More specifically it would cover errors which prevent users from accessing
> the system even with a correct user/pass. Events in the login process that
> would need to be looked at in the logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786539#comment-16786539 ] Julian Reschke commented on OAK-8111: - bq. The clusterId will be arbitrary when started without --clusterId and in read-write mode. When all clusterIds are active, this won't do anything useful but only create a new clusterId and run recovery for it. Well, it's not entirely arbitrary, but I see what you mean. So let's make --clusterId required for this command. Will update that patch. > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-8116) Expose text extraction metrics as sling metrics
[ https://issues.apache.org/jira/browse/OAK-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohit Kataria updated OAK-8116: --- Description: We want to expose Text extraction stats as sling metrics (time metrics). > Expose text extraction metrics as sling metrics > --- > > Key: OAK-8116 > URL: https://issues.apache.org/jira/browse/OAK-8116 > Project: Jackrabbit Oak > Issue Type: Task > Components: indexing, oak-search >Affects Versions: 1.12 >Reporter: Mohit Kataria >Priority: Major > > We want to expose Text extraction stats as sling metrics (time metrics). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-8116) Expose text extraction metrics as sling metrics
Mohit Kataria created OAK-8116: -- Summary: Expose text extraction metrics as sling metrics Key: OAK-8116 URL: https://issues.apache.org/jira/browse/OAK-8116 Project: Jackrabbit Oak Issue Type: Task Components: indexing, oak-search Affects Versions: 1.12 Reporter: Mohit Kataria -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786521#comment-16786521 ] Marcel Reutegger commented on OAK-8111: --- bq. Yes, but should this be done in the context of this ticket? Not necessarily. We can also move it to a separate issue. bq. Why do you say "arbitrary"? The clusterId will be arbitrary when started without --clusterId and in read-write mode. When all clusterIds are active, this won't do anything useful but only create a new clusterId and run recovery for it. > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786509#comment-16786509 ] Julian Reschke commented on OAK-8111: - bq. I like Vikas idea about creating the DocumentNodeStore in read-only mode by default and require a user to explicitly specify the read-write mode. This changes behaviour and basically means dryRun is ignored, but I think it may be worth it. Yes, but should this be done in the context of this ticket? bq. I would also make the --clusterId required. Just using an arbitrary available clusterId does not seem useful for the recovery command. Why do you say "arbitrary"? With the current patch, when "dryRun" is specified, --clusterId de facto becomes required. bq. As for the question what clusterIds are available, I suggest we create a separate command that lists the clusterIds, their state and additional information like lease end, etc. We can split that off, but I'd still think that outputting the information automatically in this case is still a good idea. > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-8111) Create read-only DocumentNodeStore for oak-run recovery dry run
[ https://issues.apache.org/jira/browse/OAK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16786496#comment-16786496 ] Marcel Reutegger commented on OAK-8111: --- I like Vikas idea about creating the DocumentNodeStore in read-only mode by default and require a user to explicitly specify the read-write mode. This changes behaviour and basically means dryRun is ignored, but I think it may be worth it. I would also make the --clusterId required. Just using an arbitrary available clusterId does not seem useful for the recovery command. As for the question what clusterIds are available, I suggest we create a separate command that lists the clusterIds, their state and additional information like lease end, etc. > Create read-only DocumentNodeStore for oak-run recovery dry run > --- > > Key: OAK-8111 > URL: https://issues.apache.org/jira/browse/OAK-8111 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: oak-run >Reporter: Marcel Reutegger >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_10, candidate_oak_1_8 > Fix For: 1.12 > > Attachments: OAK-8111.diff, OAK-8111.diff, OAK-8111.diff > > > The oak-run recovery command always creates a read-write DocumentNodeStore > even when the dryRun flag is set. In dryRun mode, the command should create a > read-only DocumentNodeStore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
