Flaky QuickDebugSourceInstallingCompilationParticipantTest #3354
Conversation
|
@cdietrich it still fails.. I'm not planning to work on that any longer.. I'd go back to my original alternatives mentioned in the issue |
|
hmmm running on battery makes it fail for me again .... :( |
|
and the more logging i add the less i can reprodcue |
|
could track it down to org.eclipse.xtext.generator.trace.LineMappingProvider.getLineMapping(AbstractTraceRegion) but wont that indicate trace file reading is broken (or even creating) |
|
of course now i can no longer reproduce at all .... |
com.google.common.io.ByteStreams.toByteArray(InputStream) says "Java 9+ users: use in#readAllBytes() instead."
LorenzoBettini
force-pushed
the
lb_3350
branch
from
95f377b to
9e08f2e
Compare
| @@ -69,7 +69,7 @@ public AbsoluteURI getPath() { | |||
|
|
|||
| @Override | |||
| public long getTimestamp() { | |||
| return file.getLocalTimeStamp(); | |||
| return file.getModificationStamp(); | |||
There was a problem hiding this comment.
The underlying assumption seems to be that the code executes too fast.
Would it fail if we wait for one second in the test?
There was a problem hiding this comment.
@szarnekow I haven't tried, but the Javadoc of getLocalTimeStamp, https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fresources%2FIResource.html&anchor=getLocalTimeStamp(), also says
Note that due to varying file system timing granularities, this value is not guaranteed to change every time the file is modified. For a more reliable indication of whether the file has changed, use getModificationStamp().
It sounds like the method is quite unreliable...
There was a problem hiding this comment.
i guess a sleep of 1s would also help. but am not sure if other tests might be affected too
There was a problem hiding this comment.
Hmm I'm not sure.
@szarnekow what do you think is wrong with getModificationStamp?
There was a problem hiding this comment.
It's not a timestamp and thus should not be used to implement getTimestamp
It might be fine to rename getTimestamp to getModification stamp
There was a problem hiding this comment.
It's not a timestamp and thus should not be used to implement
getTimestampIt might be fine to rename getTimestamp to getModification stamp
@szarnekow OK, I'll do that later.
That would be API breakage but I guess for that wouldn't be a problem because it's an internal type, would it?
There was a problem hiding this comment.
@szarnekow renamed it (7cc6b0d)
org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/generator/trace/TraceForStorageProvider.java
Outdated
Show resolved
Hide resolved
...clipse.xtext/src/org/eclipse/xtext/generator/trace/internal/AbstractTraceForURIProvider.java
Outdated
Show resolved
Hide resolved
...clipse.xtext/src/org/eclipse/xtext/generator/trace/internal/AbstractTraceForURIProvider.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Sebastian Zarnekow <Sebastian.Zarnekow@gmail.com>
Closes #3350