[
https://issues.apache.org/jira/browse/IVY-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184658#comment-14184658
]
Charles Duffy commented on IVY-1388:
------------------------------------
Not by any means arguing that the current behavior with the default locking
strategy (which, for aforementioned backwards compatibility reasons, needs to
_remain_ default) is anything other than a bug. (As an aside -- In NIO mode,
it's best practice to leave lockfiles behind unconditionally, as not doing so
greatly increases the surface for race conditions).
Feel free to CC me on any such discussion you start. I'm in the middle of a
release in the day job right now, but if nobody else gets to the ticket before
then, am reasonably likely to have some free time to poke at Ivy again in
December or so.
> *.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)
