Dave Ferguson's Blog

TweetBacks

Comments

• #1 by Brian Kotek on 1/27/08 - 8:05 PM

  

  Actually I'd say the limit depends on how much space you've allocated to the JVM. What you have to remember is that when you build up strings via concatenation (as you are doing here on each loop iteration), CF (Java, actually) creates an entirely new String instance. So it is very easy to blow the top off the JVM memory if you are concatenating huge strings like this. Instead of doing it this way, use a Java StringBuffer, which appends text to a single StringBuffer instance rather than creating new String instances after each concatenation. If you try this using a StringBuffer you'll be able to build up a much larger string.

• #2 by Marc Esher on 1/28/08 - 3:09 AM

  

  And if you're sure your request isn't being acted on by outside threads (via cfthread, or if your data are in a shared scope), you can use StringBuilder, which is supposed to be even faster than StringBuffer. Only works on CF8 though. Or CF7 if you can get it running under java 1.5.
  
  I remember reading something on Luis Majano's site wrt to cfsavecontent use in high-use apps. If I remember correctly, he was saying that one of the problems he had with fusebox's cfsavecontent model for saving the view content was that he'd get instability and out-of-memory errors, and I believe he tracked it down to cfsavecontent. Interesting.
  
  Anyway, good stuff.

• #3 by Adam Cameron on 1/28/08 - 6:04 AM

  

  Approaching the issue slightly differently... why are you generating one huge string, then writing it to file instead of writing it to file straight away?
  
  Get rid of your <CFSAVECONTENT> and put a <CFFILE ACTION="APPEND"> in your loop.
  
  --
  Adam

• #4 by Dave Ferguson on 1/28/08 - 7:16 AM

  

  I think we are focusing on the wrong thing here. I don't think it is a matter of what I was doing. I was merely trying to point out the apparent memory cap in CFCONTENT.
  
  
  --Dave

• #5 by Dan G. Switzer, II on 1/28/08 - 8:20 AM

  

  @Dave:
  
  As Brian mentioned, I'm sure it's not a limitation of the tag but of the memory allocated to the JVM. This means your mileage will vary.
  
  Something else to keep in mind is that the memory usage of building a string is no where near the physical size of the memory. If you monitor your heap, you'll see that the memory required to generate a 92MB file is significantly higher than 92MBs of RAM. So while the final size of the file written to disk may only be 92MBs, the actually amount of RAM that string consume in the JVM will be higher.

• #6 by Adam Cameron on 1/29/08 - 2:59 AM

  

  It *could* be a limit of CFSAVECONTENT, but I rather more think it would be a limit *full stop* ("*period*", whatever you prefer).
  
  All you've demonstrated so far -as far as I can tell - is memory runs out if one uses more of it than is allcoated (the question perhaps is "allocated to what?")
  
  What happens if you swap out the CFSAVECONTENT for simply concatenating the string together:
  
  <cfset theRes = theRes & "#i#: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec libero. Suspendisse bibendum. Cras id urna. Morbi tincidunt, orci ac convallis aliquam, lectus turpis varius lorem, eu posuere nunc justo tempus leo. Donec mattis, purus nec placerat bibendum, dui pede condimentum odio, ac blandit ante orci ut diam.">
  
  My expectation would be you'd get the same error.
  
  But if not, it does actually add some evidence to what you're suggesting. I don't see anything pointing specifically to CFSAVECONTENT here yet.
  
  I'd also try varying your heap size in your JVM: you should see that "max out" figure change along with it.
  
  --
  Adam