tracker issue : CF-3335568

select a category, or use search below
(searches all categories and all time range)
Title:

[ANeff] ER for: Give requests a _copy_ of per-App settings. Prevent applicationStop() from instantly deleting them.

| View in Tracker

Status/Resolution/Reason: To Fix//

Reporter/Name(from Bugbase): Aaron Neff / Aaron Neff (Aaron Neff)

Created: 09/23/2012

Components: Language, CF Component

Versions: 10.0

Failure Type: Enhancement Request

Found In Build/Fixed In Build: Final /

Priority/Frequency: Trivial / Unknown

Locale/System: English / Platforms All

Vote Count: 1

We've discussed this many times, but I believe no bug/ER has ever been filed.

Existing behavior:
E1) (good) The 1st request following applicationStop() creates a new parallel Application scope. Already-running requests share the old Application scope (see example A). New requests share the new Application scope (see example B).
E2) (bad) Requests do not get a copy of per-App settings. If a request alters a per-App setting, all concurrent requests are instantly affected. (see example C)
E3) (bad) applicationStop() instantly deletes the per-App settings. All concurrent requests are instantly affected. (see example D)

Current handling of Application-scope (#E1) is perfect.

Current handling of per-App settings (#E2 & #E3) is problematic.

Requested behavior:
R1) Keep current handling of Application scope.
R2) Give requests a duplicate() _copy_ of per-App settings. 
R3) Prevent applicationStop() from instantly deleting per-App settings.

This ER is to implement #R2 & #R3. That is the expected behavior.

Note: When running each example, click "request 1" and then immediately click "request 2". Then compare each page's output w/ my comments in the code.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3335568

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:

Attachments:

  1. September 24, 2012 00:00:00: 1_examples.zip

Comments:

Hi Adobe, We first discussed this in CF9. Could it please be considered for CF12? Requests should get a -copy- of per-App settings. Also, applicationStop() should wait for all currently-running requests to finish. Thanks!, -Aaron
Comment by External U.
17992 | November 15, 2015 01:23:56 AM GMT
Hi Adobe, I just realized this is still "To Fix". Could you please consider for Aether? It is still very much an issue. Thanks!, -Aaron
Comment by Aaron N.
17993 | August 23, 2017 07:49:29 PM GMT
+1 from me
Vote by Chris H.
17994 | August 24, 2017 11:36:50 AM GMT
Hi Adobe, I'm just checking on this issue that I raised during CF9 PR, and again in CF10 PR, and filed here. In 2015, I asked if it could please be considered for CF12 and received no reply and it wasn't fixed in CF2016 (CF12). In 2017, I asked if it could please be considered for Aether, and received no reply and it wasn't fixed in CF2018. Could it please be considered for CF2020? ApplicationStop() leaves applications in a defunct state [supposedly to fix #78459 - an issue about per-app mappings being unusable in onSessionEnd()?], and I'm hoping that one day it'll be fit-for-purpose. We definitely reported this in a timely manner. Thanks!, -Aaron
Comment by Aaron N.
30996 | July 08, 2019 08:40:56 AM GMT
Hi Adobe, In order to resolve ApplicationStop()'s issues, I believe you need to decide on exactly how it -should- behave. Your original CF9 idea was that it would, in some future CF release, cause the current request to wait for any already-running requests to finish, whilst simultaneously blocking any new requests, and then the current request would call onApplicationEnd(). However, a CF9 suggestion we had was that it would simply set a flag and the current request, and any already-running requests would finish normally/unaffected. The flag would tell CF that the -next- request would call onApplicationEnd() (if CF hadn't already called it by way of an application timeout) and then start the application anew (i.e. calling onApplicationStart() and so on). Currently, ApplicationStop() immediately calls onApplicationEnd(), in the -current- request, but lets the current request, and any already-running requests, finish normally except without their per-app settings. This defunct state that ApplicationStop() leaves requests in has left it unfit-for-purpose the decade following its inception. Thanks!, -Aaron
Comment by Aaron N.
31004 | July 08, 2019 10:02:40 PM GMT