[jira] [Created] (OAK-10831) Look at incorporating the following gists in Oak Run
Patrique Legault created OAK-10831: -- Summary: Look at incorporating the following gists in Oak Run Key: OAK-10831 URL: https://issues.apache.org/jira/browse/OAK-10831 Project: Jackrabbit Oak Issue Type: Improvement Components: oak-run Reporter: Patrique Legault The following scripts are used to help fix inconsistencies in the repository [1] / [2]. To help streamline and manage a consistency repository check these should be included in oak-run as a groovy script. This will prevent dependencies on third party scripts and allow for proper management of the scripts [1] [https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy] [2] [https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCR-5065) Look at incorporating the following gists in Oak Run
[ https://issues.apache.org/jira/browse/JCR-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrique Legault resolved JCR-5065. --- Resolution: Invalid > Look at incorporating the following gists in Oak Run > - > > Key: JCR-5065 > URL: https://issues.apache.org/jira/browse/JCR-5065 > Project: Jackrabbit Content Repository > Issue Type: Improvement > Components: core >Reporter: Patrique Legault >Priority: Major > > The following scripts are used to help fix inconsistencies in the repository > [1] / [2]. To help streamline and manage a consistency repository check these > should be included in oak-run as a groovy script. > > This will prevent dependencies on third party scripts and allow for proper > management of the scripts > > [1] > [https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy] > > > [2] > [https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovy] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCR-5065) Look at incorporating the following gists in Oak Run
Patrique Legault created JCR-5065: - Summary: Look at incorporating the following gists in Oak Run Key: JCR-5065 URL: https://issues.apache.org/jira/browse/JCR-5065 Project: Jackrabbit Content Repository Issue Type: Improvement Components: core Reporter: Patrique Legault The following scripts are used to help fix inconsistencies in the repository [1] / [2]. To help streamline and manage a consistency repository check these should be included in oak-run as a groovy script. This will prevent dependencies on third party scripts and allow for proper management of the scripts [1] [https://gist.githubusercontent.com/stillalex/e7067bcb86c89bef66c8/raw/d7a5a9b839c3bb0ae5840252022f871fd38374d3/childCount.groovy] [2] [https://gist.githubusercontent.com/stillalex/43c49af065e3dd1fd5bf/raw/9e726a59f75b46e7b474f7ac763b0888d5a3f0c3/rmNode.groovy] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12251) Null Props Cause Incorrect Query Estimation
[ https://issues.apache.org/jira/browse/SLING-12251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrique Legault resolved SLING-12251. -- Resolution: Invalid > Null Props Cause Incorrect Query Estimation > > > Key: SLING-12251 > URL: https://issues.apache.org/jira/browse/SLING-12251 > Project: Sling > Issue Type: Bug > Components: Oak >Reporter: Patrique Legault >Priority: Major > Attachments: Non Union Query Plan.json, Non Union With Null > Check.json, Screenshot 2024-02-13 at 10.17.31 AM.png, Union Query Plan.json, > cqTagLucene.json > > > Using null props in a query can cause the query engine to incorrectly > estimate the cost of query plan which can lead to a traversal and slow > queries to execute. > > If you look at the query plan below the number of null props documents is > quiet high yet the cost for the query is only 19. When we execute the UNION > query the cost is 38 which is why it is not selected when in reality the > original cost should be much higher. > > After removing the null check the cost estimation is drastically different > and correctly reflects the number of documents in the index. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10648) Null Props Cause Incorrect Query Estimation
Patrique Legault created OAK-10648: -- Summary: Null Props Cause Incorrect Query Estimation Key: OAK-10648 URL: https://issues.apache.org/jira/browse/OAK-10648 Project: Jackrabbit Oak Issue Type: Bug Components: indexing Reporter: Patrique Legault Attachments: Non Union Query Plan.json, Non Union With Null Check.json, Screenshot 2024-02-13 at 9.30.43 AM.png, Union Query Plan.json, cqTagLucene.json Using null props in a query can cause the query engine to incorrectly estimate the cost of query plan which can lead to a traversal and slow queries to execute. If you look at the query plan below the number of null props documents is quiet high yet the cost for the query is only 19. When we execute the UNION query the cost is 38 which is why it is not selected when in reality the original cost should be much higher. After removing the null check the cost estimation is drastically different and correctly reflects the number of documents in the index. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12251) Null Props Cause Incorrect Query Estimation
Patrique Legault created SLING-12251: Summary: Null Props Cause Incorrect Query Estimation Key: SLING-12251 URL: https://issues.apache.org/jira/browse/SLING-12251 Project: Sling Issue Type: Bug Components: Oak Reporter: Patrique Legault Attachments: Non Union Query Plan.json, Non Union With Null Check.json, Screenshot 2024-02-13 at 10.17.31 AM.png, Union Query Plan.json, cqTagLucene.json Using null props in a query can cause the query engine to incorrectly estimate the cost of query plan which can lead to a traversal and slow queries to execute. If you look at the query plan below the number of null props documents is quiet high yet the cost for the query is only 19. When we execute the UNION query the cost is 38 which is why it is not selected when in reality the original cost should be much higher. After removing the null check the cost estimation is drastically different and correctly reflects the number of documents in the index. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-8974) Shows a 200 OK for a delete operation even if the node does not exist.
[
https://issues.apache.org/jira/browse/SLING-8974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789490#comment-17789490
]
Patrique Legault commented on SLING-8974:
-
I tested this locally as well as wrote a unit test on the DeleteOperation to
validate that the operation fails on a NonExistingResource and returns a 400
from the PostServlet.
The unit tests pass and the E2E pass as well.
> Shows a 200 OK for a delete operation even if the node does not exist.
> --
>
> Key: SLING-8974
> URL: https://issues.apache.org/jira/browse/SLING-8974
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Reporter: Anisha Narang
>Priority: Major
>
> When you try any curl query for a 'delete' operation, it shows a 200 OK even
> even the node does not exist.
> curl query:
> {code:java}
> $ curl -F":operation=delete" http://slinghosturl.com/content/invalid_node
>
>
> Content modified /content/invalid_node
>
>
> Content modified /content/invalid_node
>
>
>
> Status
> 200
>
>
> Message
> OK
>
>
> Location
> id="Location">/invalid_node
>
>
> Parent Location
> /content
>
>
> Path
> /content/invalid_node
>
>
> Referer
>
>
>
> ChangeLog
> id="ChangeLog">predeleted(/content/invalid_node);br//pre
>
>
>
> Modified Resource
> Parent of Modified Resource
>
> {code}
> So, even though this node does not exist, there is a 200 OK response for the
> same which is not expected as per the documentation here ->
> [https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-removal]
> Expected result:
> The response should be 404 not found if the not does not exist.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-5884) Deprecate JobManager methods which allow to manage the queue
[
https://issues.apache.org/jira/browse/SLING-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789277#comment-17789277
]
Patrique Legault commented on SLING-5884:
-
Since Sling Jobs are used in various parts of the system it and many users do
not clean /var this can lead to poor query performance and slow results.
Removing the ability to query for all jobs in the system and only query for a
subset of them would be a quick and easy optimization for now.
> Deprecate JobManager methods which allow to manage the queue
>
>
> Key: SLING-5884
> URL: https://issues.apache.org/jira/browse/SLING-5884
> Project: Sling
> Issue Type: Task
> Components: Extensions
>Affects Versions: Event 4.0.2
>Reporter: Timothee Maret
>Assignee: Stefan Egli
>Priority: Major
> Fix For: Event API 1.1.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{JobManager}} contains methods which allow to manage the entries in the
> queue. Those methods such as {{o.a.s.e.j.JobManager#findJobs}} impose a heavy
> burden on the repository and can cause major runtime issues such as running
> the instance OOM.
> This issue tracks deprecating those API signatures.
> See also http://sling.markmail.org/message/k3hjqcvnnabsb47j
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-721) Importing content packages with minimum permissions fails
[ https://issues.apache.org/jira/browse/JCRVLT-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1275#comment-1275 ] Patrique Legault commented on JCRVLT-721: - Why can't we simply expose the *usersPath* and *groupsPath* in [1] and then by having a reference to [2] we can get the path without having to create a user and group saving resources when installing a package? Seems to be an expensive way to simply expose a piece of data we already have. [1] [https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserConfigurationImpl.java#L213] [2] [https://github.com/apache/jackrabbit-oak/blob/e3c2dd6303abae0056fe8def0f59d9d9ebcdf7d2/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/ConfigurationBase.java#L63] > Importing content packages with minimum permissions fails > -- > > Key: JCRVLT-721 > URL: https://issues.apache.org/jira/browse/JCRVLT-721 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Affects Versions: 3.7.0 >Reporter: Ankita Agarwal >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.2 > > > Importing Content Packages using a dedicated user (with minimum permissions) > has failed with AccessDeniedExceptions since JCRVLT 3.7.0 release. > This is a regression of issue JCRVLT-683 specifically to logic that has been > added to determine the root paths of groups and users in > JackrabbitACLManagement#determineAuthorizableRootPaths > ([https://github.com/apache/jackrabbit-filevault/blame/jackrabbit-filevault-3.7.0/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/spi/impl/jcr20/JackrabbitACLManagement.java#L119]). > The new logic creates a group and a user in order to determine the root paths > of groups and users and immediately deletes them afterward. > This is a bad solution as it breaks the Principle of Least Permission (PoLP): > The user that is being used to import content should not have permission to > create and delete users and groups. > The root paths of users and groups are always initialized as /home/users and > /home/groups, so there is little need to determine root paths by creating and > deleting groups and users. > > *Steps to reproduce:* > * You create a user that you use to import content. You give it all > permissions on /content > * When you import a content package that replaces existing content (= when > you import the same content package twice, and it has "replace" in its filter > definition), you will see that it fails with the error that it cannot access > the /home/groups or /home/users repository path > > *Expected Behavior:* Successful content package imports > > *Experienced Behavior:* Content package imports that succeeded before now > fail with AccessDeniedExceptions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-11918) GaugeSupport has infinite recursion in registerWithSuffix
Patrique Legault created SLING-11918:
Summary: GaugeSupport has infinite recursion in registerWithSuffix
Key: SLING-11918
URL: https://issues.apache.org/jira/browse/SLING-11918
Project: Sling
Issue Type: Bug
Components: Event
Affects Versions: Event 4.3.8
Reporter: Patrique Legault
Fix For: Event 4.3.14
This exception occurs on a system with an unknown but particular configuration
but none the less causes the system to become unusable.
{code:java}
(java.lang.StackOverflowError: Delayed StackOverflowError due to
ReservedStackAccess annotated method)
at
java.base/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1239)
at
java.base/java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:959)
at
java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:415)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1855)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:955)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:890)
at
java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:320)
at
java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
at
com.codahale.metrics.JmxReporter$JmxListener.registerMBean(JmxReporter.java:510)
[io.dropwizard.metrics.core:3.2.4]
at
com.codahale.metrics.JmxReporter$JmxListener.onGaugeAdded(JmxReporter.java:535)
[io.dropwizard.metrics.core:3.2.4]
at
com.codahale.metrics.MetricRegistry.notifyListenerOfAddedMetric(MetricRegistry.java:454)
[io.dropwizard.metrics.core:3.2.4]
at
com.codahale.metrics.MetricRegistry.onMetricAdded(MetricRegistry.java:448)
[io.dropwizard.metrics.core:3.2.4]
at com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:89)
[io.dropwizard.metrics.core:3.2.4]
at
org.apache.sling.event.impl.jobs.stats.GaugeSupport.registerWithSuffix(GaugeSupport.java:150)
[org.apache.sling.event:4.3.8]
at
org.apache.sling.event.impl.jobs.stats.GaugeSupport.registerWithSuffix(GaugeSupport.java:154)
[org.apache.sling.event:4.3.8] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (OAK-9815) Add Path to the Node in the logs in order to better debug
Patrique Legault created OAK-9815: - Summary: Add Path to the Node in the logs in order to better debug Key: OAK-9815 URL: https://issues.apache.org/jira/browse/OAK-9815 Project: Jackrabbit Oak Issue Type: Improvement Components: core Reporter: Patrique Legault When debugging issues related to Oak it would be nice to see the path that was attempted to be operated in order to understand where the Oak error started from. Can we include the Node Path in the logs that caused the IllegalArgumentException *https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/core/MutableTree.java#L351* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (KARAF-6848) Multiple osgi.http.whiteboard.resource.pattern used with HttpWhiteboard does not work
[
https://issues.apache.org/jira/browse/KARAF-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197039#comment-17197039
]
Patrique Legault commented on KARAF-6848:
-
[~jbonofre] is there a way to upgrade Pax Web to version 8 in Karaf 4.3.0.RC1
> Multiple osgi.http.whiteboard.resource.pattern used with HttpWhiteboard does
> not work
> -
>
> Key: KARAF-6848
> URL: https://issues.apache.org/jira/browse/KARAF-6848
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.3.0
> Environment: Linux - Docker
> Java 11 (openjdk)
>Reporter: Patrique Legault
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Labels: pax-web
>
> When creating a component with the following SCR metadata
> {code:java}
> @Component(immediate = true,
> service = PersonalProfileResource.class,
> property =
> { "osgi.http.whiteboard.resource.pattern=/profile/*",
> "osgi.http.whiteboard.resource.pattern=/profile/contact/*",
> "osgi.http.whiteboard.resource.prefix=/profile" }
> ){code}
>
> Only binds the first pattern to the prefix the second pattern is ignored.
> Even though the scr:info command shows that the all of the SCR metadata is
> correctly parsed the HTTP:list command only shows one pattern being applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (KARAF-6848) Multiple osgi.http.whiteboard.resource.pattern used with HttpWhiteboard does not work
Patrique Legault created KARAF-6848:
---
Summary: Multiple osgi.http.whiteboard.resource.pattern used with
HttpWhiteboard does not work
Key: KARAF-6848
URL: https://issues.apache.org/jira/browse/KARAF-6848
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.3.0
Environment: Linux - Docker
Java 11 (openjdk)
Reporter: Patrique Legault
When creating a component with the following SCR metadata
```
@Component(immediate = true,
service = PersonalProfileResource.class,
property = {
"osgi.http.whiteboard.resource.pattern=/profile/*",
"osgi.http.whiteboard.resource.pattern=/profile/contact/*",
"osgi.http.whiteboard.resource.prefix=/profile"
})
```
Only binds the first pattern to the prefix the second pattern is ignored. Even
though the scr:info command shows that the all of the SCR metadata is correctly
parsed the HTTP:list command only shows one pattern being applied.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
