[
https://issues.apache.org/jira/browse/IVY-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004058#comment-13004058
]
Jukka Laurila commented on IVY-654:
-----------------------------------
Same here, still having problems with Ivy 2.2.0. It's actually easy to
replicate at least in our setup:
for f in {1..10}; do ant ivy-retrieve& done
With this I get random errors, such as:
[ivy:resolve] java.text.ParseException: failed to parse report:
/home/XXXXX/.ivy2/cache/XXXXX.xml: An invalid XML character (Unicode: 0x0) was
found in the value of attribute "origin-location" and element is
"metadata-artifact".
[ivy:resolve] at
org.apache.ivy.plugins.report.XmlReportParser.parse(XmlReportParser.java:302)[ivy:resolve]
at
org.apache.ivy.core.report.ConfigurationResolveReport.checkIfChanged(ConfigurationResolveReport.java:98)
[ivy:resolve] at
org.apache.ivy.core.report.ResolveReport.checkIfChanged(ResolveReport.java:183)
[ivy:resolve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:241)
[ivy:resolve] at
org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:195)
This test case is artificial, but cache sharing would be very useful for us,
since we're using Ivy in the Jenkins CI system and so far this has forced us to
run just one executor per machine. We could try that EXECUTOR_NUMBER
workaround, but it would be less work for us if Ivy locking would just work.
> Share cache with locking
> ------------------------
>
> Key: IVY-654
> URL: https://issues.apache.org/jira/browse/IVY-654
> Project: Ivy
> Issue Type: New Feature
> Components: Core
> Reporter: Xavier Hanin
> Assignee: Xavier Hanin
> Fix For: 2.0.0-beta-1
>
>
> Currently it isn't possible use the same cache from multiple processes. This
> is a problem in some situations, especially for build servers, which have to
> use one cache per process, defeating some of the purpose of the cache. Adding
> an option allowing to use cache locking to ensure the repository cache can be
> used by concurrent build would be a nice improvement.
> To avoid degrading performance of local builds where the cache is not shared,
> this should only be an option.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
