Community
Participate
Working Groups
Some random errors happen when launching many times "Discoverer Java and Kdm inventory model from Java project...". There are many types or error messages, seem to be related to jobs synchronization for creating/saving/loading the xmi fragments files (some xmi files are not complete) e.g. for "org.eclipse.core.resources.compatibility" : some errors are - Could not write file: D:\eclipse 3.6Z.m-dev\runtime-dvt-workspace\org.eclipse.core.resources.compatibility\xmiFragmentsJavaApp\org.eclipse.core.internal.indexing_javaapp.xmi - Failed to load an external element: Java2File platform:/resource/org.eclipse.core.resources.compatibility//xmiFragmentsJavaApp//org.eclipse.core.internal.indexing_javaapp.xmi#/31 The xmi file corrupted is not always the same.
Created attachment 177090 [details] stackTrace1
Created attachment 177091 [details] stackTrace2
The bug occurs on the "Java Discoverer" too. It is a regression on trunk (0.9). The bug deos not occur in 0.8 (Helios) branch. It seems the regression is outside of the MoDisco components. A fix for Java Discoverer is to remove the options of serialization : options.put(XMLResource.OPTION_FLUSH_THRESHOLD, DefaultDiscoverer.FLUSH_LIMIT); options.put(XMLResource.OPTION_USE_FILE_BUFFER, true); However the same fix does not resolve for "Java and kdm inventory Discoverer" I temporary commit the fix for Java discoverer (DefaultDiscoverer class) until it can be processed (fix not reliable : options are necessary for memory usage tuning).
Gregoire, i think i have identified the problem which looks like an issue with the couple (EMF, CVS) features installed. I attach the source for one project : testXMISerialize. Could you make the test from of one of your eclipse install : - import the project in your workspace - launch a second eclipse instance form this one - checkout a project from a CVS repository (whatever it is) - on the project, right click -> "new submenu" -> "new action" -> if a TestSerializationEMF.xmi appears and a window "serialization ok", then delete the file and try again -> you should obtain many times in error log : "Could not write file: D:\XXX\TestSerializationEMF.xmi." If you disconnect the project from CVS, everything becomes ok. Please confirm that you have the same behavior so as i fill a new bug in EMF project, blocking this one.
Created attachment 178757 [details] testXMISerialize.zip
Hello Fabien, I followed your procedure and I had the same behavior. Here is a set of observations: - I’ve removed the CVS files when I disconnected the project form the CVS. - To see the menu, we have to use the package explorer. Regards, Grégoire
I commited some workaround into Head SVN (catching the exception and saving again without file buffer).
Bug 325245 has been closed without fix. Debugging a little more : - when FileNotFoundException is thrown from java.io.FileOutputStream, the file physically exists on local disk. The error message attached for FileNotFoundException says that the real problem is that another process is already using the file (as if an outputstream has been opened but not closed) - feature for XMLResource.OPTION_FLUSH_THRESHOLD/OPTION_USE_FILE_BUFFER seems to always do the outputStream.close() required in finally clauses. - prior to this exception, some other exceptions are thrown from org.eclipse.team.internal.ccvs.core.util.EclipseSynchronizer . Some about missing CVS\Entries.Log. Dont know if they are "normal" exceptions during CVS processing (they are catched anyway) and if there can be a side-effect on other files. - changing jre does not change the result. But the OS ... ? A relation between CVS and our bug obviously exists but is hard to debug. -> I close the bug keeping the workaround on Java/Java.composition discoverers. This workaround may be generalized in discoverymanager since we are going to refactor it.
