[tulipgraphics]

We’re a team of three developers, two of use recently upgraded to version 7 of MyEclipse, and the third developer is still running version 5.5.

The two of us running on version 7 are getting this error (as a popup) every 20-30 minutes. The lucky one on version 5.5 is sharing the exact same application source code and is having no problems.

the error, every half hour or so:
“Could not write metadata for /GP” (“GP” being the name of one of the web app projects in our workspace)

Here’s our environment: OS X (10.5.6), MyEclipse 7.0, Subclipse Plug-in (1.5.2 client adapter). Let me know if you need more details on anything specific.

The following gets logged in the workspace home directory, in a file called .log in a directory called .metadata:

!ENTRY org.eclipse.core.resources 4 568 2009-01-30 19:52:25.438
!MESSAGE Could not write metadata for ‘/GP’.
!STACK 0
java.io.UTFDataFormatException: encoded string too long: 157782 bytes
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:347)
at java.io.DataOutputStream.writeUTF(DataOutputStream.java:306)
at org.eclipse.core.internal.resources.MarkerWriter.write(MarkerWriter.java:181)
at org.eclipse.core.internal.resources.MarkerWriter.write(MarkerWriter.java:210)
at org.eclipse.core.internal.resources.MarkerWriter.snap(MarkerWriter.java:156)
at org.eclipse.core.internal.resources.MarkerManager.snap(MarkerManager.java:573)
at org.eclipse.core.internal.resources.SaveManager$4.visitElement(SaveManager.java:1516)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
at org.eclipse.core.internal.resources.SaveManager.visitAndSnap(SaveManager.java:1540)
at org.eclipse.core.internal.resources.SaveManager.visitAndSnap(SaveManager.java:1565)
at org.eclipse.core.internal.resources.SaveManager.save(SaveManager.java:1021)
at org.eclipse.core.internal.resources.DelayedSnapshotJob.run(DelayedSnapshotJob.java:44)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

[Riyad Kalla]

bnash74,

Very strange… looks like something at the platform level is barfing. Are you guys on volumes that have case sensitivity turned on? Are you by chance trying to share a workspace dir on a network share or something like that or is everyone working locally in their own dirs?

Do you have auto-synchronization turned on for the Team/SVN operations? It’s possible that subclipse could be running head-first into a read lock (even though that would more likely be a problem on Windows).

Any thoughts?

[tulipgraphics]

Regarding case-sensitivity, no it’s not enabled. I verified at the command line by creating modifying and deleting both files and directories, and case didn’t matter in any scenario.

We’re not sharing the workspace, we each have our own locally attached drive for the workspace.

Regarding auto-synchronization, no we’re not running this, but it sounds really good, didn’t know it was possible. Perhaps when we’re out of the woods on this issue I’ll brings that up again.

Thanks for your quick reply,

-Nash

[tulipgraphics]

Looking back at the stack trace, this line stands out to me:
java.io.UTFDataFormatException: encoded string too long: 157782 bytes

I think a limit of some sort is being reached. For instance, the other 3 webapps that we’re running don’t get this metadata error. I’m starting to wonder if it’s something about the webapp data itself. 157782 bytes is a pretty long string..any clue as to how to determine what string it’s referring to?

-Nash

[Riyad Kalla]

Agreed, that’s a sizable string… can you pop open the .mymetadata file, .project file and .classpath file and see if any of those have a huge bunch of garbage in them?

You’ll have to switch to the navigator view to see them.

[tulipgraphics]

Hi Riyad,

Took a look at each of the dot files you suggested. Nothing looked like garbage, everything appeared relevant…and the largest of the files was only 3,019 bytes. I’m looking around at other project files (that I didn’t create) for anything abnormal.

[Riyad Kalla]

So I dug around the Eclipse BZ system and found these:
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=could+not+write+metadata&classification=Eclipse&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

the most likely culprit looks like an “out of disk space” issue, but they definitely look similar

[tulipgraphics]

Looks like someone else just posted a bug this morning (2-6-09) almost exactly the same as ours. They’re getting the exact same error, and they also have a very large project, which i believe is probably related to the issue. I will keep my eye on the bugzilla results. Do you know how long bugs typically sit around before they’re resolved?

[Riyad Kalla]

Totally depends on everything from resources, to desire to politics. No way to tell.

If someone submits a patch for it though, that ups the chances of it getting fixed by about 10x from what I’ve seen.

[tulipgraphics]

I think I’ve found a fix to the problem…
According to what I read here: http://stackoverflow.com/questions/381273/eclipse-problems-saving-workspace
this is a JVM problem where the DataOutputStream class used to do some writing has a hard-coded limit of 65535 bytes
(see DataOutputStream’s source code here: http://www.docjar.com/html/api/java/io/DataOutputStream.java.html)
The solution for me was to update to a newer JRE (1.6.09 did the trick) which appears NOT to have this same limitation.
I’ve been a few hours, and so far no problems/errors. I’ll report back here if I do find any other issues around this, or if the error comes back.

[Riyad Kalla]

Excellent find — very strange about this, I’ll let the ME team to know.

[Author]

Posts