Ron Blaschke wrote: > I've had another look at Forrest's memory issue, this time more > deeply. I still only understand parts of it, and hope someone can > help fill in the missing pieces. > > The problem seems to originate at the LinkRewriteTransformer. Through > one way or the other, a single XMLFileModule is used. This > XMLFileModule seems to be used to access XML content. XMLFileModule > also keeps the documents for further reference, in my opinion for > caching. That's where most of the memory goes during a "forrest > site." > > I've hacked Cocoon's XMLFileModule#getDocumentHelper(Configuration) to > return a new DocumentHelper every time. > > // Disable caching - for testing only > //this.documents.put(src, new DocumentHelper(reload, cache, src, this)); > return new DocumentHelper(reload, cache, src, this); > > After compiling Coccon and replacing cocoon-2.2.0-dev-r230820.jar, I > changed forrest.properties in site-author to "forrest.maxmemory=32m," > and ran "forrest site," with sucess. I also compared two memory > snapshots taken during the run, and they look good. > > Now, my question is: How do you guys usually proceed if you have > issues like this with Cocoon?
Thanks so much for doing this Ron. The best thing would be to create an issue at Cocoon's issue tracker [1]. Make the issue title be very descriptive and start with the term [PATCH]. Describe what you think the problem is and append your patch for the workaround. Someone who understands the XMLFileModule will hopefully either fix it based on your experiments or will add comments to further describe the issue. Using your workaround, do you still see the massive slowdown with Forrest building "site-author" that we are seeing after our recent Cocoon upgrade [2]? [1] http://cocoon.apache.org/2.1/ and choose "Status=>Patch queue" then at Bugzilla choose "new" and follow the prompts. Need to create an account. [2] http://marc.theaimsgroup.com/?t=112357127600001 "Reducing Forrest build time" -David
