tracker issue : CF-3752424

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

logging and try / catch has a flaw

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/NotABug

Reporter/Name(from Bugbase): Andrew Scott / Andrew Scott (Andrew Scott)

Created: 04/29/2014

Components: Logging

Versions: 10.0

Failure Type: Incorrect w/Workaround

Found In Build/Fixed In Build: Final /

Priority/Frequency: Normal / Most users will encounter

Locale/System: English / Win All

Vote Count: 2

Problem Description:

This has actually surprised me that it has taken me this long to wake up to this behavior...

Anyway the current problem is that I am having a major read / write lock and can't find where it is occurring, the problem is that there is absolutely nothing in the ColdFusion logs at all. When realizing that this is because the error is being captured, the best test case I can give for this is the following code.

try {
  // code block to execute.
} catch (any e) {
  //... skip errors as we don't need to display this to the user.

Now one would first be inclined to just put a log in the catch area, however it is not that simple. Over the years I have seen many examples of where an error is being thrown to be caught later, in some cases it is a way to just cleanly exit and not let the user know.

But I have seen many examples of the above code, where nothing gets logged for serious errors.

Which brings me to my current situation, as there is no log of the error except some basic information. We know have to wait until it occurs again, this is painful because it makes it hard to look for something that can be easily lost in the noise of the workings of the application..

My proposal is that no matter what, once a try block has been caught ColdFusion logs this information in its logs. I can't stress how important that small change can make our lives so much easier.

Steps to Reproduce:

Actual Result:

Expected Result:

Any Workarounds:

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

Watson Bug ID:	3752424

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



To be clear, are you saying that something should be logged when you have captured it in a try? I'm not sure that is the norm, is it?
Comment by External U.
12416 | May 01, 2014 09:17:26 PM GMT
Not at all Raymond. What I am saying is this. Most developers while developing an application, will put try catch blocks in their code to capture know conditions. This is too stop the output from being shown to the user browsing the site. In normal conditions, one would just put a log here and be done with it. However I am in a position where the author of a framework hasn't logged anything that is being captured by the Application. This is a serious read/write lock on some cfthread that pops up every now and then. The code does what it is supposed to do, stops the output from being displayed to the user. Which is why these things exist in the first place. But with errors, they should always be logged by CF. Yes it is up to us to catch and decide what to do, but there is som much that can and does go wrong when the internals fail that people are not seeing because it doesn't appear in their logs. I also have another error that occurs every now and then, its a null pointer exception being thrown by ColdFusion, again can't locate how this is happening because again the framework author is not logging anything. So when I sit down and think about this some more, the likely hood that people are using try/catch blocks, is not to log errors, but to stop the error from being shown to user. So far I have 2 serious errors that I can located, because ColdFusion can't log these errors. I think the perception of users is to always try / catch and let the software running the application log what it has to log. This is no different, it is a small change, easy to implement on both sides. But better if it is in ColdFusion.
Comment by External U.
12417 | May 01, 2014 09:27:04 PM GMT
"In normal conditions, one would just put a log here and be done with it." Why? If I know something may thrown an error and I try/catch it, I may or may not care to log that it happened. I don't think it is safe to assume you always want to log it. You say I was wrong about my comment, but after reading your follow up, it *still* sounds like you are saying that you want an exception captured in a try/catch block to still be logged. Which to me, is *not* the norm.
Comment by External U.
12418 | May 01, 2014 09:45:10 PM GMT
But what is the norm? And who says we have to follow it, hell Adobe is good at not following the norm in so many areas. Anyway, look it is no big deal. I think when it comes down to the logistics off it, it would be far better to have ColdFusion log it regardless. The onuses of developers always making sure to add a log is asking a lot... So all I am doing is saying, lets make it easier for bugs and problems to be found, hosting providers will always get the logs regardless and means Sys Admins don't need to rely on clients getting the data needed to pass back to the Sys Admins. Like I said I am in a position where a framework author hasn't done this and to be fair an internal ColdFusion error thrown because a lock can't get released is not something that is always on a developers mind. But I can't find this, the Sys Admins have nothing to work with, because there is nothing in the logs that they need. I don't see it as a big deal, I am just looking at trying to make the language more user friendly and if by being blindsided by what is the norm, then maybe think about taking a step back and saying well you know, we should be making the language user friendly and breaking what is perceived as the norm.
Comment by External U.
12419 | May 01, 2014 09:57:30 PM GMT
This isn't how any language system I've seen actually works. The whole point of try/catch is that YOU are responsible for the error handling and YOU are responsible for logging those exceptions if that's what you want. That's true of every language system I've worked with: exceptions that are caught by user code are not handled by the system. There are "expected" exceptions that code will raise and catch and if that code produces errors in the logs, many people would complain - people want LESS noise in their log files, not more. This is absolutely not a bug.
Comment by External U.
12420 | May 01, 2014 10:12:22 PM GMT
So Sean, are you saying that it is OK for ColdFusion itself to bawk at an internal problem and not log it?
Comment by External U.
12421 | May 01, 2014 10:28:05 PM GMT
It sounds like I am not being clear here. Lets try this another way. If I write an Application in CFML, I understand that if I try to access a file and it throws an exception that it is up to me to catch and log if I so desire. But what I can't fathom, is the lack of logging for exceptions that ColdFusion throws due to unknown bugs or problems in the way something works. For example I go back to it again, ColdFusion is throwing 2 errors. The first is a null exception pointer, that is thrown but not logged as it is caught up in the try / catch block. This is an intermittent error that I can't find nor can the host as there are no logs for it. The code is not my code causing the error, but ColdFusion itself not handling an exception error correctly. So should I then become responsible for capturing and logging these, no, I don't believe that is my responsibility. The 2nd error is the same thing, ColdFusion is having the issue of a read / write lock that is also intermittent but not due to my code actually failing. So again should I be responsible for logging things ColdFusion should be doing! I understand the concept of logging your own errors, which is the key here. I am all for logging or not logging things the application does wrong.
Comment by External U.
12422 | May 01, 2014 10:40:57 PM GMT
Another scenario is JDBC timeouts, these are also caught up in the try / catch blocks and yet this is something that hosting providers System Administrators need to see. So in a case like that, why should the Application have to log something like this. I would have thought this would have been something people would jump at, take away the onuses of the developer doing the right thing with logging and make all ColdFusion internal / important enough for System Administrators be logged by ColdFusion. Lower level errors like file not found or divison by zero errors, should be handled by the developers Application.
Comment by External U.
12423 | May 01, 2014 10:53:38 PM GMT
If you control the try / catch, you can choose which exceptions to catch. The problem here is the framework you mention, that is catching "any" exceptions I suspect, instead of just the ones it knows how to handle. Go log a bug against the framework. The whole point of try / catch is to say "I know how to handle exceptions of type T (and I'll let everything else bubble up)". Handling an exception means that it's not an error for the system to worry about - it says, yeah, I'm expecting this to fail and I don't want the default behavior.
Comment by External U.
12424 | May 01, 2014 11:53:34 PM GMT
Sean, yes I understand that. When was the last time you saw Java throw an exception that was a fault in the c++ libraries? I think the misconception here is that I am looking at segregating ColdFusion exceptions and Application specific exceptions. Is narrow mindedness a disease that can't be cured, it might not be a bug and happy for it to be transferred to an E/R but I think this is something that could help more. As a developer who codes and places sites onto a shared host, I only care about errors in my code and stopping them from being displayed to the user and do what is right for the Application. I don't care about exceptions that System Administrators need, in my eyes it would be best for these to be logged in a manor that the right people see them and not the Application developer. Hell, even a switch in the Administrator or at Application level either from a Sys Admin or developer level could just say log all exceptions so that the hosting provider Sys Admins see what they need to see. They don't care about my Application exceptions, as I don't care for theirs. So is it really that awful, that we can't make that job easier! I don't or really fail to understand how you can't see how this helps better the language for everyone.
Comment by External U.
12425 | May 02, 2014 12:15:09 AM GMT
I'm actually surprised you even think this is an issue. I really thought you were smarter than this. You are having trouble debugging a problem and you think the solution is to have ColdFusion break the rules around exceptions to help you. You're completely and totally wrong on this issue. Go log a bug with the framework, seriously. This is not a CFML issue at all.
Comment by External U.
12426 | May 02, 2014 12:42:35 AM GMT
Whatever Sean and I thought you where smart enough to see what it is that is being proposed. I know it is not a CFML issue, it is a ColdFusion issue or enhancement that would make System Administrators happier. All I am saying is that if it is a ColdFusion exception, for example a SQL server begins to have issues with bandwidth. I see these errors in my logs, yes that is not the issue. The issue is that until it is reported back to the hosting provider, it could be hours down the track. In this example, if these errors where actually logged by ColdFusion in the ColdFusion logs, then the System Administrators can begin to look at how often and how long the errors have been occurring. As it stands now, they don't see this and are well unaware that there maybe an issue until the likes of myself report it too them. I don't understand how you can ignore that this is about improving workflow and communication, yes mainly for System Administrators in hosting situations, but an enhancement that I am sure will benefit everyone as I keep saying. What is wrong with asking Sean!!
Comment by External U.
12427 | May 02, 2014 12:55:38 AM GMT
Because you're poking at the completely wrong part of the problem. You're focused on the root exception instead of on the code that is suppressing it. It's that latter code that is the problem, not the root cause. ColdSpring is a good example of this problem: it wraps all CFC instantiations in a try/catch and suppresses a lot of information. Commenting out its try/catch is about the only way to get decent exception information out of it. The bug there is in ColdSpring, not in ColdFusion. The problems you are seeing are the same: the try/catch code is the problem, not the underlying lack of logging in CF. I completely understand what you're proposing - and it's just a bad idea. This was discussed on the ##coldfusion IRC channel today and everyone felt you are wrong here - I'm just the only one with balls enough to tell you :)
Comment by External U.
12428 | May 02, 2014 01:01:53 AM GMT
Whatever Sean... I am not looking at this from a developers point of view, but more from the System Administration side of things and how it impacts how I have to deal with my hosting provider now. As it stands if this null exception error comes in, yes I get the log information, but when I go to the host they search the ColdFusion logs and see that no one else is having this issue. Why can't those errors be logged by ColdFusion, so when a Sys Admin goes through the logs they can see that others are also having the issue! Why do we have to keep looking at this from the Application point of the equation! That's it I have made my case and I still believe in the enhancement being requested, just because you can't see what it is that is being asked is not my fault either. Just because it is norm to log in a catch, doesn't mean the lower level language should not take a more pro approach to making this pain a little easier either.
Comment by External U.
12429 | May 02, 2014 01:57:09 AM GMT
Sorry Andrew; I'm with Sean on this one. (and, to be very clear, just like Sean and Ray, I completely understand what you're saying. I just don't agree with what you're suggesting). There is nothing to fix here, and if it was positioned as an enhancement request, I'd be against it as the wrong way of going about things. Sorry mate. -- Adam
Comment by External U.
12430 | May 02, 2014 01:44:38 PM GMT
Adam, Sean is looking at this from the Application level. i am looking at this from the server level. What I mean is very simple, my Application makes a DB connection that 99.9% of the time is up and running. However there is a time when the DB bandwidth maybe congested and in some cases throws an error. ColdFusion doesn't log this and lets the Application in question deal with it, that's fine I have no issue with that side of it. because I don't want the error displayed I take control and display something more user friendly. The problem is that this is not logged by ColdFusion, so when I go the my Host they search through the logs and see no-one else is having issues like this. Even if I provide the captured log, they will only acknowledge that I am having this issue, how many other sites on a hosting server have this issue and it is not appearing in the logs? The solution of allowing ColdFusion to log this excpetion, not only helps me as a Developer, it also helps the System Administrators as well. Because they can't see this in the logs, it will be placed as a lower priority rather than a high priority if indeed the database connection is having serious errors. Recently this happened to my site, where eventually the DB connection went down due to hardware failure, but as there was nothing in the ColdFusion logs it makes it hard for the System Administrator to see, well we can see that it started happening then and just maybe if we could have seen this in the ColdFusion logs we could have put up a temporary DB in place while we fix the hardware to this one having issues. Instead everyone went down eventually, but because nothing showed in the ColdFusion logs no-one knew about the impending danger. The point is if it is something NOT caused by the Application then I am saying there is no harm in ColdFusion logging this before bubbling down to the Application.
Comment by External U.
12431 | May 03, 2014 05:54:13 PM GMT
Andrew, I *get it*. What you're describing isn't hard to understand. You can repeat it as often as you like, but I got it the first time, and every other subsequent time. On the other hand I don't think you're actually absorbing what Sean, Ray and myself have said (although obviously I only said "me too", really). Sean summed it up as much as was needed with this: "The problems you are seeing are the same: the try/catch code is the problem, not the underlying lack of logging in CF." And: "The whole point of try/catch is that YOU are responsible for the error handling and YOU are responsible for logging those exceptions if that's what you want. " When you catch an exception... it's no longer something CF would consider log-worthy, as CF logs *unhandled* exceptions. Once you try/catch it, you are telling CF that it's been handled. That's what these constructs are for. That you're not logging stuff is a shortcoming of *your* code, not Adobe's. -- Adam
Comment by External U.
12432 | May 03, 2014 06:07:38 PM GMT
Whatever Adam... Your always the king of everything and your so frigging right on everything.
Comment by External U.
12433 | May 03, 2014 06:21:00 PM GMT
Dude, this isn't just Adam, this is *multiple* people telling you - or trying to tell you - that your understanding of try/catch, or the expected behavior of it, is not right. Just.. add... a log. Seriously. If you want to start logging in things you are try/catching, just do it.
Comment by External U.
12434 | May 03, 2014 06:24:40 PM GMT
I have ignored what they have said, because they are all looking at what the CFML Application should be doing. I am not asking for that to change. Which is what they are saying and ignoring the rest of it. All I am saying is that if it is something that ColdFusion is doing wrong, or something that is being caused by other connection issues or whatever is serious enough to bring ColdFusion itself down, be logged in the ColdFusion logs by ColdFusion and not the make it the Applications responsibility. As far as our code goes, nothing will change. The only change is that something that should be in the ColdFusion logs actually is. So if you understand why do you, Sean and Ray think that the Application or anything written in CFML needs to change?
Comment by External U.
12435 | May 03, 2014 06:27:10 PM GMT
Ray, I am not asking for the CFML side to change. Again you are all thinking that I am asking for the current execution of ColdFusion Applications to change. I am not. I am not asking for the try / catch to do anything more than it is actually doing. Except that if ColdFusion throws the error it is logged by ColdFusion. Not CFMl code that throws a ColdFusion error, but physical errors like the null exception or DB timeouts should be logged by ColdFusion and still filter down to the CFML Application. If you deal with hosts enough to see this problem for what it is, you may understand.
Comment by External U.
12436 | May 03, 2014 06:35:20 PM GMT
You know when everyone jumped up and said the for array loops need to know the index of the array instead of just the element. I was like well that is not how other languages handle it. So how does a request like that gain momentum, because they are sick of doing the code or refactoring the code to work the right way. How does that argument to go against how other languages work there, but doesn't apply here? Especially since I am not asking for any CFML changes to code that is being written, I am only asking that if ColdFusion throws an error that it should be logging for System Administrators, why can it? So don't bring well that is how other languages works, when there is a huge momentum to break that mold in the actual language itself. And people wonder why I get upset with the so called Community Experts, if it suits them good, if not then bad. As a development community the ColdFusion has to be the worst I have ever dealt with.
Comment by External U.
12437 | May 03, 2014 06:39:54 PM GMT
Adam, here is what I here Sean saying. If you are writing an Application and you use try / catch, it becomes your responsibility to log the errors. Really! I know that. The mis-conception is that we have 4 Applications in play here, we have. 1) The CFML Application 2) The ColdFusion Application 3) The Java Application and last but not least 4) The OS Application. Each and everyone of these Applications, as Sean is indicating with his response, is responsible for logging if they use a try / catch, which ColdFusion doesn't. ColdFusion filters all errors to the try / catch block, which I don't have a problem with at all. But everyone seems to think that I do. All I am saying is that ColdFusion becomes responsible for logging errors it needs to know about. Such errors are anything that is not caused by the normal execution of CFML code. I used the examples of DB timeouts, because this is not in the control of the CFML Application. Although it DOES need to be caught and dealt with is something that HAS to be done. But the step that is missing here, is that ColdFusion has been acceptable to an external issue that has caused ColdFusion to stop running, instead of just bubbling this down to the CFML Application. ColdFusion should be logging this information for any System Administrator to look at, as it stands right now these are not logged by ColdFusion. As it stand right now, because this is not logged by ColdFusion before filtering down to the CFML Application is can get lost. This doesn't help System Administrators as they can't see if other sites on the server are having this issue if ColdFusion is not logging these things. And for god sake, don't assume I mean every error. Like Sean is saying, I am saying that the framework if using the try / catch even if it is written in java for the execution of ColdFusion, should be logged. So if Sean is agreed, that the framework is the responsible person, then that means in these examples ColdFusion is that entity. Because after all they know about this serious error and as Sean says, it is then the responsibility of that framework to log the error. As if the error was an OS related error, it would also be logged by the OS, then Java would have to do what it does. But the OS was the cause so it also need to log the error and is indeed the case. Same for what I am asking for, if ColdFusion is the cause of the CFML part from failing, that ColdFusion become responsible for logging it. How everyone keeps focusing on the execution of the try / catch in my CFML Application, when that is not what I am asking is beyond me to comprehend how and why you continue to focus on something that I am not asking to change.
Comment by External U.
12438 | May 03, 2014 07:10:16 PM GMT
"You know when everyone jumped up and said the for array loops need to know the index of the array instead of just the element. I was like well that is not how other languages handle it." Um, I can't speak for every language, but here is JS: I'd probably guess it is the norm to pass both. At the end of the day, I'd rather have both and not need em then not have one and need it. "As a development community the ColdFusion has to be the worst I have ever dealt with." Dude. We are having a discussion. No one has said you are stupid. No one has attacked you. Multiple people have disagreed with you. You have made multiple statements like this. For example: "Whatever Adam... Your always the king of everything and your so frigging right on everything." What was the point of that? Do you just want to be a dick? Do you think that will help make your point? I can't speak for Adam, but I contributed to this discussion because I honestly wanted to understand your point. "Whatever Sean and I thought you where smart enough to see what it is that is being proposed." Again - how was this helpful? We don't agree with you. Stop taking it as a personal attack and grow the hell up.
Comment by External U.
12439 | May 03, 2014 08:21:49 PM GMT
Ray, Nobody mentioned the foreach, it was the for in array loop, in every language they only hold the element not the index. That was the discussion was about back then and its on my blog as well, not the foreach loops, so I will stand by that statement. Sean on the other hand attacked first, so I am on the defensive when Adam and Sean and maybe you are looking at the fact that it is wrong and you are the ones who can't see it. If you look at this from a sinlge application running on ColdFusion, I can't understand your reasoning. But I am talking about 30, 40 hell even 500 sites running on ColdFusion. It is not the responsibility of these 500+ CFML Applications to report back to System Administrators about issues that are out of their control. That is what needs to change. I know if I was a hosting provider and had 20+ sites all taking control of the exceptions and when it came too ColdFusion having issues with DB connections and other things like ColdFusion not catching and reporting its own internal errors, runs a bit thin if you cant understand that. So lets say we have a lock, in my case a read / write lock exception. It is only thrown because the Database has become unresponsive to something holding it up, when I look further into this I find a timeout trying to connect to a DB. I then report this to the hosting provider, they place it low priority and maybe user error (I dont know I am guessing here) but if they go and look at the ColdFusion logs they see nothing. Yet how many of these 20+ sites are also experiencing this same error on multiple DB servers? If it was me I would like to see ColdFusion log these things, not everything but just these serious ones that bring down a CFML application. Or what if one of these sites are a rouge site doing things that brings other sites down, that are not logged in ColdFusion logs. Look I know most host are on the ball with that example, but at the end of it all, its still an example that shows what I mean. Or how about mail server issues, that everyone is having but doesn't report it and it turns out that the mail server is down, I think if ColdFusion knows this is needs to report this. I mean one or two may not have the problem, but the majority using that server could be. How is a hosting provider going to know who it affects if ColdFusion is not logging this? Everyone has still focused on the CFML code block that I mentioned, I only used that as an example to say hey I have an application here that is logging and doing what it should be doing. But ColdFusion is not, if it is good enough for the OS to log the error and Java to log an error if it thinks it serious enough to do so, why can't ColdFusion do the same. Not leave it up to one or 20 sites running under it, but give the onuses right where Sean said it should be. ColdFusion, as it is the framework!!
Comment by External U.
12440 | May 03, 2014 08:49:00 PM GMT
Hi Andy, Personally, I wouldn't change *default* behavior (and agree this is an ER, instead of bug). That said, I do have an idea for CF Admin's "Logging Settings" page: [ ] Log all captured errors. When enabled, all captured errors are logged to captured.log (or w/e the filename would be). I understand the sys admin wants to see ALL errors for ALL sites on a shared hosting server. So sys admin could enable that setting for a bit, then review all CF's log files (including captured.log), then disable the setting. Just an idea. Thanks!, -Aaron
Comment by External U.
12441 | May 04, 2014 05:07:31 AM GMT
Aaron, yes even that would work. But I am not sure they would want to see every error though. I mean if its a user fault or specific only to one website, no that should not be captured. And it doesn't need to be captured, ColdFusion can decide based on the same error, info, warn as to which should be passed on only or logged before passing on. Whatever the solution an error should be in one place, having another file for logs when one already exists is overkill.
Comment by External U.
12442 | May 04, 2014 05:22:56 AM GMT
The proposed feature to have a toggle for "capture all logs" would indeed be helpful.
Vote by External U.
12454 | May 05, 2014 03:00:16 PM GMT
Andrew, I just don't get it anymore. It sounded to me like your ER was: "Even if I try/catch an error, I want CF to log it." I don't agree with that, but I understand it. But then you go and say this: "But I am not sure they would want to see every error though. I mean if its a user fault or specific only to one website, no that should not be captured." So... wait. You want CF to log errors. CF only DOESN'T log errors when it is in try/catch, for the reasons we discussed below. (Ie, in a try/catch the user is responsible.) You don't agree with that logic - that's fine. But now you are saying you DONT want to log in certain circumstances - like it being on one web site. So now the logic is: If an error occurs, I should use some set of rules, that you haven't defined clearly, to decide if I should log or not. Can you *precisely* define what case you want CF to log where it is NOT logging now? Because you are being nebulous now.
Comment by External U.
12443 | May 05, 2014 03:09:39 PM GMT
Is there an "unsubscribe" button? :)
Comment by External U.
12444 | May 05, 2014 03:23:20 PM GMT
A toggle to temporarily turn on such logging of captured errors would indeed be useful. No need for it to be any more complex than that if considered for addition.
Vote by External U.
12455 | May 05, 2014 03:45:41 PM GMT
No ray... Only the logs that would be helpful to trouble shoot System Administration issues, like ColdFusion having trouble communicating with a DB, this error is not the fault of the CFML Application, but it is something that System Administrators will need to know. Not when those sites start complaining.
Comment by External U.
12445 | May 05, 2014 08:27:14 PM GMT
So the rule is: Log errors inside a try/catch but only if they are X, which you have defined as "helpful to sys admins." Do you recognize that that is still nebulous? You need to get more precise here. Personally, I'm even more against this now. I can see... although not necessarily agree... a toggle for logging stuff caught in try/catch. But you are now saying, "yes, we will log stuff in try/catch, but only some stuff." I think that is even worse than the original request (as I understood it anyway).
Comment by External U.
12446 | May 05, 2014 08:31:13 PM GMT
Well yes, I dont think errors that are actually caused by a file missing on the server, or exceptions like that need to be logged by ColdFusion. Here is one stack trace, that happens about 3-4 times a wekk, it is not the cause of my Application but it is something that ColdFusion itself throws because it is expecting it. But as this exception is not the fault of me, but ColdFusion itself loosing the scope for whatever reason. The following is also related to an exception that I see that is a null pointer. As I said in this case, this is not the CFML Application at fault here, yet it appears to be a serious uncaptured exception in ColdFusion. For 3 years now I have been trying to get Adobe or someone to fix it, yet there is nothing in the ColdFusion logs that will help at all track this down. I have had to even do something that I am not allowed to do, just to see why this error is happening, but can't get it fixed because it is never logged by ColdFusion. If you follow this, it appears that the method in ColdFusion 10 to get ApplicationSettings a ColdFusion function fails and is not logged by ColdFusion, but is captured by the CFML Application. These are the errors that I mean. coldfusion.runtime.UndefinedElementException: Element DATASOURCE is undefined in SETTINGS. at coldfusion.runtime.DotResolver.resolveSplitNameInMap( at coldfusion.runtime.CfJspPage._resolve( at coldfusion.runtime.CfJspPage._resolveAndAutoscalarize( at coldfusion.runtime.CfJspPage._resolveAndAutoscalarize( at cfCFORMUtil2ecfcDVAPR-1165099099$funcGETDEFAULTDATASOURCE.runFunction(D:\home\\wwwroot\coldbox\system\orm\hibernate\util\CFORMUtil.cfc:93) at coldfusion.runtime.UDFMethod.invoke( at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke( at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke( at coldfusion.filter.FunctionAccessFilter.invoke( at coldfusion.runtime.UDFMethod.runFilterChain( at coldfusion.runtime.UDFMethod.invoke( at coldfusion.runtime.CfJspPage.
Comment by External U.
12447 | May 05, 2014 08:37:40 PM GMT
Sorry that should mean NOT needed to be logged if it is a file missing, if it is the fault of the CFML Application.
Comment by External U.
12448 | May 05, 2014 08:42:50 PM GMT
So crazy question. If you think this is a bug with CF (it certainly can be!) and the try/catch is preventing it from logging... why not remove the try/catch? I mean you say you have been trying to get it fixed for 3 years but you have trouble gathering data. Remove the try/catch. The stack trace you posted is rather clear. You tried to use a key (datasource), of a structure (settings) that did not exist. Perhaps your application has a race condition in its setup logic? Would you like to share the code with me (off of this bug tracker)?
Comment by External U.
12449 | May 05, 2014 08:45:05 PM GMT
No Ray, that is the issue in this case. The Application is not at fault here, if it is i is not something as simple as that. I have asked Luis many times to look at why this error happens once in about 1000 hits and so far Adobe and he is ignorant of this error. Like I said, you have to go looking deep into that problem to actually see what ColdFusion is doing, there is one thing ColdFusion is looking for and failing and the exception will be either this or a NULL pointer exception. But the question is why does this section of code public string function getDefaultDatasource(){ var settings = application.getApplicationSettings(); // check orm settings first if( structKeyExists( settings,"ormsettings") AND structKeyExists(settings.ormsettings,"datasource")){ return settings.ormsettings.datasource; } // else default to app datasource return settings.datasource; }; Fail 1 in 1000 hits or give or take a few thousand more. The line that is actually failing is this line? var settings = application.getApplicationSettings(); Further logging, and debugging shows that the Application is still very much alive, so why is it throwing an error on this line? We can't get to the bottom of it because ColdFusion doesn't log this exception that it throws. So its not clear cut, and something that I have had to argue with, because people like you Ray automatically assume that the cause is as simple as you think it is. But it is not...
Comment by External U.
12450 | May 05, 2014 08:53:35 PM GMT
Looking at that stack trace, I strongly suspect it's some sort of race condition bug in ColdBox around application timeout / restart...
Comment by External U.
12451 | May 05, 2014 08:56:39 PM GMT
"because people like you Ray automatically assume that the cause is as simple as you think it is." You do realize myself - and MULTIPLE other people here in this thread - have been TRYING to help. You may want to consider that if MULTIPLE people do not understand you, then maybe, just MAYBE, you aren't being clear. Step off the personal fraking attacks man, it is NOT helping. I still say this smells like a race condition issue. Have you tried testing w/ a load tester?
Comment by External U.
12452 | May 05, 2014 08:57:41 PM GMT
And because it is not logged, it is hard to see if anyone else is having the same issue. Or if there is an external force going on at the same time, because there is nothing in the ColdFusion logs. All I am saying is in cases like this it is Logged by ColdFusion as it is a serious error, I know what I am asking is going to be a hard. But a switch could be all that is needed for ColdFusion to log anything that is a serious issue regardless of CFML Applications. But I am sorry, I find it hard that if ColdFusion the framework is causing errors that is NOT the fault of any CFML running under it, ColdFusion should be responsible for logging critical exceptions so Adobe can gather more information. I mean if ORM fails it logs what it has too, before passing it onto ColdFusion to do what it has too, but it just passes it back to the CFML Application without doing anything. Yes if it is because I try to access an entity that is not mapped properly, well that should not be logged. But if it tries to connect to the DB and times out because the DB has fallen over , then yes it needs to be logged by ColdFusion as well as passing it onto the CFML Application.
Comment by External U.
12453 | May 05, 2014 09:00:57 PM GMT