[
https://issues.apache.org/jira/browse/IVY-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184643#comment-14184643
]
Charles Duffy edited comment on IVY-1388 at 10/26/14 8:05 PM:
--------------------------------------------------------------
Any locking support detection is done by the JVM -- if you were on a filesystem
where neither fcntl-based locking nor flock were supported, I wouldn't be
surprised to see an exception result when trying to use NIO locking, but I'd
have to read the library documentation to know whether that behavior is defined.
A patch to enable NIO whenever the platform provides it strikes me as a good
idea, but difficult to implement in practice given the need to retain
compatibility across defaults for mixed-release environments (upgrading only a
subset of nodes accessing the same backend). Presently, then, enabling NIO
locking is runtime configuration; see
http://ant.apache.org/ivy/history/latest-milestone/settings/lock-strategies.html.
was (Author: cduffy):
Any locking support detection is done by the JVM -- if you were on a filesystem
where neither fcntl-based locking nor flock were supported, I wouldn't be
surprised to see an exception result when trying to use NIO locking, but I'd
have to read the library documentation to know whether that behavior is defined.
A patch to enable NIO whenever the platform provides it strikes me as a good
idea, but difficult to implement in practice given the need to retain
compatibility across defaults for mixed-release environments (upgrading
different only a subset of nodes accessing the same backend). Presently, then,
enabling NIO locking is runtime configuration; see
http://ant.apache.org/ivy/history/latest-milestone/settings/lock-strategies.html.
> *.lck files created by "artifact-lock" lock strategy are not cleaned up if
> ivy quits abruptly
> ---------------------------------------------------------------------------------------------
>
> Key: IVY-1388
> URL: https://issues.apache.org/jira/browse/IVY-1388
> Project: Ivy
> Issue Type: Bug
> Affects Versions: 2.2.0, 2.3.0-RC1, trunk
> Reporter: Wei Chen
> Assignee: Nicolas Lalevée
> Fix For: 2.3.0
>
> Attachments: FileBasedLockStrategy.java.patch, patch1.patch
>
> Original Estimate: 0.5m
> Remaining Estimate: 0.5m
>
> We have a few build processes running in parallel, all of which share the
> same ivy cache. In order not to run into any parallel downloading problems,
> we enabled artifact-lock lock strategy. An annoying problem with the
> artifact-lock strategy is that the *.lck files which are created as a lock
> are not cleaned up if the build exits abruptly. For example, while ivy is
> downloading a big jar, if you Ctrl-C to quit that build process. Those lock
> files will remain in the metadatas folder. The same happens too if ivy
> encounters some error and fails the build.
> Those uncleaned lock files will cause problem when you start the build again.
> The build process will hang while ivy waiting those "locks" to be released,
> which will never happen automatically. So eventually the build will fail with
> an ivy error "impossible to acquire lock for xxxyyyzzzz". What makes it worse
> is that ivy doesn't fail-fast on the default 2 miuntes lock timeout, it seems
> trying it a few times. In worst scenarios, we have seen the build hangs for
> 12 minutes and then timeout'd and failed.
> We believe this can be fixed by setting deleteOnExit() for the
> FileBasedLockStrategy.java class. We have implemented the fix and it works
> well.
> Patch is provided, could anyone quickly apply this one line change?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
