Skip navigation
Currently Being Moderated

"Java heap space" error and coldfusion crashes

Mar 16, 2010 7:05 AM

I have a coldfusion scheduled task that takes about two hours to run (about 4000 lines of code).  It does a number of cfquery, cffile, cfexecute with cffunction, cfloop, and cfif.  If works perfectly in the fifteen minute version that works with a subset of the data, but it frequently runs coldfusion out of java heap in the full record set run.  This then sometimes causes our public webserver to go down or malfunction until the coldfusion process is restarted.

 

When I posted about getting this to work initially last year, the solution was to put output="no" in every cffunction as apparently the whitespace generated by the code in all the cfloops was eventually enough to crash the server after a couple hours.

 

Recently, it has started to crash again as the record count has grown over the past year.  I put everything in a number of cfsilent tags, and it ran for one night, but now it is crashing again.

 

I'm not sure what to do next.  The cfexecutes log to a file not to a variable. The variables are in cffunction with var keyword with output="no" on the cffunction with coldfusion debugging checkboxes unchecked in the admin so in theory the fifteenth step/cffunction in the process should have the same memory available after garbage collection if needed as the first.  But obviously it doesn't as each step can run by itself but not sequentially unless limited in record count.

 

Any ideas?  Any known coldfusion memory leaks in 8,0,0,176276 Standard?  Any way to prevent coldfusion server from malfunctioning if one page runs it out of memory?

 
Replies
  • Currently Being Moderated
    Mar 16, 2010 7:31 AM   in reply to RickBergen

    IF you can't upgrade to enterprise you are definitely limited in options.

     

    With Enterprise, whether 64bit or not, you could run multiple instances of ColdFusion.  So you could have one instance with all of it's JVM memory dedicated to this resource consuming task, and another instance for your public web site.  This would at least allow application isolation so that the problems and failures of this task does not affect the other applications.

     

    But even with that, it is not going to solve the underlining problem that you are using up all the memory.  There is always limits in programming.  We have come a long way from the days where years were stored as two digits instead of four digits to save memory so that applications would not run out of it.  But it is still possible to create tasks that just plain use more memory then is available.

     

    When this happens you have to look at your application and see what you can do to make it more frugal with memory.  The first thought I had is does all this process have to be done in one request?  The main problem is that the JVM really can't do much with garbage collection in the middle of a request.

     

    Once we had a task to create several hundred PDF reports on a nightly basis.  When we tried to do all of this in a single request it would quickly use up all the memory.  What we did was to break up the task into a series of process that would process a handful of reports and then using a simple META refresh, generate a new request to process the next batch.  This allowed all the variables used in the previous refresh to go to garbage collection and eventually get cleared out while new requests where processing other reports.  We could also throttle the processing with the time between META refreshes to allow the server some breathing room between requests.

     

    This made the overall process run a while longer, but the server stopped failing in the middle of it.  Seemed a good compromise to us.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2010 7:36 AM   in reply to ilssac

    P.S. I don't know if a META refresh would work with a scheduled task.  I don't think the built in browser that ColdFusion uses to make scheduled task http requests would understand or process the meta refresh.

     

    But the same thing could be done with a master page that then makes a throttled series of <cfhttp....> http requests to a sub page that process a single batch at a time.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2010 8:46 AM   in reply to ilssac

    I'm with Ian vis-a-vis his comments about CF Enterprise edition.  You seriously should not be running a process that heavy on your user-facing CF instance.

     

    Beyond that, you seem to have made some efforts to minimise your memory footprint by guessing which bits of the code could need attention, but it doesn't seem like you've actually done any memory-usage profiling to check what's consuming the memory.

     

    Nine times out of ten it will not be a CF memory leak causing this sort of thing, it will be injudicious or unexpected memory consumption by the code.

     

    You should be verifying what's consuming the memory (using FusionReactor or the server monitoring build in to CF (Enterprise)).

     

    You also might want to get a second pair of eyes to go over your code.  Having said that... I'm not sure I want to volunteer to eyeball 4000 lines of code... ;-)

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2010 9:14 AM   in reply to RickBergen

    Is there any other tool that you could use to accomplish this task?  If the ultimate objective of the task is not "to generate HTML output," it might be argued that you are simply using the wrong tool for the job -- even tough ColdFusion is, after a manner of speaking, doing it.

     

    A very definite possibility here is that you are somehow building-up data within (e.g. global...) variables or hashes (structs...) that never get cleaned away.  They never get garbage-collected because they never become "un-referenced."

     

    One strategy that might help alleviate the situation is to put all of your variable references into global structures, e.g. named GLOBAL and/or LOCAL.  Then, at the top of each processing loop, you insert a statement like:  <cfset GLOBAL = StructNew()> .  Now, explicitly, the old structure (and everything in it) is thrown-away and a new empty structure is allocated.  This happens each time through the loop.  If you need to retain the values of certain variables, add explicit code at the top of the loop that sets-aside these variables (in another, temporary, struct), resets the main global struct, puts the variables back, and then resets the temporary one before proceeding.

     

    One of the characteristics of ColdFusion, particularly when you are using CFML tags vs. <cfscript>s, is that it is very easy for everything to wind up in a global scope.  Lots of things can hang-around in memory much longer than they need to.  All of which might not matter much if you are serving web pages (and recycling the worker-threads every so often), but it becomes a crippling concern when a thread runs for a very long time, such as multiple hours.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2010 9:21 AM   in reply to TLC-IT

    One of the characteristics of ColdFusion, particularly when you are using CFML tags vs. <cfscript>s, is that it is very easy for everything to wind up in a global scope.

     

    Interesting.  Do tell..?

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 16, 2010 9:37 AM   in reply to Adam Cameron.

    I'm not sure what the reference between the tag and script form or CFML means.  But I presume he is refereeing to what I alluded to.  That if you do not take steps to cause different behavior, a great deal of the data in a request will end up in the variables scope and this scope is not going to be dereferenced for garbage collection until the end of the request.  Thus requests that run for a very long time can become problematic.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 18, 2010 9:28 AM   in reply to RickBergen

    Point One:  All systems have limits.  Sometimes you just have to say that this is all that we can do with the tools we have to work with.  To quote Mr. Scotty, "I can not change the laws of physics Captain!"/

     

    Point Two:  ColdFusion is optimized as a web application server.  As such it focuses on the request as an atomic unit.  It does not naturally try to do overhead, housekeeping tasks, such as garbage collection, during a request.

     

    You can either try to break up your tasks into multiple requests to work within this framework, or you can try other garbage collection and JVM memory management settings.  But realize with the latter option you are choosing to optimize your CF to handle this scheduled task, which could have performance consequences to the day to day web severing tasks the server is also expected to perform.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 18, 2010 9:30 AM   in reply to RickBergen

    So you're prepared to have flaky code that crashes the server, but you're not prepared to have a trial version of a very robust piece of software which will help you solve your problem?  Where's the logic there?

     

    Equally... $299... how many person-hours is that?  Stuff all.  How much mucking around have you already done, and how much mucking around will you still need to do?  If it's an more than about three hours in total, you're costing your employers more money with your current approach than buying the software and short-circuiting all the blind fumbling about (no offence meant), replacing it with targetted, quick analysis.  Obviously having identified any problem there's still the person/hour cost to fix it, but you will slice your investigation time back drastically.

     

    Beyond a point, it's not sensible (it's actually irresponsible, I think) to not tool-up and do the job properly.

     

    Also, once you've got FusionReactor, you can run it over the rest of your code, and test new code with it when it's in QA or UAT.  It really is very good at turning up sub-optimal code, which when fixed bring good performance gains.  Just because code doesn't crash does it mean it's healthy code, after all.  It's a pretty low benchmark to set that "as long as it doesn't crash, it's fine".

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 28, 2010 5:35 AM   in reply to ilssac

    I too was having the same error.

     

    I am running a long job posting products to Google via cfhttp post.

    After about one our of running the job would crash with a "Java heap space error"

     

    The job was set up to run in a loop collecting records preping them to a xml and then invoking a cfc that post them to Google.

    After posting is complete it then returns to the driver program to collect more records and repeats.

     

    By addingthe line <META HTTP-EQUIV="REFRESH" CONTENT="600">

    to the header of the driver program it would restart with a fresh session allowing the

    GC Garbage Collector of java to release the memory preventing the "Java heap space" error.

     

    Problem solved thanks for the tip from  (ilssac)

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 11, 2012 11:24 AM   in reply to RickBergen

    We have the same issue and it appears as we look around in the web that the garbage collection isn't designed very well. amybe ask to fix it in CF11 http://coldfusion.uservoice.com

     
    |
    Mark as:
  • Currently Being Moderated
    Sep 11, 2012 3:55 PM   in reply to Rob Stevenson

    Wow Rob waking up a March 2010 thread. CF is Java and java garbage collects. There are many ways you can adjust CF (java) memory and GC routines. Best to do some kind of logging or analysis to know what is going on, then armed with knowing what is happening make an adjustment to memory, GC or both and monitor some more.

    Regards, Carl.

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 9:20 AM   in reply to carl type3

    I know this is an old threat, but its the most detailed I've seen and touches on something I am looking for.

     

    I've been experiencing an issue where the mail spool crashes and stops delivering cfmail until the mail service is restarted or CF is restarted.  Upon investigation, in my most recent crash I noticed that at the same time the spool stopped, I had a GC limit issue.  I just doubled my heap size from 512 to 1024.  I have 16gb of ram on the server and task manger's performance tells me I'm using no more than 6.5gb.

     

    How would someone go into more detail to find out what would cause the GC issue?

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 10:32 AM   in reply to ifsteve

    Hi,

     

    Can you share your jvm config with us. What is the MaxPermSize defined and which GC are you using?

     

    Regards,

    Anit Kumar

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 11:26 AM   in reply to Anit Kumar Panda

    I am not very familiar with the info your asking for. 

     

    Here is the 1 piece I found:

    -server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/../ -Dcoldfusion.libPath={application.home}/../lib -Dcoldfusion.fckupload=true

     

    If it helps, windows 2008 r2, default installation, with basically nothing changed.

     

     

    JVM Details
    Java Version1.6.0_17 
    Java VendorSun Microsystems Inc. 
    Java Vendor URLhttp://java.sun.com/
    Java HomeC:\ColdFusion9\runtime\jre 
    Java File EncodingCp1252 
    Java Default Localeen_US 
    File Separator
    Path Separator
    Line SeparatorChr(13)
    User NameABCDEFG
    User HomeC:\ 
    User DirC:\ColdFusion9\runtime\bin 
    Java VM Specification Version1.0 
    Java VM Specification VendorSun Microsystems Inc. 
    Java VM Specification NameJava Virtual Machine Specification 
    Java VM Version14.3-b01 
    Java VM VendorSun Microsystems Inc. 
    Java VM NameJava HotSpot(TM) Server VM 
    Java Specification Version1.6 
    Java Specification VendorSun Microsystems Inc. 
    Java Specification NameJava Platform API Specification 
    Java Class Version50.0 
    CF Server Java Class Path;C:/ColdFusion9/runtime/../lib/updates/hf901-00001.jar;  C:/ColdFusion9/runtime/../lib/activation.jar;  C:/ColdFusion9/runtime/../lib/ant-launcher.jar;  C:/ColdFusion9/runtime/../lib/ant.jar;  C:/ColdFusion9/runtime/../lib/antlr-2.7.6.jar;  C:/ColdFusion9/runtime/../lib/apache-solr-core.jar;  C:/ColdFusion9/runtime/../lib/apache-solr-solrj.jar;  C:/ColdFusion9/runtime/../lib/asn1.jar;  C:/ColdFusion9/runtime/../lib/axis.jar;  C:/ColdFusion9/runtime/../lib/backport-util-concurrent.jar;  C:/ColdFusion9/runtime/../lib/bcel-5.1-jnbridge.jar;  C:/ColdFusion9/runtime/../lib/bcel.jar;  C:/ColdFusion9/runtime/../lib/bcmail-jdk14-139.jar;  C:/ColdFusion9/runtime/../lib/bcprov-jdk14-139.jar;  C:/ColdFusion9/runtime/../lib/cdo.jar;  C:/ColdFusion9/runtime/../lib/cdohost.jar;  C:/ColdFusion9/runtime/../lib/certj.jar;  C:/ColdFusion9/runtime/../lib/cf-acrobat.jar;  C:/ColdFusion9/runtime/../lib/cf-assembler.jar;  C:/ColdFusion9/runtime/../lib/cf-logging.jar;  C:/ColdFusion9/runtime/../lib/cf4was.jar;  C:/ColdFusion9/runtime/../lib/cf4was_ae.jar;  C:/ColdFusion9/runtime/../lib/cfusion-req.jar;  C:/ColdFusion9/runtime/../lib/cfusion.jar;  C:/ColdFusion9/runtime/../lib/clibwrapper_jiio.jar;  C:/ColdFusion9/runtime/../lib/commons-beanutils-1.8.0.jar;  C:/ColdFusion9/runtime/../lib/commons-codec-1.3.jar;  C:/ColdFusion9/runtime/../lib/commons-collections-3.2.1.jar;  C:/ColdFusion9/runtime/../lib/commons-digester-2.0.jar;  C:/ColdFusion9/runtime/../lib/commons-discovery-0.4.jar;  C:/ColdFusion9/runtime/../lib/commons-fileupload-1.2.jar;  C:/ColdFusion9/runtime/../lib/commons-httpclient-3.1.jar;  C:/ColdFusion9/runtime/../lib/commons-lang-2.4.jar;  C:/ColdFusion9/runtime/../lib/commons-logging-1.1.1.jar;  C:/ColdFusion9/runtime/../lib/commons-logging-api-1.1.1.jar;  C:/ColdFusion9/runtime/../lib/commons-net-2.0.jar;  C:/ColdFusion9/runtime/../lib/commons-vfs-1.0.jar;  C:/ColdFusion9/runtime/../lib/crystal.jar;  C:/ColdFusion9/runtime/../lib/derby.jar;  C:/ColdFusion9/runtime/../lib/derbyclient.jar;  C:/ColdFusion9/runtime/../lib/derbynet.jar;  C:/ColdFusion9/runtime/../lib/derbyrun.jar;  C:/ColdFusion9/runtime/../lib/derbytools.jar;  C:/ColdFusion9/runtime/../lib/dom4j-1.6.1.jar;  C:/ColdFusion9/runtime/../lib/ehcache-web.jar;  C:/ColdFusion9/runtime/../lib/ehcache.jar;  C:/ColdFusion9/runtime/../lib/esapi-2.0_rc10.jar;  C:/ColdFusion9/runtime/../lib/FCSj.jar;  C:/ColdFusion9/runtime/../lib/flashgateway.jar;  C:/ColdFusion9/runtime/../lib/flex-messaging-common.jar;  C:/ColdFusion9/runtime/../lib/flex-messaging-core.jar;  C:/ColdFusion9/runtime/../lib/flex-messaging-opt.jar;  C:/ColdFusion9/runtime/../lib/flex-messaging-proxy.jar;  C:/ColdFusion9/runtime/../lib/flex-messaging-remoting.jar;  C:/ColdFusion9/runtime/../lib/flex-rds-server.jar;  C:/ColdFusion9/runtime/../lib/geronimo-stax-api_1.0_spec-1.0.1.jar;  C:/ColdFusion9/runtime/../lib/hibernate3.jar;  C:/ColdFusion9/runtime/../lib/httpclient.jar;  C:/ColdFusion9/runtime/../lib/ib6addonpatch.jar;  C:/ColdFusion9/runtime/../lib/ib6core.jar;  C:/ColdFusion9/runtime/../lib/ib6http.jar;  C:/ColdFusion9/runtime/../lib/ib6swing.jar;  C:/ColdFusion9/runtime/../lib/ib6util.jar;  C:/ColdFusion9/runtime/../lib/im.jar;  C:/ColdFusion9/runtime/../lib/iText.jar;  C:/ColdFusion9/runtime/../lib/iTextAsian.jar;  C:/ColdFusion9/runtime/../lib/izmado.jar;  C:/ColdFusion9/runtime/../lib/jai_codec.jar;  C:/ColdFusion9/runtime/../lib/jai_core.jar;  C:/ColdFusion9/runtime/../lib/jai_imageio.jar;  C:/ColdFusion9/runtime/../lib/jakarta-oro-2.0.6.jar;  C:/ColdFusion9/runtime/../lib/jakarta-slide-webdavlib-2.1.jar;  C:/ColdFusion9/runtime/../lib/java-xmlbuilder-1.jar;  C:/ColdFusion9/runtime/../lib/java2wsdl.jar;  C:/ColdFusion9/runtime/../lib/jax-qname.jar;  C:/ColdFusion9/runtime/../lib/jaxb-api.jar;  C:/ColdFusion9/runtime/../lib/jaxb-impl.jar;  C:/ColdFusion9/runtime/../lib/jaxb-libs.jar;  C:/ColdFusion9/runtime/../lib/jaxb-xjc.jar;  C:/ColdFusion9/runtime/../lib/jaxrpc.jar;  C:/ColdFusion9/runtime/../lib/jdom-1.0.jar;  C:/ColdFusion9/runtime/../lib/jeb.jar;  C:/ColdFusion9/runtime/../lib/jets3t-0.7.3.jar;  C:/ColdFusion9/runtime/../lib/jetty-continuation-7.0.0.v20091005.jar;   C:/ColdFusion9/runtime/../lib/jetty-http-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-io-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-security-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-server-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-servlet-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-servlets-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-util-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jetty-xml-7.0.0.v20091005.jar;  C:/ColdFusion9/runtime/../lib/jintegra.jar;  C:/ColdFusion9/runtime/../lib/jnbcore.jar;  C:/ColdFusion9/runtime/../lib/jpedal.jar;  C:/ColdFusion9/runtime/../lib/js.jar;  C:/ColdFusion9/runtime/../lib/jsch-0.1.41m.jar;  C:/ColdFusion9/runtime/../lib/jsr107cache.jar;  C:/ColdFusion9/runtime/../lib/jutf7-0.9.0.jar;  C:/ColdFusion9/runtime/../lib/ldap.jar;  C:/ColdFusion9/runtime/../lib/ldapbp.jar;  C:/ColdFusion9/runtime/../lib/log4j-1.2.15.jar;  C:/ColdFusion9/runtime/../lib/lucene-analyzers.jar;  C:/ColdFusion9/runtime/../lib/lucene.jar;  C:/ColdFusion9/runtime/../lib/lucenedemo.jar;  C:/ColdFusion9/runtime/../lib/macromedia_drivers.jar;  C:/ColdFusion9/runtime/../lib/mail.jar;  C:/ColdFusion9/runtime/../lib/metadata-extractor-2.4.0-beta-1.jar;  C:/ColdFusion9/runtime/../lib/mlibwrapper_jai.jar;  C:/ColdFusion9/runtime/../lib/msapps.jar;  C:/ColdFusion9/runtime/../lib/mysql-connector-java-commercial-5.1.11- bin.jar;  C:/ColdFusion9/runtime/../lib/namespace.jar;  C:/ColdFusion9/runtime/../lib/nekohtml.jar;  C:/ColdFusion9/runtime/../lib/ooxml-schemas.jar;  C:/ColdFusion9/runtime/../lib/pdfencryption.jar;  C:/ColdFusion9/runtime/../lib/poi-contrib.jar;  C:/ColdFusion9/runtime/../lib/poi-ooxml-schemas.jar;  C:/ColdFusion9/runtime/../lib/poi-ooxml.jar;  C:/ColdFusion9/runtime/../lib/poi-scratchpad.jar;  C:/ColdFusion9/runtime/../lib/poi.jar;  C:/ColdFusion9/runtime/../lib/portlet_20.jar;  C:/ColdFusion9/runtime/../lib/postgresql-8.3-604.jdbc3.jar;  C:/ColdFusion9/runtime/../lib/relaxngDatatype.jar;  C:/ColdFusion9/runtime/../lib/ri_generic.jar;  C:/ColdFusion9/runtime/../lib/rome-cf.jar;  C:/ColdFusion9/runtime/../lib/saaj.jar;  C:/ColdFusion9/runtime/../lib/serializer.jar;  C:/ColdFusion9/runtime/../lib/slf4j-api-1.5.6.jar;  C:/ColdFusion9/runtime/../lib/slf4j-log4j12-1.5.6.jar;  C:/ColdFusion9/runtime/../lib/smack.jar;  C:/ColdFusion9/runtime/../lib/smpp.jar;  C:/ColdFusion9/runtime/../lib/STComm.jar;  C:/ColdFusion9/runtime/../lib/tika-core-0.6.jar;  C:/ColdFusion9/runtime/../lib/tika-parsers-0.6.jar;  C:/ColdFusion9/runtime/../lib/tools.jar;  C:/ColdFusion9/runtime/../lib/tt-bytecode.jar;  C:/ColdFusion9/runtime/../lib/vadmin.jar;  C:/ColdFusion9/runtime/../lib/verity.jar;  C:/ColdFusion9/runtime/../lib/vparametric.jar;  C:/ColdFusion9/runtime/../lib/vsearch.jar;  C:/ColdFusion9/runtime/../lib/wc50.jar;  C:/ColdFusion9/runtime/../lib/webchartsJava2D.jar;  C:/ColdFusion9/runtime/../lib/wsdl2java.jar;  C:/ColdFusion9/runtime/../lib/wsdl4j-1.5.1.jar;  C:/ColdFusion9/runtime/../lib/wsrp4j-commons-0.5-SNAPSHOT.jar;  C:/ColdFusion9/runtime/../lib/wsrp4j-producer.jar;  C:/ColdFusion9/runtime/../lib/xalan.jar;  C:/ColdFusion9/runtime/../lib/xercesImpl.jar;  C:/ColdFusion9/runtime/../lib/xml-apis.jar;  C:/ColdFusion9/runtime/../lib/xmlbeans-2.3.0.jar;  C:/ColdFusion9/runtime/../lib/xmpcore.jar;  C:/ColdFusion9/runtime/../lib/xsdlib.jar;  C:/ColdFusion9/runtime/../lib/;  C:/ColdFusion9/runtime/../gateway/lib/examples.jar;  C:/ColdFusion9/runtime/../gateway/lib/;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/flex/jars/cfgatewayadapter. jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/flex/jars/concurrent.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/flex/jars/;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/batik-awt-util. jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/batik-css.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/batik-ext.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/batik-transcode r.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/batik-util.jar;   C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/commons-discove ry.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/commons-logging .jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/concurrent.jar;   C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/flex.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/jakarta-oro-2.0 .7.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/jcert.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/jnet.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/jsse.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/oscache.jar;  C:/ColdFusion9/runtime/../wwwroot/WEB-INF/cfform/jars/; 
    Java Class PathC:\ColdFusion9\runtime\servers\lib;
    C:\ColdFusion9\runtime\servers\lib\jrun-patch.jar;
    C:\ColdFusion9\runtime\..\lib\macromedia_drivers.jar;
    C:\ColdFusion9\runtime\lib\cfmx_mbean.jar;
    C:\ColdFusion9\runtime\..\lib\oosdk\classes;
    C:\ColdFusion9\runtime\..\lib\oosdk\lib;
    C:\ColdFusion9\runtime\..\lib\oosdk\lib\juh.jar;
    C:\ColdFusion9\runtime\..\lib\oosdk\lib\jurt.jar;
    C:\ColdFusion9\runtime\..\lib\oosdk\lib\ridl.jar;
    C:\ColdFusion9\runtime\..\lib\oosdk\lib\unoil.jar;
    C:\ColdFusion9\runtime\lib;
    C:\ColdFusion9\runtime\lib\cfmx_mbean.jar;
    C:\ColdFusion9\runtime\lib\instutil.jar;
    C:\ColdFusion9\runtime\lib\java2wsdl.jar;
    C:\ColdFusion9\runtime\lib\jrun-ant-tasks.jar;
    C:\ColdFusion9\runtime\lib\jrun-xdoclet.jar;
    C:\ColdFusion9\runtime\lib\jrun.jar;
    C:\ColdFusion9\runtime\lib\jspc.jar;
    C:\ColdFusion9\runtime\lib\migrate.jar;
    C:\ColdFusion9\runtime\lib\oem-xdoclet.jar;
    C:\ColdFusion9\runtime\lib\sniffer.jar;
    C:\ColdFusion9\runtime\lib\webservices.jar;
    C:\ColdFusion9\runtime\lib\wsconfig.jar;
    C:\ColdFusion9\runtime\lib\wsdl2java.jar;
    C:\ColdFusion9\runtime\lib\xmlscript.jar;
    C:\ColdFusion9\runtime\lib\jrun.jar 
    Java Ext DirsC:\ColdFusion9\runtime\jre\lib\ext;C:\Windows\Sun\Java\lib\ext 
     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 12:07 PM   in reply to ifsteve

    Hi,

     

    Thank you for sharing the info. You can try changing the -XX:MaxPermSize=256m. Save the file and restart the services. A more detailed explanation regarding managing your system memory is available at http://docs.oracle.com/cd/E13222_01/wls/docs81/perform/JVMTuning.html. You can refer to http://www.adobe.com/devnet/coldfusion/articles/coldfusion_performance .html  for performance tunning as well.

     

    Regards,

    Anit Kumar

     
    |
    Mark as:
  • Currently Being Moderated
    Apr 2, 2013 12:31 PM   in reply to Anit Kumar Panda

    Thanks, I will fine tune that on next reboot.

     

    As it relates to cfmail spool crashing:

     

    This is an issue that I have personally been experiencing since CF5 and all the versions since.  Each of the following links document people with the same issue too.  Is there a bug in this "mailSpoolService" that needs to be fixed?

     

    http://www.cutterscrossing.com/index.cfm/2006/12/10/ColdFusion-Mail-Sp ool-Lock (2006)

    http://house-of-fusion.10909.n7.nabble.com/cfmail-stuck-in-spool-td112 530.html (2007)

    http://stackoverflow.com/questions/94932/coldfusion-mail-queue-stops-p rocessing (2009)

     

    Its very frustrating when customer(s) call you to tell you that their emails aren't going out and you ultimately have to restart coldfusion, or attempt to restart the service.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points