[jira] [Work logged] (WW-5190) StackOverflowError when dispatching to JSP
[
https://issues.apache.org/jira/browse/WW-5190?focusedWorklogId=816443&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816443
]
ASF GitHub Bot logged work on WW-5190:
--
Author: ASF GitHub Bot
Created on: 13/Oct/22 06:27
Start Date: 13/Oct/22 06:27
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #571:
URL: https://github.com/apache/struts/pull/571#issuecomment-1277092879
@burtonrhodes do you use DMI?
Issue Time Tracking
---
Worklog Id: (was: 816443)
Time Spent: 2h 20m (was: 2h 10m)
> StackOverflowError when dispatching to JSP
> --
>
> Key: WW-5190
> URL: https://issues.apache.org/jira/browse/WW-5190
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions
>Affects Versions: 6.0.0
>Reporter: Lukasz Lenart
>Assignee: Lukasz Lenart
>Priority: Major
> Fix For: 6.0.3
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I am running a Spring Boot 2.7.0 (Latest) Tomcat embedded WAR + Spring
> Security + Struts 6.0.0 Actions + JSP pages. I started noticing a loop when
> a Struts2 Action result type is a "dispatcher" with following repetitive
> stack trace. Then, a stack overflow is raised.
> {noformat}
> .. repeated several times ..
> at
> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:637)
> ~[struts2-core-6.0.0.jar:6.0.0]
> at
> org.apache.struts2.dispatcher.ExecuteOperations.executeAction(ExecuteOperations.java:79)
> ~[struts2-core-6.0.0.jar:6.0.0]
> at
> org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:140)
> ~[struts2-core-6.0.0.jar:6.0.0]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
> ~[tomcat-embed-core-9.0.63.jar:9.0.63]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
> ~[tomcat-embed-core-9.0.63.jar:9.0.63]
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:111)
> ~[spring-web-5.3.20.jar:5.3.20]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
> ~[tomcat-embed-core-9.0.63.jar:9.0.63]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162)
> ~[tomcat-embed-core-9.0.63.jar:9.0.63]
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:111)
> ~[spring-web-5.3.20.jar:5.3.20]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189)
> ~[tomcat-embed-core-9.0.63.jar:9.0.63]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [struts] lukaszlenart commented on pull request #571: [WW-5190] Fixes StackOverflowException when dispatching request
lukaszlenart commented on PR #571: URL: https://github.com/apache/struts/pull/571#issuecomment-1277092879 @burtonrhodes do you use DMI? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@struts.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (WW-3691) BackgroundProcess should use a java.util.concurrent.Executor alternatively to spawning a new thread
[ https://issues.apache.org/jira/browse/WW-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616793#comment-17616793 ] ASF subversion and git services commented on WW-3691: - Commit 4c8cc361d5fc37d9962f66d7d3302e2ae6b2e847 in struts's branch refs/heads/master from Lukasz Lenart [ https://gitbox.apache.org/repos/asf?p=struts.git;h=4c8cc361d ] Merge pull request #609 from apache/WW-3691-executor WW-3691 Converts BackgroundProcess into interface and uses Executor to execute BackgroundProcess > BackgroundProcess should use a java.util.concurrent.Executor alternatively to > spawning a new thread > --- > > Key: WW-3691 > URL: https://issues.apache.org/jira/browse/WW-3691 > Project: Struts 2 > Issue Type: Improvement > Components: Core Interceptors >Affects Versions: 2.2.3.1 >Reporter: Falko Modler >Assignee: Lukasz Lenart >Priority: Major > Fix For: 6.1.0 > > Attachments: WW-3691.patch, WW-3691_core.txt, WW-3691_showcase.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Every new instance of org.apache.struts2.interceptor.BackgroundProcess spawns > a new Thread (see constructor), no thread pooling is used. > Besides problems in environments where some container might need to manage > the creation of threads, this issue also prevents certain > performance/efficiency optimizations via ThreadLocal from taking full effect. > E.g.: We use ThreadLocals for Random and SimpleDateFormat and those thread > local instances "are lost" when a new Thread is created. > Therefore BackgroundProcess should be given a new constructor that takes a > java.util.concurrent.Executor instance that is used to execute the Runnable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WW-5232) Use Github Actions instead of Travis to build PRs
[ https://issues.apache.org/jira/browse/WW-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart resolved WW-5232. --- Resolution: Fixed > Use Github Actions instead of Travis to build PRs > - > > Key: WW-5232 > URL: https://issues.apache.org/jira/browse/WW-5232 > Project: Struts 2 > Issue Type: Improvement > Components: Build Management >Reporter: Lukasz Lenart >Priority: Major > Fix For: 6.1.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (WW-3691) BackgroundProcess should use a java.util.concurrent.Executor alternatively to spawning a new thread
[ https://issues.apache.org/jira/browse/WW-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616792#comment-17616792 ] ASF subversion and git services commented on WW-3691: - Commit 8f0db1d22a5cbfaf43d19628ea548387088f781a in struts's branch refs/heads/master from Lukasz Lenart [ https://gitbox.apache.org/repos/asf?p=struts.git;h=8f0db1d22 ] WW-3691 Converts BackgroundProcess into interface and uses Executor to execute BackgroundProcess > BackgroundProcess should use a java.util.concurrent.Executor alternatively to > spawning a new thread > --- > > Key: WW-3691 > URL: https://issues.apache.org/jira/browse/WW-3691 > Project: Struts 2 > Issue Type: Improvement > Components: Core Interceptors >Affects Versions: 2.2.3.1 >Reporter: Falko Modler >Assignee: Lukasz Lenart >Priority: Major > Fix For: 6.1.0 > > Attachments: WW-3691.patch, WW-3691_core.txt, WW-3691_showcase.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Every new instance of org.apache.struts2.interceptor.BackgroundProcess spawns > a new Thread (see constructor), no thread pooling is used. > Besides problems in environments where some container might need to manage > the creation of threads, this issue also prevents certain > performance/efficiency optimizations via ThreadLocal from taking full effect. > E.g.: We use ThreadLocals for Random and SimpleDateFormat and those thread > local instances "are lost" when a new Thread is created. > Therefore BackgroundProcess should be given a new constructor that takes a > java.util.concurrent.Executor instance that is used to execute the Runnable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (WW-3691) BackgroundProcess should use a java.util.concurrent.Executor alternatively to spawning a new thread
[ https://issues.apache.org/jira/browse/WW-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukasz Lenart resolved WW-3691. --- Resolution: Fixed > BackgroundProcess should use a java.util.concurrent.Executor alternatively to > spawning a new thread > --- > > Key: WW-3691 > URL: https://issues.apache.org/jira/browse/WW-3691 > Project: Struts 2 > Issue Type: Improvement > Components: Core Interceptors >Affects Versions: 2.2.3.1 >Reporter: Falko Modler >Assignee: Lukasz Lenart >Priority: Major > Fix For: 6.1.0 > > Attachments: WW-3691.patch, WW-3691_core.txt, WW-3691_showcase.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Every new instance of org.apache.struts2.interceptor.BackgroundProcess spawns > a new Thread (see constructor), no thread pooling is used. > Besides problems in environments where some container might need to manage > the creation of threads, this issue also prevents certain > performance/efficiency optimizations via ThreadLocal from taking full effect. > E.g.: We use ThreadLocals for Random and SimpleDateFormat and those thread > local instances "are lost" when a new Thread is created. > Therefore BackgroundProcess should be given a new constructor that takes a > java.util.concurrent.Executor instance that is used to execute the Runnable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (WW-3691) BackgroundProcess should use a java.util.concurrent.Executor alternatively to spawning a new thread
[ https://issues.apache.org/jira/browse/WW-3691?focusedWorklogId=816438&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-816438 ] ASF GitHub Bot logged work on WW-3691: -- Author: ASF GitHub Bot Created on: 13/Oct/22 06:07 Start Date: 13/Oct/22 06:07 Worklog Time Spent: 10m Work Description: lukaszlenart merged PR #609: URL: https://github.com/apache/struts/pull/609 Issue Time Tracking --- Worklog Id: (was: 816438) Remaining Estimate: 0h Time Spent: 10m > BackgroundProcess should use a java.util.concurrent.Executor alternatively to > spawning a new thread > --- > > Key: WW-3691 > URL: https://issues.apache.org/jira/browse/WW-3691 > Project: Struts 2 > Issue Type: Improvement > Components: Core Interceptors >Affects Versions: 2.2.3.1 >Reporter: Falko Modler >Assignee: Lukasz Lenart >Priority: Major > Fix For: 6.1.0 > > Attachments: WW-3691.patch, WW-3691_core.txt, WW-3691_showcase.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Every new instance of org.apache.struts2.interceptor.BackgroundProcess spawns > a new Thread (see constructor), no thread pooling is used. > Besides problems in environments where some container might need to manage > the creation of threads, this issue also prevents certain > performance/efficiency optimizations via ThreadLocal from taking full effect. > E.g.: We use ThreadLocals for Random and SimpleDateFormat and those thread > local instances "are lost" when a new Thread is created. > Therefore BackgroundProcess should be given a new constructor that takes a > java.util.concurrent.Executor instance that is used to execute the Runnable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
