Bug 323247

Comment 1 Fabien Giquel 2010-08-20 09:19:51 EDT

Created attachment 177090 [details]
stackTrace1

Comment 2 Fabien Giquel 2010-08-20 09:20:09 EDT

Created attachment 177091 [details]
stackTrace2

Comment 3 Fabien Giquel 2010-08-20 13:33:36 EDT

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).

Comment 4 Fabien Giquel 2010-09-13 12:13:51 EDT

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.

Comment 5 Fabien Giquel 2010-09-13 12:14:14 EDT

Created attachment 178757 [details]
testXMISerialize.zip

Comment 6 Gregoire Dupe 2010-09-14 05:30:33 EDT

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

Comment 7 Fabien Giquel 2010-09-15 09:02:29 EDT

I commited some workaround into Head SVN (catching the exception and saving again without file buffer).

Comment 8 Fabien Giquel 2010-10-06 08:39:12 EDT

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.