[jira] [Updated] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java
[ https://issues.apache.org/jira/browse/SLING-12200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Baedke updated SLING-12200: --- Description: AFAIK shaded Guava is no longer part part of recent releases of graphql-java. The only usage is https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, which is trivial to replace with JavaSE. cc [~reschke] was: AFAIK shaded Guava is no longer part part of recent releases of graphql-java. The only usage is https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, which is trivial to replace with JavaSE. > sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from > graphql-java > - > > Key: SLING-12200 > URL: https://issues.apache.org/jira/browse/SLING-12200 > Project: Sling > Issue Type: Improvement > Components: GraphQL >Reporter: Manfred Baedke >Priority: Trivial > > AFAIK shaded Guava is no longer part part of recent releases of graphql-java. > The only usage is > https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, > which is trivial to replace with JavaSE. > cc [~reschke] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12200) sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java
Manfred Baedke created SLING-12200: -- Summary: sling-org-apache-sling-graphql-core unnecessarily uses the shaded guava from graphql-java Key: SLING-12200 URL: https://issues.apache.org/jira/browse/SLING-12200 Project: Sling Issue Type: Improvement Components: GraphQL Reporter: Manfred Baedke AFAIK shaded Guava is no longer part part of recent releases of graphql-java. The only usage is https://github.com/apache/sling-org-apache-sling-graphql-core/blob/30babad3caab0da0dc85bc0d645f76ca6784ef67/src/main/java/org/apache/sling/graphql/core/engine/SelectedFieldWrapper.java#L181, which is trivial to replace with JavaSE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14700283#comment-14700283 ] Manfred Baedke commented on SLING-4676: --- Hi Carsten, The keepalive time doesn't restrict the total life time of a thread, it just allows for removing threads that have been idle for some time - maybe that's sufficient? Clean up threads or refresh threads when put back into the pool --- Key: SLING-4676 URL: https://issues.apache.org/jira/browse/SLING-4676 Project: Sling Issue Type: Improvement Components: Commons Reporter: Carsten Ziegeler Fix For: Commons Threads 3.2.2 Attachments: sling-4676-provisional.patch A thread from the pool might use thread locals which are - for whatever reason - not cleaned up, when the thread is put back into the pool. This can lead to memory leaks. We should protect against this. Unfortunately there is no official API to clean up thread locals. There are solutions out there using reflection. Another option is to simply discard the thread object after some time of usage and use a fresh one. This needs to include thread objects staying in the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14695740#comment-14695740 ] Manfred Baedke edited comment on SLING-4676 at 8/13/15 6:38 PM: Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. Opinions? was (Author: baedke): Thx [~cziegeler]. Since org.apache.sling.commons.threads.ThreadPoolConfig already features a method getKeepAliveTime() which is used to retrieve the time interval after which idle threads will be removed, my plan was to just add a max age constraint. The problem with this approach is that org.apache.sling.commons.threads.impl.DefaultThreadPool uses java.util.concurrent.ThreadPoolExecutor which actually maintains the pool and I didn't see a way to interfere since this stuff is at least package protected and there also is no suitable hook. I attached a provisional patch which adds the new config params, but doesn't do anything with the max age value yet. I see three possibilities: # I have a blind spot and there is a trivial solution # We write our own ThreadPoolExecutor (just mentioned for completeness) # We don't introduce a max age and use the Tomcat reflection hack instead. Clean up threads or refresh threads when put back into the pool --- Key: SLING-4676 URL: https://issues.apache.org/jira/browse/SLING-4676 Project: Sling Issue Type: Improvement Components: Commons Reporter: Carsten Ziegeler Fix For: Commons Threads 3.2.2 Attachments: sling-4676-provisional.patch A thread from the pool might use thread locals which are - for whatever reason - not cleaned up, when the thread is put back into the pool. This can lead to memory leaks. We should protect against this. Unfortunately there is no official API to clean up thread locals. There are solutions out there using reflection. Another option is to simply discard the thread object after some time of usage and use a fresh one. This needs to include thread objects staying in the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4676) Clean up threads or refresh threads when put back into the pool
[ https://issues.apache.org/jira/browse/SLING-4676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693834#comment-14693834 ] Manfred Baedke commented on SLING-4676: --- [~cziegeler], I will have to introduce new parameters to the thread pool configuration, which would add new methods to the interface ThreadPoolConfig. What's the policy on that? Creating a new interface extending the old one? Clean up threads or refresh threads when put back into the pool --- Key: SLING-4676 URL: https://issues.apache.org/jira/browse/SLING-4676 Project: Sling Issue Type: Improvement Components: Commons Reporter: Carsten Ziegeler Fix For: Commons Threads 3.2.2 A thread from the pool might use thread locals which are - for whatever reason - not cleaned up, when the thread is put back into the pool. This can lead to memory leaks. We should protect against this. Unfortunately there is no official API to clean up thread locals. There are solutions out there using reflection. Another option is to simply discard the thread object after some time of usage and use a fresh one. This needs to include thread objects staying in the pool for a long time -- This message was sent by Atlassian JIRA (v6.3.4#6332)
