Hi Kelvin, Thanks for researching this for us. We'll go ahead and try your breakpoint suggestion and let you know our results.
- Ron ----- Original Message ---- From: kelvin goodson <[EMAIL PROTECTED]> To: tuscany-user@ws.apache.org Sent: Friday, January 11, 2008 12:02:06 PM Subject: Re: Tuscany SDO Memory Leaks in Production Server Environment Ron, I talked to Ed Merks about this, and here's a summary of what he said. He was referencing the EMF 2.4 code, but aside from the generics he thought it was the same as 2.2.3. The key diagnostic would be to see whether calls to getPrinter() and releasePrinter(XMLString) are made in pairs. He suspects that something must be creating printers directly and releasing them, thereby never reusing printers that have been released. The one call to getPrinter seems to be made in XMLSaveImpl: protected void init(XMLResource resource, Map<?, ?> options) and the corresponding releae is made in endSave(List<? extends EObject> contents) throws IOException Both calls are guarded by the useCache guard. So to track it Ed suggested setting a breakpoint in the getPrinter and setPrinter methods. You should never get a release call that didn't give back what was given by a getPrinter call. So one might keep a list of all the things that were given away and when a release happens, check that it's really one that was given away. If not, that code path is a bad one. If this doesn't bear fruit I guess we're going to need a test case that replicates the problem and post it to the EMF list. He says hell be happy to take a look. Regards, Kelvin. On 10/01/2008, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > Greetings, > > We are using Tuscany SDO 1.0 in a production server environment. During > application execution, we see the XMLStrings contained in the EMF > org.eclipse.emf.ecore.xmi.impl.ConfigurationCache.printers[] array growing > without bound until eventually we are forced to restart the application. > There exists a ConfigurationCache.release() method which appears designed > to release this cache. However, we never see this method being invoked > during the life-cycle of our application. Any suggestions for resolving this > problem? Your prompt assistance with this matter is appreciated. > > - Ron > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]