[
https://issues.apache.org/jira/browse/WW-5312?focusedWorklogId=862523&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-862523
]
ASF GitHub Bot logged work on WW-5312:
--------------------------------------
Author: ASF GitHub Bot
Created on: 28/May/23 07:07
Start Date: 28/May/23 07:07
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on code in PR #688:
URL: https://github.com/apache/struts/pull/688#discussion_r1208386567
##########
core/src/main/java/org/apache/struts2/interceptor/ExecuteAndWaitInterceptor.java:
##########
@@ -394,7 +404,10 @@ public void init() {
@Override
public void destroy() {
- super.destroy();
- executor.shutdown();
+ try {
+ executor.shutdown();
+ } finally {
+ super.destroy();
+ }
Review Comment:
Thanks a lot for your comment, yet I was thinking about redesigning the
current *Map approach (there is ApplicationMap, RequestMap as well) and use
native objects to have more control over them. Right now we must prevent extra
cuotion to secure the framweork (excluded `#application` or `#request` in
ParametersInterceptor).
Anyway this will happen in Struts 7.0 at leas :)
Issue Time Tracking
-------------------
Worklog Id: (was: 862523)
Time Spent: 50m (was: 40m)
> ExecuteAndWaitInterceptor inconsistent wait processing behaviour
> ----------------------------------------------------------------
>
> Key: WW-5312
> URL: https://issues.apache.org/jira/browse/WW-5312
> Project: Struts 2
> Issue Type: Bug
> Components: Core, Core Interceptors
> Affects Versions: 6.1.2
> Environment: Java 8, Tomcat 8.5. The behaviour will likely be the
> same for other Java/Server combinations.
> Reporter: James Chaplin
> Priority: Minor
> Labels: pull-request-available
> Fix For: 6.2.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The _ExecuteAndWaitInterceptor_ processing appears to only execute as
> expected for the first run-through for any given session.
> This can be seen interactively using the Struts2 Showcase "_Execute and Wait
> Examples_", with the wait processing only functioning during the first
> attempt through each example in the same session. Clearing the session in
> the browser gives the expected wait behaviour again, but only one time (until
> clearing the session again).
> After debugging the _ExecuteAndWaitInterceptor_ flow, it appears that the
> removal from the _SessionMap_ did not perform as expected, resulting in a
> state divergence with the underlying session.
> A PR that attempts to fix the behaviour will be submitted soon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
