Ufitzi, you say "I intentionally left the default storage as was, since it did not seem to be affecting any other sites." Well, right, that's what I confirmed above. I noted that you had not changed the default, but only tested it as the clientstorage for a given app, and it failed. You go on to say, "I've confirmed the stability of all other sites using client variables", but my point was that you seem to have said that you're asserting that these other sites use the same clientstorage. How do you know, for sure? You seemed to be saying that a given DSN works for one app, and not for another. That just seems unusual. (As you note, there's that one hitch that the app name is used for the cdata. I would have asked what was the value of the appname when the app was failing, but you're saying you tried changing it, and I'll assume to a reasonable value, and you say it still fails.) So anyway, I was proposing that you run the simple little single line of code in the WORKING app/sites, to confirm that they are indeed using the DSN that you think they are. Seems worth double-checking, since you think they work with a DSN where another app fails. Let's just confirm that, rather than trust it from eyeballing the code. As always, just trying to help. ... View more

Ufitzi, here's my take on the situation. I have some background info (to make sure we're on the same page) and then something for you to try that may really help with your problem. You had said, "As soon as I remove the clientstorage attribute from the Application.cfm file, the site breaks." That would be because the CF Admin is still set to use the old DSN as the default. The admin page on client variables has 2 purposes: to let you define DSNs to server as client var repositories, and to name which should be the default if code doesn't set it itself (like you did when you set the clientstorage attribute). So you did step 1, added a new DSN. Then you skipped step 2 (set it as the default) and used code instead to set the clientstorage, first to use cookies, then to use the new DSN. When you removed it, you went back to using the old DSN, as it's still set as the default. You could finish step 2, telling the Admin to use the new DSN as the default client storage. That should make the one (and all) apps work. But your concern that "only 1 app breaks" using the old DSN is indeed curious. There's little reason for that. They would all access the DSN the same way, if all on the same server and using the same DSN for their client storage repository. I would challenge you to test to make SURE that the "other" apps really don't have their own clientstorage defined. It sure sounds like they do, and that they're not using the "bad" old one. It can be tough to confirm, because a number of things could throw you off. First, the apps may be using application.cfc, rather than application.cfm. In that case, the latter is ignored and you have to look in the application.cfc for what's really controlling things. Second. either way, the code could be including (or invoking) another application.cfm or .cfc after the code you see that's setting (or not) the clientstorage attribute. You need to be sure you have confirmed that's not the case. But here's some good news: there's no documented to confirm what a given app is using for its clientstorage, but there is an unsupported way: <cfdump var="#Client.getPersistSettings().get("clientstorage")#"> Of course, that needs to be run in the scope of whatever app whose client storage you are trying to check. Be careful about mistakenly running it in some test directory outside of the app's. Let us know if any of this helps. ... View more

I meant to comment on that, Wladimir. I can't see how that would cause a crash, no. He was focused on your cf/logs. I recommended you look at your cf/runtime/logs. Any news from that? Or any of the other info I offered? Have you considered enabling Jrun metrics? Have you looked at CFSTAT? The answers are often there among the various diagnostics, provided or that can be enabled. ... View more

I have a few thoughts that may help you, Wladimir. It's a long-ish reply, but I hope it has some value for you or others. There's been some discussion of looking at logs, and that may help, but I think you'll need to look at far more than what's been mentioned. For instance, BKBK said to look at the "application, exception and server logs all matter", and that may be true, as far as the [cf]/logs/ are concerned. But you want to be sure to check out the [cf]/runtime/logs/ as well (if in multiserver/multi-instance mode, see [jrun4]/logs/). These other logs (including ones named [server]-out.log and [server]-event.log) are often far more helpful in understanding the cause of errors. Even then, though, they're often still not enough. There may also be hs*.logs in the [cf]/runtime/bin/ [jrun4]/bin/ that offer additional info on jvm crashes, if that's what's happening. Sometimes, it's not that CF crashes but that it's simply hung up as all request queues are busy. In that case, you need to know what's going on in the CF engine when things go bad. One thing that helps is if you enable jrun metrics, which logs status info at a chosen interval (such as every few seconds). The CFSTAT command (built into CF, in the [cf]/bin directory) can help as well, as can perfmon stats (though not on Linux). I discussed these and other sorts of resources for troubleshooting in a talk I gave at Max (at the CF Unconference) called, "CF911: Tools and techniques for Troubleshooting", which you can find online at http://www.carehart.org/presentations/#cf911. Hope that may be helpful. I'll just add in conclusion that there's always an explanation to CF hanging up. It's not "just broken", so it's a shame when hosts (and others) just "restart CF" to make the "problem go away". There's always a root cause, and as in your case, it repeats, so the problem will come back. The challenge is to find that root cause, when it "goes rogue". The issue may be due to CF config, jvm config, jvm version (there's a known issue with the built-in jvm in CF8, but you're on 7). It may be due to load (perhaps unexpected). You may be running out of memory or CPU. Your rackspace techs don't clarify. Since you're on 7, there's also a known issue of file uploads being a potential killer in that they use up memory (equal to the size of the file uploaded) that's never released. There's a hotfix for that. See http://www.adobe.com/go/kb401239 (and in my experience, it has nothing to do with CFCs, as suggested in the title and description). If you're running out of memory in CF, I'd highly recommend this (and it's not applied if you've applied even the latest cumulative hotfix for CF7). And speaking of hotfixes, I find many shops still running on the original release of whatever they have (such as 7.0). You should at least move up to 7.01 or 7.02. And even then they've often not applied cumulative hotfixes (or individual ones). Many times there are problems that are solved with these. Going back to the discussion of memory, are you (or they) tracking memory use within CF? whether by watching the memory used by the jrun process (less effective) or watching memory use within CF (more effective)? The JRun metrics can show you, or there are available java methods you can call (for instance, see http://www.petefreitag.com/item/115.cfm). Finally, there are also useful commercial tools like FusionReactor and SeeFusion which can help, and they're more than "just monitors", in that they track information that you can review after a crash (and especially more in FusionReactor, which does tremendous yet lightweight logging of lots of details about running requests, queries, and more). I use all these tools and logs (and more) when I help people solve these kinds of problems. Half the battle is knowing the tools and how to connect the dots in the diagnostic info they provide. I hope the info above may help, and of course this forum is a great resource so ask away. Note as well that there are various companies that can help also, whether on-site or over-the-web. See http://www.cf411.com/#cfconsult for a list of several. Some require days at a minimum, while some (like myself) have no minimum. Sorry if that sounds like a sales pitch to some. It's really not, and I've tried to offer a lot of info for free above and on my site (carehart.org). But sometimes people just want to make the pain go away as fast as possible,and I just want them to know they don't need to suffer if they'd rather pull in some help. ... View more

Dan, besides what NeoRye offered, given the "24 hour nature", I would wonder first if you may have the CF Admin client variable purge time set to that 24 hours (it defaults to 1 hour 7 minutes, and people often raise it without considering the implications.) And don't ignore this because you "don't use client vars" I could elaborate, but just check first. Also, do you have cf's debugging output enabled? even if restricted to some ip addresses? Try turning that off, too. Finally, it may pay to analyze the web server logs to see if the 24 hour limit may really be preceded by a spike of some certain requests, or type of requester (scheduled task, load test, spiders, bots), or if the DB may have its own glitch that makes CF instead a victim. As Neo proposes, FR may help here. It has tremendously valuable logging (low-overhead) that can help you spot such issues. More at fusion-reactor.com. ... View more

Glad I could help, Libby. ... View more

Glad I could help, Ciarán. ... View more

DCwebGuy, about your issue that using the CF8 Server monitor gets "coldfusion server is unavailable", check out a solution that I blogged about: http://carehart.org/blog/client/index.cfm/2008/11/7/cf911_cf8mon_cf_unavailable Hope it helps you or future readers of this thread, searching for info on that problem. ... View more

Libby, I would suspect that all this is saying is that whatever the scheduled task was you were trying to run took too long and exceed the "timeout requests" setting in your CF Admin. The error on the CFOUTPUT is a classic one: it leads one to think, "how could a CFOUTPUT exceed the time limit?", but in fact what's happening is that the tag that preceded it is what took too long. What happens is that CF can't timeout requests that are in native threads (a java technicality). What that translates to is that things like CFQUERY, CFHTTP, CFINVOKE of a web service, etc, which talk to external resources, can't be interrupted, so that when the requests returns and proceeds to the next tag (often a CFOUTPUT, or perhaps a CFDUMP which reports as the same thing), it THEN reports that THAT tag is what exceeded the timeout. Anyway, since under the covers scheduled tasks do a CFHTTP to execute whatever URL was listed (even if it's local to the same server), I would suspect that it was the CFHTTP that took too long. Now, if this were code you owned, I'd say add a TIMEOUT attribute to the CFHTTP (or CFINVOKE or CFQUERY, though it's not always honored for the latter). But since this is a scheduled task, you're right that you can't edit the code. But the good news is that the scheduled task interface in the CFADMIN (as well as the CFSCHEDULE tag) does offer a timeout option. Hope that helps. ... View more

When you do the uninstall/reinstall, do you delete the coldfusion8 directory between steps? If not, I wonder if there may be something that gets left during the uninstall that is still a remnant of the bad initial install. I'll say that this is not something I've ever heard of, so I'm grasping at straws. For it to get a BSOD, given your mention of it recursively creating directories, I'd wonder if perhaps some deep directory structure has been created that somehow CF is trying to read/load/process and that's when the problem happens. Or that could be red herring, but some other remnant of the previous attempt remains. ... View more

Jim, I just noticed one other thing you'd said: "during these times, calls to the web services never return any data" So, that's potentially still another issue. It wasn't clear if you were saying any other CF requests were running. I focused on your saying "the site was unavailable", so can you report if other CF requests did run? Also, what may help you too is to see what the web services would respond with if requested directly in the browser. Many don't realize you can request a CFC as a web service on the browser, which can help to confirm if/how it responds. If you had a test.cfc with a method called getdata, that took an argument of myarg and a value of 1, you could request that on the browser using http://yourserver/yourpath/test.cfc?wsdl&method=getdata&myarg=1. If you need to pass in other arguments with simple values (text, numbers), just keep adding them. Finally, you could also use a debugging Flash player or proxy tools like Charles to watch what traffic is going from/back to your Flex browser client. I list several such proxies in a resource I keep, http://www.cf411.com/#proxy. ... View more

Jim, no, there are no features to set "windows of availability" for CF. So either CF was up and responding, or it wasn't. Even if it was, it may also be that your problem was with IIS. The first thing I'd do is check the Event Log (Application) to see if CF was indeed up or down. Look for event ids 3 and 4 for the "source" being the name for your CF server as shown in the event viewer. Then I'd check if the web server itself may have gone down, using the same approach (though it's less likely). I'd also check the Event Logs (application or system) for any indications that the IIS application pool(s) may have have gone down. It's not unusual for the pools to recycle, but being down for an extended period may point out a web server problem (by which CF often gets blamed unfairly). If that's not the issue, I'd then check the IIS logs, to see if indeed requests were being processed during that time. When people say "the server is down", that just means their requests were not processed. It may well be up and processing other requests. You'd also want to check whether cfm or other extensions were being processed at the time, their status codes, and the time-taken for each request (if enabled for the log in the properties for the site in IIS). And when people report that it is "down", I'd also run requests using CF's built-in web server if it is/was enabled. If it responds on that web server, but not IIS, then that confirms a problem either with IIS or the web server connector between CF and it. The default port for CF's built-in web server is 8300, 8500, or some variation like it, depending on the version of CF and other things. You can confirm if it's enabled and what port it would be by looking in the jrun.xml file. For more info, see resources like http://livedocs.adobe.com/coldfusion/7/htmldocs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ColdFusion_Documentation&file=00001752.htm. I realize you mention that these are web services requests coming in. But as far as CF and IIS are concerned, those are regular requests, so they go through the same web server process and CF request queue. (You don't mention what version of CF you have--whether 6, 7, or 8--and whether it's Standard or Enterprise. In CF8 Enterprise, there is a new feature to give web services requests their own set of request threads. You can see that in the CF Admin "Request Tuning" page.) Finally, I'll point out that besides the web server logs, this is a problem that would be well served by having a tool like FusionReactor (fusion-reactor.com) and its great logging features that track all kinds of details about each page request. Of course, it's a great monitor and notification tool, with optional request protection features as well. I'll say in closing that if anyone has problems like the above and would like some help (someone looking over your shoulder to help you solve such problems), I'm happy to provide that sort of support, as discussed at carehart.org/consulting. But as you can see above, I'm also happy to share the info for people who prefer to solve problems on their own. ... View more

Wow, that's pretty huge news. Thanks so much for sharing, AGICroeder. I did some digging and just found this Adobe article that explains it more (and the top of the article has an update about the very October 2008 updates). It explains it also in the context of versions of Flash that are rolling out these new policies. http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html (It turns out that's also the same page that the error message points to, though it names it http://www.adobe.com/go/strict_policy_files.) So what are people to do? AGICroeder said he 'simply created a "Master" policy file and added a meta-policy line to allow the multiservermonitor-access policy'. Rather than ask him/her, I tried things out myself and here's what I did. S/he can clarify if they did anything difference. I created a crossdomain.xml file (we didn't need one before) and placed it in the root of the web server (above where the CFIDE is, which is where the multiservermonitor-access-policy.xml was needed per the previous instructions for CF8. See the article I had written, mentioned above, for more on where that may be located for you.) In that file, I placed these lines: <?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM " http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <!-- Policy file needed from Flash 10 forward to permit ColdFusion Multi Server Monitor access in CFIDE --> <cross-domain-policy> <site-control permitted-cross-domain-policies="all"/> </cross-domain-policy> (I've pasted some XML code above. If it doesn't show up, I'll create a new note with the code as an attachment.) Note that, I discuss in the article, if you make changes to these XML files, you may still see errors (or things not working right) despite your change, but that's just because the browser/flash caching the XML. You can either force a hard refresh (hold down shift while refreshing the page), or close and reopen the browser. Hope that helps someone. I wonder if Adobe may come out with a CF technote about all this, as it's sure to eventually bite anyone using the MultiServer monitor, but CFers are often unaware of such changes in the Flash platform. I'll blog about it, for sure, but that won't be as far-reaching as a new technote. And I'll be sure you credit you for identifying it. (Would you mind sharing your name, or do you prefer to be listed just as AGICroeder?) ... View more

It's the "Maximum Number of Simultaneous Requests", available in the "Server Settings" (first section) of the Admin, on the "Setting" page in CF 7, and in the "Request Tuning" page in CF8. ... View more

I'm surprised by an assertion that this was due to a change in "the latest release of Flash". This cross-domain security model is quite long-standing. I'll say I'm sorry I didn't see your question earlier, because I wrote about this subject at length in part 4 of a 4-part series I did on the Server Monitor. (That's also further testament that this isn't a "new" issue.) I also would point out that while you changed it to permit "all" IPs, from a security perspective you can choose instead to create an entry for each IP or domain name of servers from which the Multiserver Monitor will be launched. You need to specify the domain names/ips on separate XML entries. And note that it's NOT about the IP of the client running the monitor, but simply that from which the MultiserverMonitor is launched (and the entries need to be made in the XML file of the server being monitored frmo the MS Monitor). Hope that helps, even if just other readers, if you're happy to leave it at "all". For more, the specific section of the article on the MultiServer Monitor and Cross-Domain XML is here, and the start of all the articles is here. ... View more

Mkane, I see what you mean. That is odd. The updates page does have a link to the individual CF7 hotfixes (after the list of the cumulative hotfixes for 7), but there is not the same link to the same sort of page for 8 (which Ian offered) after the list of cumulative hotfixes for 8. I don't know if anyone responsible will see this, but I'll drop a note to some insiders who may be able to help. As for notification of hotfixes, I'm not aware of an email one, but there is a feed for both hotfixes and technotes. I discuss it, and others like it, in an entry at: http://carehart.org/blog/client/index.cfm/2008/7/16/cf_technote_hotfix_security_article_feeds Hope that helps. ... View more

Glad to hear it may have been helpful, Scott. As for the GC error, well, I wouldn't say it was just because the GC process was "too active". It's always very active. But that particular error seems tied to that particular feature (new in 6) where if it determines that the JVM is spending "too much time" in GC that it will mark it as an out of memory problem. I've not heard of it happening yet with any other clients of mine. Yours was my first observation of it. Now, you propose that there may be a good bit of GC happening when sessions end, and that may be possible, but it should be pretty random that that happens, so I wouldn't call it a smoking gun. Really, I'd bet more junk is released to be GC'ed simply at the end of every request. There are ways to ask the JVM to log GC details to tell you when it's happening, and how often. It tends to be quite often with modern JVMs, but in different parts of the memory space, which is usually a good thing. But maybe rather than focus on how the JVM is operating, you might instead want to look at the bigger picture. Are you using lots of memory? It may or may not be possible to tell from the task manager, btw. The Server Monitor will be your best bet. It has a page showing memory usage as a chart which updates live over time. And as I explain in the articles on the Server Monitor, you DO NOT need to enable "start memory tracking" to see that chart. Now, if in fact you are using high amounts of memory, your mention of sessions, and the fact that you put a lot of info into the session when a user starts, is a real clue. I'm curious: do you do that whether the user logs in or not? If you do so even if they do not log in, then this could very well be the cause of a memory usage problem. Many don't think of this, but whenever a search engine spider, or other bots (or load test tool, or web service client), visits your site, they generally get a new session on *each page visit*, since they don't tend to present cookies, particularly the CFID/CFTOKEN/JSessionID that CF would have given them on their previous visit. So on each visit to every page CF creates a new session for them (if you have sessionmanagement enabled in your application.cfm/cfc), and also a new client repository entry (if you have clientmanagement enabled). It's a severe cause of problems for many people, in creating huge numbers of of sessions. Depending on what they do put in the sessions, and how long they set them to last, it could gobble up memory and hold it for a very long time. That's not a "memory leak", in the sense of bad code in the CF engine, but it can look like one. It can also hurt them in the large number of client variable repository entries created--and it doesn't matter if one says, "well we don't use client vars". Doesn't matter. If you have clientmanagement enabled, CF will create an entry (unless you checked an option in the Admin client variable repository details, called "disable global client variable updates"), and whether you've set the registry or a database to be your repository (in the admin as default, or in code using the clientstorage attribute0, it could have another severe impact. I mention that just because the problems tend to go hand in hand, if you go exploring. Thanks for your other kind words, too. ... View more

I'm a bit mystified that folks would offer that little bit of info and ask, "please advise". You say you're "not sure what's causing it to go down". Well that's job 1. You can't go on what people guess at. What do the logs say? And not just the [CF]/logs, but the [cf]/runtime/logs (or the [jrun]/logs, if on the Multiserver form of deployment). And do you see any *pid*.log files in the [cf]/runtime/bin (or [jrun]/bin) directory? I realize these may be new resources for you to consider, so sorry if I'm sounding a bit harsh. I'm just saying these are where you need to start looking. I'm sure someone might reply to your questions about Access, and certainly one could argue that you should never use it, but before concluding that they necessarily have anything at all to do with the problem, look instead for the facts provided by the log files. CF doesn't just go down for no reason. Or is the problem not that it goes down, but that it becomes unresponsive? You say you're on CF8. Is that Enterprise or Standard? If the former, what do you see going on in the Server Monitor? If you're on Standard, consider tools like FusionReactor or SeeFusion (commercial tools with trial editions) to help give you still more diagnostics to go on, or look into the JRun metrics feature. I realize that it's easy to feel at a loss, and that CF is a black box. It's really not. You just need to know where to look and how to connect the diagnostic dots. There's a good series of recent troubleshooting blog entries by Mark Kruger, starting at http://www.coldfusionmuse.com/index.cfm/2008/8/11/troubleshooting-part1-gathering-information. There are similarly compelling troubleshooting blogs from Steven Erat, Brandon Purcell, Robi Sen, and others. I'm not discouraging your asking here. I'm just trying to help give you more resources to consider. Hope that's helpful. ... View more

Kent, I see that many others have reported that error (doing a google search), but I see no ready answers. I saw something that reminded me of a connection string value that I've seen answer some problems. May be worth a shot for you: try adding this string to the connection string (in "advanced options") for your datasource: AuthenticationMethod=Type2 If it doesn't solve it, remove it. But keep it handy in case it ever may help with some other problem. Here's one other possible answer for you: http://www.webmasterkb.com/Uwe/Forum.aspx/coldfusion-server/3206/SQL-Server-2000-Windows-Auth Sorry I can't be more clear for you. ... View more

I'm afraid I have no answers for you. I was only pointing you to the few references I could find. It's not clear:are you saying you read them, and still have the questions? I've not read them. I would be surprised if your 2 questions weren't covered, even if the info is dated. As for your error, a google of it finds a few entries, one of which suggests their problem (not related to running CF or the wsconfig) suggested that installing the JDK (rather than the JRE) solved that. The wsconfig launches a java applet. You'd think the JRE should be enough, but it seems worth the shot. Sorry I can't be more helpful. The way these forums work is that you have to hope someone who's interested in the subject will open and read the messages. If not enough people are, you may not get much help, which is indeed a shame. Sometimes you may have to resort to posting your question elsewhere, in the hopes of reaching a still wider audience. I list several such places in a category of my site: http://www.cf411.com/#cflists ... View more

Are you successfully connecting from CF to that SQL Server already (other datasources working)? If not, then it may be that you can't connect to SQL Server at all. You haven't offered the error you got. What is it? Here's one possible error that a lot of folks get, with solutions: http://carehart.org/blog/client/index.cfm/2006/7/8/sql2k5_Error_establishing_socket It's the most visited of all blog entries I've ever done, so it seems to be something that many are pointed to. If that's not it, please report what your error is. ... View more

Running CF and the web server on separate boxes is called running CF in "distributed mode". You can find lots of discussions of it which may answer questions (and also help you ensure that it's something really worth doing). While some may have been written for CF 6 or 7, they'd still apply in CF8 (stuff for CF5 is likely too different to be useful for you). See, for instance: http://www.adobe.com/support/coldfusion/administration/cfmx_in_distributed_mode/ http://kb.adobe.com/selfservice/viewContent.do?externalId=121a0b29 It's interesting: I tried to find reference to the feature in the CF docs, both "Configuring and Administering CF", and "Installing and Using CF". The former makes no mention of it, which surprised me, and the latter (sadly) says that it's covered in the former (but it's not). I even looked in the 8, 7, and 6 versions of these manuals. Very curious. There are a few more technotes at Adobe.com that discuss it in the context of clustering, but you don't say you're doing that. Or are you? Anyway, are you getting an error? Or just wondering what to look out for? Problems people have had in the past are firewall or other port blocking/conflict issues between the 2 servers. ... View more

Just wanted to throw in here that for at least on of the errors referenced above, I had a client who saw it go away with an upgrade to 8.01 ( http://www.adobe.com/support/coldfusion/downloads_updates.html#cf8) and/or its 8.01 Cumulative Hotfix 1 ( http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403622). I can't recall which it was, but both are worth trying if you're still stuck. Besides 8.01 upgrading the JVM a bit (from 1.6.0_01 to 1.6.0_04), the CHF included mention of some related to image handling, and the specific error (like above) that I saw fixed was getting the "out of swap" errors which specifically reference "jbyte in C:\BUILD_AREA\jdk6_01\hotspot\src\share\vm\prims\jni.cpp" in the out log message (as does one of the above). Note that the error clearly shows this was running on the 6.01 hvm. The PID output shared above was also the same as what my client was seeing, in that the first line of the stack trace showed reference to the following on its first line: com.sun.medialib.codec.jpeg. That suggested that things had to do with image manipulation. I can't recall now if the code was using CFIMAGE or cfx_imagecr. Anyway, sorry I can't be more definitive. Some of the details are hazy for me now in retrospective. And I know that some of the "out of swap" space errors others are getting are not related to or resolved by this 8.01 upgrade. ... View more

Mark, thanks very much for the considered reply. I have to say, though, that I have been using your option 2 (meeting>end meeting). Sadly, that does just place them on hold. I even just did it again in the meeting I referred to before, and then revisited it (in another browser, where it did not recognize me from having been logged in as admin) and it still says "on hold". So really, it appears that this inconsistency in interface extends from the meeting set up to the tear down. I hope someone in a position of responsibility may see and address this some day. In the meantime, I'll keep your ideas in mind. Thanks again. ... View more