[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] [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&focusedCommentId=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] (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&focusedCommentId=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">deleted("/content/invalid_node");
>
>
>
> 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] [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] [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] (SLING-12403) Ability to review sling authenticators handling authentication request
Patrique Legault created SLING-12403: Summary: Ability to review sling authenticators handling authentication request Key: SLING-12403 URL: https://issues.apache.org/jira/browse/SLING-12403 Project: Sling Issue Type: Improvement Reporter: Patrique Legault In situations where authentication is handled in correctly it is important to be able to understand which authenticator was called upon to perform authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12403) Ability to review sling authenticators handling authentication request
[ https://issues.apache.org/jira/browse/SLING-12403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrique Legault updated SLING-12403: - Component/s: Authentication > Ability to review sling authenticators handling authentication request > -- > > Key: SLING-12403 > URL: https://issues.apache.org/jira/browse/SLING-12403 > Project: Sling > Issue Type: Improvement > Components: Authentication >Reporter: Patrique Legault >Priority: Major > > In situations where authentication is handled in correctly it is important to > be able to understand which authenticator was called upon to perform > authentication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12406) thread name should be set to x-request-id
Patrique Legault created SLING-12406: Summary: thread name should be set to x-request-id Key: SLING-12406 URL: https://issues.apache.org/jira/browse/SLING-12406 Project: Sling Issue Type: Improvement Components: Authentication Reporter: Patrique Legault The request in sling request log is not logged if authentication has failed, the only thing you have left to review is the error log. If the use of a x-request-id is present the thread name should be set to that so that we can trace the request in the log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12406) thread name should be set to x-request-id
[ https://issues.apache.org/jira/browse/SLING-12406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872957#comment-17872957 ] Patrique Legault commented on SLING-12406: -- [~cziegeler] / [~rombert] the issue here is that the request logger only logs requests that have made it through sling authentication. We dont see requests that have not made it through the SlingAuthentication service. You see a request logged once it makes it through the authentication service and onto the main servlet. This makes debugging very complex when it comes to authentication issues. > thread name should be set to x-request-id > - > > Key: SLING-12406 > URL: https://issues.apache.org/jira/browse/SLING-12406 > Project: Sling > Issue Type: Improvement > Components: Authentication >Reporter: Patrique Legault >Priority: Major > > The request in sling request log is not logged if authentication has failed, > the only thing you have left to review is the error log. > > If the use of a x-request-id is present the thread name should be set to that > so that we can trace the request in the log. -- This message was sent by Atlassian Jira (v8.20.10#820010)
