Here's how the timeout processing handling works (this is based on CF5 code).
REQUEST TIMEOUT PROCESSING There are two Request timeout mechanisms controlled by the Settings page in Administrator: mechanism A). [_] Timeout requests after [____] seconds mechanism B.) [_] Restart at [____] unresponsive requests For mechanism A.) --If this mechanism is enabled, an expected completion time is calculated at the start of page processing by adding the current time to the number of seconds specified in the Administrator. If a ?RequestTimeout=sss parameter is included in the URL, this supercedes the Administrator entry. --Periodically as the CFML code is interpreted, the current time is compared to the expected completion time, and if it is greater then page processing is terminated and an entry is made in the application log. --This check is built into Allaire supplied software in cfserver, and cannot check for request timeouts during the execution of user-written or 3rd-party-supplied software, such as CFX tags or COM, CORBA, and JAVA objects --Database queries are similar to the execution of user-written and 3rd-party, except that query timeout values are passed to the database driver, and it is expected that the driver will return with an error status when the timeout has elapsed. --The calculation of an expected completion time is subject to problems when the current time (measured in milliseconds), and the timeout time (seconds X 1,000), add up to an integer value larger than 32 bits. In this case, the expected completion time is smaller than the current time and the page times out on the first check. This happens every 49.7 days. Bug #23429 (see TechNote 20691). For mechanism B.) --This mechanism can be enabled in addition to mechanism A. It is used to restart the cfserver when too many pages escape the timeout in mechanism A. --If this mechanism is enabled, a separate thread of execution is started in addition to the threads used to process page requests. This thread does not execute any page requests, but sleeps for a number of seconds and then checks all currently processing pages to see if they are past their expected completion time. --The time that this thread sleeps (i.e. the "scan" time) is the number of seconds specified in mechanism A. If this is less than 30 seconds, then a scan-time of 30 seconds (hard-coded) is used instead. In no case will a scan be made more frequently than 30 seconds. --This mechanism does not terminate the execute of a page. If a page is found to be running past its expected completion time, an entry is made in the application log and the count of unresponsive threads is incremented. Note that the overdue page may still complete in the future, thereby decrementing the count of unresponsive threads. --This mechanism will never count more that one unresponsive page per scan. That means that there is a minimum of 30 seconds (or the value from mechanism A if it is greater than 30) between the discovery of unresponsive threads by this mechanism. --If this mechanism discovers an unresponsive thread, and incrementing the count makes it equal to the number specified in the Administrator, then the cfserver is stopped. The cfexec process is expected to restart the cfserver. --If the maximum number of unresponsive threads specified for this mechanism is greater than the number of simultaneous threads specified in Administrator, then the number of simultaneous threads is used instead. It is impossible to have more unresponsive threads than there are simultaneous threads. -----Original Message----- From: Smith, Matthew P -CONT(DYN) [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 28, 2002 2:27 PM To: CF-Talk Subject: RE: unresponsive threads crashing cf Thanks for the response. I have done some research online, both with Google and on the Macromedia Forums. http://www.macromedia.com/v1/handlers/index.cfm?ID=22707&Method=Full&PageCal l=/support/index.cfm Above states that the error "no entry for thread nnnn" is harmless. However, is seems directly related to the unresponsive threads, although I think this is really just a symptom. As far as the why they take so long: Well, when the validation is cached locally, it only takes 0 to 30 ms. The remote call to the third party web service seems to be hit or miss, and that's where the delay seems to be occurring. It was only taking 6 seconds most of the time, although it would slow once in a while. What bothers me is two things: 1. It seems the templates are being allowed to exceed the timeout in CF administrator, CF administrator setting: Timeout requests after 90 seconds "Warning","304","08/28/02","06:53:13",,"Template: D:\Inetpub\wwwroot\foo\dverify.cfm, Ran: 102 seconds." 2. It also seems to be ignoring the cfhttp timeout attribute (timeout="90") When a request is made, does that take an entire thread until the request is finished processing? Why aren't the threads being reallocated after the 90 second timeout? As you can see, the first unresponsive thread remained in the count for 37 minutes. It would seem CF should be able to reuse this thread once the request times out.... I will try to adjust the unresponsive requests. This is a bit of an old server, especially for production. But on a single processor, allocated 3 threads, it would reboot after only 1 or two by your recommendations. That would seem to just make the server restart more often in this case. ; ) >>The CFadmin >>default setting makes the restart number greater than the total number >>of threads, so CF never restarts even if all threads are unresponsive. CF admin settings: Limit simultaneous requests to 10 Restart at 10 unresponsive requests What is the difference between a thread and a request? Matthew P. Smith Web Developer, Object Oriented Naval Education & Training Professional Development & Technology Center (NETPDTC) (850)452-1001 ext. 1245 [EMAIL PROTECTED] >>-----Original Message----- >>From: Chris Norloff [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, August 28, 2002 12:14 PM >>To: CF-Talk; [EMAIL PROTECTED] >>Subject: Re: unresponsive threads crashing cf >> >>Search the Macromedia knowledge base, I think there's information there >>about CF admin settings. Also, search on information about how CF handles >>threads. >> >>You need to find why your .cfm templates are running so slowly - that's >>what's killing you. >> >>It sounds like the "restart at X number of unresponsive threads" is set >>too low. Generally that should be 80% of the number of threads. The >>number of threads should be about 3 to 5 per processor. The CFadmin >>default setting makes the restart number greater than the total number of >>threads, so CF never restarts even if all threads are unresponsive. >> >>Chris Norloff >> >> >>---------- Original Message ---------------------------------- >>from: "Smith, Matthew P -CONT(DYN)" <[EMAIL PROTECTED]> >>Reply-To: [EMAIL PROTECTED] >>date: Wed, 28 Aug 2002 10:30:22 -0500 >> >>>I am having a problem with unresponsive threads crashing the server. It >>>seems that they are not being released even after they exceed the timeout >>>specified in cf administrator(90 seconds). >>> >>>It took over 37 minutes for the same template to generate unresponsive >>>threads. Why doesn't CF drop them when they exceed the time limit? >>> >>>"Information","238","08/28/02","05:52:49",,"The ColdFusion Application >>>Server started." >>>"Warning","88","08/28/02","06:53:12",,"Template: >>>D:\Inetpub\wwwroot\webServices\deersValidation.cfm, Ran: 101 seconds." >>>"Warning","304","08/28/02","06:53:13",,"Template: >>>D:\Inetpub\wwwroot\foo\dverify.cfm, Ran: 102 seconds." >>>"Warning","426","08/28/02","07:06:19",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 1. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","07:06:19",," !! CFTrace::logThread(304) has >>no >>>entry for thread 304" >>>"Warning","426","08/28/02","07:12:19",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 2. >>>[D:\Inetpub\wwwroot\Cantrac\dverify.cfm]" >>>"Error","426","08/28/02","07:12:19",," !! CFTrace::logThread(324) has >>no >>>entry for thread 324" >>>"Warning","426","08/28/02","07:16:49",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 3. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","07:16:49",," !! CFTrace::logThread(88) has >>no >>>entry for thread 88" >>>"Warning","426","08/28/02","07:18:19",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 4. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","07:18:19",," !! CFTrace::logThread(464) has >>no >>>entry for thread 464" >>>"Warning","426","08/28/02","07:21:19",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 5. >>>[D:\Inetpub\wwwroot\Cantrac\dverify.cfm]" >>>"Error","426","08/28/02","07:21:19",," !! CFTrace::logThread(327) has >>no >>>entry for thread 327" >>>"Warning","426","08/28/02","07:43:49",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 6. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","07:43:49",," !! CFTrace::logThread(568) has >>no >>>entry for thread 568" >>>"Warning","426","08/28/02","07:55:49",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 7. >>>[D:\Inetpub\wwwroot\Cantrac\dverify.cfm]" >>>"Error","426","08/28/02","07:55:49",," !! CFTrace::logThread(129) has >>no >>>entry for thread 129" >>>"Warning","554","08/28/02","07:56:44",,"Template: >>>D:\Inetpub\wwwroot\webServices\deersValidation.cfm, Ran: 210 seconds." >>>"Information","129","08/28/02","07:56:45",,"A long-running request >>returned. >>>The unresponsive thread count is down to 6. >>>[D:\Inetpub\wwwroot\foo\dverify.cfm]." >>>"Warning","129","08/28/02","07:56:45",,"Template: >>>D:\Inetpub\wwwroot\foo\dverify.cfm, Ran: 211 seconds." >>>"Warning","426","08/28/02","08:00:19",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 7. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","08:00:19",," !! CFTrace::logThread(308) has >>no >>>entry for thread 308" >>>"Warning","426","08/28/02","08:04:49",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 8. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","08:04:49",," !! CFTrace::logThread(554) has >>no >>>entry for thread 554" >>>"Warning","426","08/28/02","08:07:49",,"A request exceeded the timeout. >>The >>>unresponsive thread count is up to 9. >>[D:\Inetpub\wwwroot\foo\dverify.cfm]" >>>"Error","426","08/28/02","08:07:49",," !! CFTrace::logThread(129) has >>no >>>entry for thread 129" >>>"Fatal","426","08/28/02","08:09:19",,"Unresponsive thread threshold >>reached. >>>Restarting service." >>>"Information","177","08/28/02","08:09:23",,"The ColdFusion Application >>>Server started." >>>(ETC) >>> >>> >>> >>>The template uses a custom tag call that does a cfhttp call to another >>>template on the same server, trying my hand at a pseudo web service. >>> >>>Basically: >>>1. Template calls custom tag for validation. >>>2. Custom tag calls (local/same cf server) web service url >>>3. Web service url/template checks if local cache(ms sql db) if user >>>validation expired. If not expired and validates properly, returns "1". >>>4. If expired: >>> Calls a third party web service, which we validate against. >>> Validation fails, return "0" >>> Validation succeeds, insert to local db cache, return "1" >>> >>>I hope that makes sense. >>> >>>Could that cause problems? I would guess that it would take two threads >>as >>>one template calls another... But that shouldn't be to bad. >>> >>>We've tried tweaking cf administrator a bit, but we're not really sure >>which >>>setting to play with. >>> >>>Thanks for any help. >>> ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
