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! :)

[ke4pym]

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@Work]

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 [url]http://www.adobe.com/go/2d2a7a19[/url] and
[url]http://www.adobe.com/go/tn_17034[/url]

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

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

[ke4pym]

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!

[terribleted]

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

:wink;

[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.