CF Server hangs every few days

[EvolvedDSM]

Every couple of days, ranging from 1 day to 2 weeks, we get an application that hangs when trying to access a page that uses a database query. I have to manually restart the CF application server service to correct the problem. I am unsure what is causing this.

My Server.log shows multiple entries of the same error message, but reported in 30 second intervals (which I believe is due to the option in CF administrator "Timeout Requests after ( seconds ) [30]" )
Here is one line of the Server.log, and this line repeats over and over in close to 30 second intervals:
"Warning","jrpp-206","02/23/07","13:51:36",,"Thread: jrpp-206, processing template: C:\Inetpub\wwwroot\CFMX7\tagout\login.cfm, completed in 30 seconds, exceeding the 30 second warning limit"

this error message continued through "completed in 1009 seconds" before I restarted the CF service.

When I restart the server, is all back to normal. Sometimes it can go only a few days before hanging, sometimes up to 2 weeks. But rarely longer than 2 weeks without a hang.

I have read the "ColdFusion MX Hanging Condition Investigation" thread, but I didn't get much help from it. I couldn't tell if my problem was either of the cases described. So I've come here hoping that someone has the answer! 🙂

[Guest]

I would begin by doing a code/db design review to figure out if your code/db is optimized as well as scaling to the load you require.

Next, I would do one of two things -
A) Up the server's timeout value in the administrator
-or-
B) Use the timeout attribute where necessary to allow your code to run a little longer.

Next, limit the number of connections ColdFusion can make to your database to around 6 per CPU. If the database is busy, leave maintain connection on. Otherwise, turn it off.

Make sure your ODBC drivers are up to date.

How much memory is the JRun process using when you have to kill it?

What do the other logs say?

[EvolvedDSM]

Let me get your opinion on my situation then.

The application is a board that shows who is currently out of the building at my agency. This was created as a way for people, especially the receptionists, to see who is not here. The board is a table with every employee's name who is currently not available in our agency. It refreshes every 25 seconds to update employee status.

We have over 100 employees who use this board, however not all of them are making changes to the database at the same time. If I reduce the number of connections to 6, will that limit the number of people who can view the board, or will that limit the number of people who are making changes in the database at the same time? All employees need access to view this application, but only a small % of them are actually modifying the table.

[LL]

If you are running on MS Access, be sure to disable "Maintain Connections".
You will also likely benefit by using the Jadozoom JDBC Driver instead of the native ODBC drivers.
See http://www.adobe.com/go/2d2a7a19 and
http://www.adobe.com/go/tn_17034

If you are using an enterprise database with JDBC support, you may benefit by updating to the 3.5 JDBC drivers:
See
http://www.adobe.com/go/42dcb10a

You also may benefit from the "Database Design" section of this article:
http://www.adobe.com/go/tn_17054

[terribleted]

Thanks for the info folksk! I benefited from the input on my end as well.

[Guest]

No, reducing the number of connections has nothing to do with the number of people who can interact with your application. The setting tells CF how many connections to open at any given time. If all of the connections are busy, new connections will be queued until the next connection is available. If everything is working as it should, this queue should only last in the milliseconds.

One other thing, check the "Maximum number of cached queries" value in the administrator. By default it is configured for 100. Entirely too many. Drop it to 50.

[EvolvedDSM]

LL@Work -- thanks for the links. One of them recommended my max number of simultaneous requests be between 5-10 if the server has plenty of ram, so I dropped this to 10 from 105 originally. I don't know what effect this might have.

Ke4pym -- I've changed the max number of cached queries to 50 as suggested.

Since getting help from this thread, no hang ups but its still early in the week.

[hipjimmer]

Was the driver upgraded in your fix? We currently are experiencing the same problem.

[EvolvedDSM]

We didn't upgrade any drivers, or any patches. Our CF is the most current version and has been for months. I would like to note that it has been about 3 weeks since I posted my problem, and we have not had to restart the CF service yet! Thanks for all the info provided in this thread. Hopefully it helps someone else!

[hipjimmer]

We're running a fully patched (we think) version of 6.1 and all of our dbs are MS Access. We had no problems at all on CF 5 and this migration so far has been horrible for us. I'm hoping that the Jadozoom driver is robust enough.

[hipjimmer]

Evolved: BTW, are you running MS access dbs?

[EvolvedDSM]

Yes, MS Access. We typically do SQL db's, but I find working with Access to be much easier for editing and general changes when it's a small volume db.