Community
Participate
Working Groups
We're observing a concurrency issue in our client code and we're not sure if its exposing an issue in ModelManagerImpl. We have some tests that open a structured editor and perform some edits, then close the editor and check that the model references are returned to 0. Occasionally the tests are off by 1, and we have been observing that the FileBufferModelManager.connect method is logging an exception because the document it is passed is null. The model reference count is being incremented before FileBufferModelManager does its work and before ModelManagerImpl returns the shared model. Should the _incrCount and _decrCount methods only be increasing/decreasing the reference count based on whether the FiledBufferModelManager.connect result is successful? And should the model getters return null if the FileBufferModelManager can't connect?
I mean to include a stack trace that shows the relevant methods in ModelManagerImpl !ENTRY org.eclipse.wst.sse.core 4 4 2011-03-05 23:11:16.686 !MESSAGE can not connect() without a document java.lang.IllegalArgumentException: can not connect() without a document at org.eclipse.wst.sse.core.internal.FileBufferModelManager.connect(FileBufferModelManager.java:423) at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl._incrCount(ModelManagerImpl.java:665) at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.getExistingModelForRead(ModelManagerImpl.java:1302) at org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.getExistingModelForRead(ModelManagerImpl.java:1269) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AspectDefinitionBuilderHelper$DefaultDocumentFactory.createDocument(AspectDefinitionBuilderHelper.java:116) at org.springframework.ide.eclipse.security.core.aop.model.builder.SecurityXmlAspectDefinitionBuilder.buildAspectDefinitions(SecurityXmlAspectDefinitionBuilder.java:66) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AspectDefinitionBuilderHelper.buildAspectDefinitions(AspectDefinitionBuilderHelper.java:90) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAspectDefinitions(AopReferenceModelBuilderJob.java:399) build 05-Mar-2011 23:11:16 at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesForFile(AopReferenceModelBuilderJob.java:328) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopModel(AopReferenceModelBuilderJob.java:442) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.run(AopReferenceModelBuilderJob.java:159) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Hi, Leo. Thanks for opening this. Ultimately, we'd want to fix the concurrency issue and then hopefully the reference counts will fall back into line. Is it possible to attach a reproducible scenario that we could get to the bottom of? Returning null for the model and cleaning up the sharedObject might be safer in the end than returning a model with no document.
Hello Nick. I was never able to come up with a reproducible case. Upon further investigation I've discovered that the stack trace I posted occurs at random on a subset of our tests, but does not occur during our model count test as I first suggested. I've been able to verify that the model reference count does eventually return to 0, despite not always reporting so the first time. I'm still not sure what the conditions are that would be causing the stack trace above to occur, but it could just be a poorly formed test case on our part. I'd be okay with closing this as invalid if you don't think there needs to be any modifications to ModelManagerImpl
Created attachment 205070 [details] patch I believe this may be a race condition when invoking the _incrCount from the getExistingModelForEdit[Read](Object) as it was not properly guarded by the SYNC lock.
Created attachment 205448 [details] updated patch
Code released to HEAD.
