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]
>
>

Reply via email to