This makes my head hurt just reading about it ;)
There could be any number of things going on here. These are some things
you can do to troubleshoot (not in any type of order). Do you have a dev
box with 6.1 on it that you can recreate this on (to rule out server
configurations)? Have you tried serializing the LDAP results before
parsing them? Have you tried using try/catch blocks in your code? Do you
have variables that might be rewriting themselves (like multiple dc
entries)? Are you database server and CF server on the same box? Are all
the patches on your CF Server? Have you refactored your code so there
are fewer loops (or at least factoring a loop into a function)? Is there
code in the loops to keep you out of an infinite loop?
HTH,
Wayne
Aaron Rouse wrote:
The one specific example I am thinking and I will note I hate this
process and having to inherit the maintenance of it, but have to
maintain it and they will not budget much to allow for researching a
more appropriate solution. Goes something like this and it is more a
CFM page with some CFC calls.
CFM Page:
- Loops over alphabet
- For each letter(some it does first two letters like AA, AB, AC, etc
because CFLDAP returns incorrect record sets in CF 6.1 when past about
3200 records) it makes an CFLDAP call to pull out all names begining
with that along with something like 50 LDAP fields.
- Parses through those fields and checks lengths, trims, pulls out
data, and basically turns it into 60-70 variables for inserting into a
database
- Puts each person into a structure and appends that to an array
- When array is at a count of 50, passes to a web service(was a
component call but that used up resources and crashed the server,
before that was just single inserts and no array of structures but
that crashed quicker from lack of resources), all the web service does
is insert the data(currently with a stored procedure but nothing fancy
with the insert)
- After array inserts it calls the GC and tries setting the object to
blank so it re-initializes, but those were both added to see if it
helped any before that it only initialized that object once.
So curious if all that data manipulation was instead handled by an
object would that help it any at all? The only reason the current
object was added to this is because months after I got here and
inherited the process they moved the process from CF5 where it runs
rock steady to CFMX 6.1 where all the server crashes started. It
seems like it is the query or currently stored procedure calls that is
what is eating up the the server resources, when all said and done
there are probably 67k of those(like I said before, I hate having to
support this). I say it seems that way because once I stripped out
the inserts and put into a CFC then tried calling it as a web service,
the page would actually complete its nightly run most of the time.
On 3/9/06, *Wayne Graham* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Even though you can call the garbage collector, it's really only a
suggestion to Java to run the clean up than an explicit invocation of
the garbage collection. If I remember correctly, it has to do with
finalizing unreferenced objects and the algorithms Sun chose to run in
memory. Even if you're doing a lot of manipulations within a loop, you
shouldn't need to call java.lang.System.gc() as long as your properly
var your variables.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject
of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
--
Wayne Graham
Earl Gregg Swem Library
College of William and Mary
PO Box 8794
Williamsburg, VA 23185
757.221.3112
http://swem.wm.edu/blogs/waynegraham/
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
