(IMO). I may be pointing you in the wrong direction but I would look carefully
at your client var storage. We had terrible problems with CF5 before we
changed to storing the client vars in a database with similar symptoms (in
essence) as what you are describing.
I can definitely recommend moving to RH ES (which you will need to consider
long term) and 2.1 has proved fine for us. In the meantime, I would swap to
storing the client vars in a MySQL database (but you will need to clear the
registry first). Search the archives of this list. How big is the registry at
the moment?
I hope this helps - if not I am sure that there are lots of people on this list
far more CF-savvy than me who having read this post may now chip in some
further advice.
M
> Hi Matt -
>
> We are running CFMX 6.1 on RH 7.3 with Apache 1.3.27-4. The machine is
> a Dual 1.5GHz Athlon server with 1.5GB of RAM and a 100GB 4-disk Level
> 5 RAID. We use MySQL 3.23.58, running locally (DNS and mail also run
> locally - this is our "primary" server for everything, we have 2 Win2k
> servers that aren't really used for anything except file storage.)
> Client vars are stored in the system registry, I've never set up a
> datasource for them, although I don't use the client scope in any
> applications (I use session scope, since there's no cluster.)
>
> We have about 61 active virtual hosts on the server, though only a
> handful really use CF or SQL. CF is a clean install of 6.1, and I've
> changed the JVM parameters to use 256MB of RAM. I'm still losing
> contact with CF about once an hour (I've got a cron job running to
> restart CF at 55 past the hour.) It doesn't happen EVERY hour, of
> course, but in the cfserver log, I have a number of these errors which
> seem to be at the heart of the problem:
>
> java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start(Native Method)
> at jrunx.scheduler.ThreadPool.spawnHandler(ThreadPool.java:239)
> at
> jrunx.scheduler.ThreadPool$ThreadThrottle.createRunnable(ThreadPool.java
> :404)
> at
> jrunx.scheduler.ThreadPool$UpstreamMetrics.createRunnable(ThreadPool.jav
> a:269)
> at jrunx.scheduler.WorkerThread.run(WorkerThread.java:62)
>
> The stack traces I've done have no jnpp entries, so it doesn't seem to
> be any pages causing the problem. (FYI, the scheduler is usually quiet,
> our clients send out the occasional newsletter, but that's only 1 task,
> and it doesn't correspond with all the crashes we've been getting.)
>
> I think that's the bulk of the data I've been able to gather about
> this. If you have any insights, I'd greatly appreciate them! :) Thanks
> in advance,
>
> Ken
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
