tracker issue : CF-3863748

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

[ANeff] Bug for: extends path is cached, even w/ all caching options off

| View in Tracker

Status/Resolution/Reason: To Fix//

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

Created: 12/08/2014

Components: Language, CF Component

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Few users will encounter

Locale/System: ALL / Platforms All

Vote Count: 4

CF is caching the extends path, even w/ all caching options off. When 2 apps invoke the same child CFC, and the child CFC extends an app-specific parent CFC, then the 2 apps end up sharing each other's parent CFC (until CF is restarted or the template cache is cleared). This was an interesting one to sort out =)

Repro:

1) On CF Admin's Caching page, disable all options and clear all caches
2) Clear out the C:\ColdFusion11\cfusion\wwwroot\WEB-INF\cfclasses directory
3) Unzip attached extendscaching.zip to localhost (i.e. C:\inetpub\wwwroot)
4) Browse to localhost/app1 and see "app1's foo() was called" (good)
5) Browse to localhost/app2 and see "app1's foo() was called" (bug: CF cached the child CFC's extends path in #4)
6) On CF Admin's Caching page, click "Clear Template Cache Now"
7) Browse to localhost/app2 and see "app2's foo() was called" (good)
8) Browse to localhost/app1 and see "app2's foo() was called" (bug: CF cached the child CFC's extends path in #7)

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

Watson Bug ID:	3863748

External Customer Info:
External Company:  
External Customer Name: itisdesign
External Customer Email:  
External Test Config: x64 Win All w/ CF11 Update 3 (11,0,03,292480) Enterprise Standalone and Java 1.7.0_51 and isapi_redirect.dll v1.2.40.0 modified Monday, ?November ?10, ?2014, ??5:14:48 PM

Attachments:

  1. December 08, 2014 00:00:00: 1_extendscaching.zip

Comments:

We resolve the hierarchy of a CFC (its all parents) and cache it to avoid doing it on every request. The current issue, an edge case, is the side effect of this. Any change in the CFC resolution might cause severe regression. Will not take up it now.
Comment by Awdhesh K.
9619 | January 30, 2015 03:06:02 AM GMT
Hi Awdhesh, This actually caused me a real troubleshooting problem b/c the extends caching behavior is unexpected. In each app, I create a Component.cfc which all CFCs in the app share. It can be named anything, but is essentially an app-level version of CF's own WEB-INF.cftags.component.cfc. Example: c:\app1\Component.cfc c:\app2\Component.cfc I don't think that is so edge-case for all CFCs in an app to extend same Parent. After all, all CFCs server-wide extend WEB-INF.cftags.component.cfc by default. All CFCs in App1 have extends="component" (meaning, all CFCs in App1 extend c:\app1\Component.cfc). All CFCs in App2 have extends="component" (meaning, all CFCs in App2 extend c:\app2\Component.cfc). Next, I create some shared CFCs that also all have extends="component". c:\shared\Security.cfc c:\shared\Utils.cfc c:\shared\etc etc When shared CFCs are instantiated/invoked from App1, expected behavior is they should extend c:\app1\Component.cfc. When shared CFCs are instantiated/invoked from App2, expected behavior is they should extend c:\app2\Component.cfc. Currently, each shared CFC permanently extends the Component.cfc of whichever app it was instantiated/invoked from first. That is a real problem! Can we *please* have an option to turn off the extends caching? Thanks!, -Aaron
Comment by External U.
9620 | January 30, 2015 10:13:03 AM GMT
Changing the parent at runtime is definitely an edge case. Moreover, resolving the whole inheritance chain and validating all the methods of all the parents in the chain for every object creation would be very expensive. Not caching ths would impact your application performance drastically and therefore we would not do that. I would strongly advise you to change your design.
Comment by Rupesh K.
9621 | January 30, 2015 10:27:06 AM GMT
I'm going to disagree with you Rupesh. The "Component Caching" setting in CF Administrator specifically says: "When checked, component path resolution is cached and not resolved again." This implies that if one were to leave this setting _unchecked_, no caching should be happening. In effect, what you are saying is that by leaving it unchecked, component path resolution is not cached **except for this edge case circumstance**. Where is that documented? I also don't think this is as much of an edge case as you do. While it might not be best practice, I bet many place community frameworks in a central shared location (like C:\shared\frameworkX, C:\shared\MXUnit, etc.). It's also likely they have multiple applications on the same server which have components which extend the same parent or prototype components from the shared framework folder; furthermore, it's also likely that those applications use some of the same component names (user.cfc, thing.cfc, etc.). So the expectation would be that if the "Component Caching" setting is turned off, these applications would not step on each other's toes. I think it also would be reasonable to expect that if component paths were being cached (the "Component Caching" setting is turned **on**), the caching would be done on a _per application_ basis, not server-wide.
Comment by External U.
9622 | January 30, 2015 03:55:57 PM GMT
+1 - this is an unexpected and apparently undocumented behavior.
Vote by External U.
9629 | January 30, 2015 03:56:46 PM GMT
Incidentally, I just tested Aaron's sample code on CF10 Update 15 and the same problem existed there too. Don't have a CF9 box available to try it on though, to see if this unanticipated behavior existed that far back.
Comment by External U.
9623 | January 30, 2015 03:59:12 PM GMT
Rupesh, how about you lot just focus on making your code work, and we'll focus on making our code work. It's not for you to decide how people architect their CFML applications. Not a single one of you comes even close to having the CFML expertise to be dictating anything about CFML to anyone. Java? Sure. CFML? No. If there is a setting to cache these things; when the setting is off then no caching should happen. End of story. You should instead be focusing on your own code. If looking up the CFC hierarchy is slow... *speed it up*. It's not exactly a complex undertaking.
Comment by External U.
9624 | January 30, 2015 05:13:04 PM GMT
+1//////////////////////////////////
Vote by External U.
9630 | January 30, 2015 05:19:09 PM GMT
Seems like a real issue to me
Vote by External U.
9631 | January 30, 2015 05:29:42 PM GMT
Adobe's dictation of when caching should/shouldn't be done is a repeat issue. Examples: CF-3916906 - THIS.datasources changes ignored until CF restart CF-3787631 - Axis2 web services can cache unexpectedly CF-3915081 - CF caches S3 metadata CF-3923429 - Queries stay cached even after clearing them in the administrator panel @Carl and @Adam, exactly! -------------------------------------------- [ ] Component cache When checked, component path resolution is cached and not resolved again. This setting does not require restarting the server. ---------------------- The reverse is implied: When unchecked, component path resolution is not cached and is resolved again. @Rupesh, once that setting is fixed (to never cache component path resolution if unchecked), then this ticket will be resolved. Until then, this ticket should be Open/ToFix b/c this is a bug which defies the feature description in CF Admin and the documentation. Please don't tell me how to design my apps when I'm actually "Using the ColdFusion Administrator" per its documentation: https://wikidocs.adobe.com/wiki/display/coldfusionen/Using+the+ColdFusion+Administrator#UsingtheColdFusionAdministrator-Cachingpage Thanks!, -Aaron
Comment by External U.
9625 | January 30, 2015 06:51:33 PM GMT
At Carl's request, I tested the supplied code sample on CF9.0.2. I needed to switch the syntax over to createObject() for it to run, but the same undesired caching exists even with all cache settings turned off in the administrator. And since I like to be thorough, I fired up Railo and confirmed the expected behavior was present. Railo does not cache the super class and the correct text is output by both sites. Mind you, this still worked even with Railo's most stringent caching settings enabled! It seems Railo has found a way to avoid any performance so I'm confident ColdFusion can figure something out too. If nothing else, couldn't the lookup at least just be cached for a given application and not for the whole server?
Comment by External U.
9626 | January 30, 2015 10:47:58 PM GMT
Looks like I mistakenly filed this as an ER. It's obviously a bug and should be changed from ER to bug. Additionally, another ticket was recently filed for the same extends path caching issue: https://bugbase.adobe.com/index.cfm?event=bug&id=CF-4100853 Thanks!, -Aaron
Comment by External U.
9627 | January 05, 2016 04:29:36 AM GMT
+1
Vote by External U.
9632 | January 05, 2016 04:48:53 AM GMT
Where I think this problem could really crop up is when in environments (such as hosting providers) where many different applications are being run, which could be using many different versions of the same open source projects. For example, you could run into this issue with users using FW/1 where mappings to FW/1 were declared in the App.cfc. If people are using the same custom per app mapping (such as "fw1") then you're going to run into a potential problem with different apps potentially using an unexpected version of the framework.cfc.
Comment by External U.
9628 | January 05, 2016 06:06:36 AM GMT