Description Daniel Luebke 2010-05-19 04:49:05 EDT

Build Identifier: M20090917-0800

If you run a MWE workflow multiple times from a Java program and that workflow uses a XSDMetaModel component, the XSD files will be loaded multiple times and stay in memory. If deployed on the server-side, this will lead to serious problems.
We diagnosed this problem with the SAP Memory Analyzer tool after we detected a memory leak in our generator.

In our project, we introduced a workaround by subclassing the XSDMetaModel and caching the dynamic ecore metamodel based on the XSD files. This is only a hack. A better solution IMO would be see whether the namespace is already registered. However, it works for our case. The class looks like this:

public class XsdCachedMetaModel extends XSDMetaModel {

	private static final Map<List<String>, XSDMetaModel> cache = new HashMap<List<String>, XSDMetaModel>(); 

	private static synchronized XSDMetaModel getMetaModel(List<String> uris) {
		if(!cache.containsKey(uris)) {
			XSDMetaModel xsdMM = new XSDMetaModel();
			
			for(String uri : uris) {
				xsdMM.addSchemaFile(uri);
			}
			
			cache.put(uris, xsdMM);
		}
		
		return cache.get(uris);
	}
	
	private List<String> uris = new ArrayList<String>();
	
	public void addSchemaFile(String uri) {
		uris.add(uri);
	}

	@Override
	public EPackage[] allPackages() {
		return getMetaModel().allPackages();
	}

	@Override
	public EFeatureMapEntryTypeImpl getEFeatureMapEntryType() {
		return getMetaModel().getEFeatureMapEntryType();
	}

	@Override
	public XMLFeatureMapTypeImpl getEFeatureMapType(EClass aClass) {
		return getMetaModel().getEFeatureMapType(aClass);
	}

	@Override
	public EFeatureType getEFeatureType() {
		return getMetaModel().getEFeatureType();
	}

	@Override
	public EMapEntryType getEMapEntryType(EClassifier innerType) {
		return getMetaModel().getEMapEntryType(innerType);
	}

	@Override
	public EMapType getEMapType(EClassifier innerType) {
		return getMetaModel().getEMapType(innerType);
	}

	@Override
	public Set<Type> getKnownTypes() {
		return getMetaModel().getKnownTypes();
	}

	private XSDMetaModel getMetaModel() {
		return getMetaModel(uris);
	}

	@Override
	public Set<String> getNamespaces() {
		return getMetaModel().getNamespaces();
	}

	@Override
	public QNameType getQNameType() {
		return getMetaModel().getQNameType();
	}

	@Override
	public Type getType(Object obj) {
		return getMetaModel().getType(obj);
	}

	@Override
	public Type getTypeForEClassifier(EClassifier element) {
		return getMetaModel().getTypeForEClassifier(element);
	}

	@Override
	public Type getTypeForETypedElement(ETypedElement typedElement) {
		return getMetaModel().getTypeForETypedElement(typedElement);
	}

	@Override
	public Type getTypeForName(String typeName) {
		return getMetaModel().getTypeForName(typeName);
	}

	@Override
	public TypeSystem getTypeSystem() {
		return getMetaModel().getTypeSystem();
	}
	
	@Override
	public XSDManager getXsdManager() {
		return getMetaModel().getXsdManager();
	}
	
	@Override
	public boolean isRegisterPackagesGlobally() {
		return getMetaModel().isRegisterPackagesGlobally();
	}

	@Override
	public boolean isSaveEPackages() {
		return getMetaModel().isSaveEPackages();
	}

	@Override
	public void setRegisterPackagesGlobally(boolean registerPackagesGlobally) {
		getMetaModel().setRegisterPackagesGlobally(registerPackagesGlobally);
	}

	@Override
	public void setSavePackagesPath(String path) {
		getMetaModel().setSavePackagesPath(path);
	}

	@Override
	public void setTypeSystem(TypeSystem typeSystem) {
		getMetaModel().setTypeSystem(typeSystem);
	}

	@Override
	public String toString() {
		return getMetaModel().toString();
	}

}


Reproducible: Always

Steps to Reproduce:
1. Create workflow using XSDMetaModel
2. Run this workflow in a loop from a WorkflowRunner and print memory consumption
3. See memory consumption increase and finally the program exit with an OutOfMemoryException.