[
https://issues.apache.org/jira/browse/TAP5-2821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071061#comment-18071061
]
Hudson commented on TAP5-2821:
------------------------------
FAILURE: Integrated in Jenkins build Tapestry ยป
tapestry-javax-java-11-freestyle #99 (See
[https://ci-builds.apache.org/job/Tapestry/job/tapestry-javax-java-11-freestyle/99/])
TAP5-2821: ReloadSpec write bytecode first, touch after (benw: rev
0d18da2e0abfea9db636a32a8f2df07c210d950a)
* (edit) tapestry-ioc/src/test/groovy/ioc/specs/ReloadSpec.groovy
> ReloadSpec fails occasionally on CI
> -----------------------------------
>
> Key: TAP5-2821
> URL: https://issues.apache.org/jira/browse/TAP5-2821
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.10.0
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Major
>
> The ReloadSpec.groovy Spock tests fail the {{reload a proxy object}} test
> occasionally on CI.
> Two issues were found as possible culprits in the Groovy test:
> * touch() is called before createImplementationClass. The touch() ensures the
> lastModified is after the current one. However, writing the bytes after the
> touch might reset the time, and now it depends on the FS granularity.
> * touch() uses Thread.sleep(...) with XOR (^) resulting in non-linear
> increatings times
> Changing the order of operations (first writing the bytes, then touching)
> seems to fix the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
