tracker issue : CF-4033856

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

Local Application setting randomly lost

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/CannotReproduce

Reporter/Name(from Bugbase): benoit plessis / benoit plessis (benoit plessis)

Created: 08/10/2015

Components: General Server

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Normal / Few users will encounter

Locale/System: ALL / Linux All

Vote Count: 0

Problem Description:
 With a Application.cfc defining a default datasource and/or local CustomTag path CF11 randomly trigger 'CustomTag Not found" or "invalid cfquery attribute value "" for datasource"

Steps to Reproduce:

Actual Result:

Expected Result:

Any Workarounds:
 Copying/linking the local CustomTags in the global server setting is one way.

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

Watson Bug ID:	4033856

External Customer Info:
External Company:  
External Customer Name: benoit
External Customer Email:  
External Test Config: My Hardware and Environment details:

Linux system, CF11, "raw" and update 1 to 5


  1. October 01, 2015 00:00:00: 1_trace.txt


Benoit, I am not able to observe the "Application.cfc/default DSN" issue with CF 11 update 06 (on Win 7 x64) Can you pls. share the relevant code with which you can observe the issue. I used the code below: -------------------- Application.cfc ---------------------------------- component output="false" displayname="" { "default-app-dsn-test"; THIS.datasource = "cfartgallery"; THIS.customtagpaths = "#expandpath("./")#..\mytags"; } -------------------- ../myTags/greetings.cfm --------------- <cfparam name="Attributes._name" default="Earthling"> <cfoutput>Greetings from Mars, #Attributes._name#!<br></cfoutput> -------------------------- test.cfm --------------------------- <cfquery name="_qry"> SELECT firstname FROM artists WHERE lastname='Kim' </cfquery> <cfoutput>#application.applicationname#</cfoutput><br> <cf_greetings _name = _qry.firstname > -------------------------- output ----------------------------------- default-app-dsn-test Greetings from Mars, Elicia!
Comment by Piyush K.
6306 | September 29, 2015 12:08:18 PM GMT
Hi Piyush, Perhaps CF-3634391 wasn't completely fixed. Please see my Sep 3, 2015 comment on that ticket. Thanks!, -Aaron
Comment by External U.
6307 | September 30, 2015 03:30:39 AM GMT
Hi Piyush, your code look ok to me, the problem is that i don't have a simple process to reproduce the issue, i'm merely only aware of the issue because of an error handler in my Application.cfc that e-mail me every error triggered on the production serveur with all details.
Comment by External U.
6308 | September 30, 2015 04:46:08 AM GMT
Benoit, Can you share the stack traces from your CF exception.log files from the time corresponding to the error notification emails you received. Let us see if we see something akin to what Aaron is suspecting in there. Aaron. Thanks for your input. I think we can raise a separate bug for the CME exceptions you observed in case Benoit here, unearths something different in the logs. Bug #CF-3634391 fixed an NPE. The new CME error could possibly be related to that fix.
Comment by Piyush K.
6309 | October 01, 2015 01:16:07 AM GMT
Latest one attached, too big to come in note. NB: Strangely enough the location pointed in the error message is always wrong, it seem to be a mix of the first file triggered, with the position of the error on the last file on the stack
Comment by External U.
6310 | October 01, 2015 02:57:52 AM GMT
Benoit, Can you share the defaulting cfc indicated in the log file you shared: /var/www/sidysv2/_ws/vente/bc.cfc You can share just the relevant part of the component here, or if you are not comfortable sharing it here you can mail it to
Comment by Piyush K.
6311 | October 05, 2015 09:17:50 PM GMT
I am closing this. We can revisit the issue if there is a reliable reproducible test case for this.
Comment by Piyush K.
6312 | July 28, 2016 12:07:51 AM GMT
I've recently found that the application had two extra "Application.cfm" (but with same application name) lurking in different path to override some of the settings/processing originaly done in the root's Application.cfm file. Requesting a file from within thoses path seem to be the missing trigger of the problem, it look like it reset the application setting "in flight" of the currently running pages, so that two requests on the same page will react differently (first one can work while the second one fail for missing the default datasource setting). I'm in process of fixing this on our application, however wouldn't it be a bit better to "fix" application settings for the current processing ? ie have some kind of local copy of the application structure made at request initialisation, that can't be modified "live" by the other requests ?
Comment by External U.
6313 | July 28, 2016 01:54:32 AM GMT