Ivy
  1. Ivy
  2. IVY-1152

Ivy does not close URL connection to ivy-report.xsl properly

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.1.0
    • Fix Version/s: 2.2.0-RC1
    • Component/s: Core
    • Labels:
      None

      Description

      It seems BasicURLHanlder.disconnect() does not properly close URL connection to ivy-report.xsl file. In my case URL looks like:
      jar:file:/<path>/ivy-2.0.jar!/org/apache/ivy/plugins/report/ivy-report.xsl

      In disconnect() method there is a check for URL connection class:
      "sun.net.www.protocol.file.FileURLConnection".equals(con.getClass().getName())

      However in runtime this check does not work because instead of FileURLConnection there is JarURLConnection:
      sun.net.www.protocol.jar.JarURLConnection

      This leads to leaked input streams if Ivy is used programmatically within the same JVM.

        Activity

        Hide
        Maarten Coene added a comment -

        Thanks for the report!

        I've removed the extra check for "sun.net.www.protocol.file.FileURLConnection" and always close the InputStream now.
        Could you verify if this change solved your problem?

        thanks,
        Maarten

        Show
        Maarten Coene added a comment - Thanks for the report! I've removed the extra check for "sun.net.www.protocol.file.FileURLConnection" and always close the InputStream now. Could you verify if this change solved your problem? thanks, Maarten
        Hide
        Pavel Sher added a comment -

        Well, I tried to fix this issue in the same way, however this does not seem to work.
        The opened input stream seems to be left after the getLastModified() call inside void download(URL src, File dest, CopyProgressListener l) method:
        long lastModified = srcConn.getLastModified();
        if (lastModified > 0)

        { dest.setLastModified(lastModified); }

        if I add additional check to this code:
        if (!(srcConn instanceof java.net.JarURLConnection)) {
        long lastModified = srcConn.getLastModified();
        if (lastModified > 0) { dest.setLastModified(lastModified); }

        }

        The stream is not open anymore, and everything looks fine. On Windows you can check it with help of SysInternals Process Explorer. On Unix you can probably use lsof utility (however I did not try it).

        Basically it looks like a bug in JVM, and it is not critical for those who use Ivy inside short lived processes. I've reproduced this problem in our tests which start artifacts resolution process via Ivy API, however I am not sure whether these not closed input streams do any harm. I also tried different versions of JVM and it looks like in Java 1.5 this bug is not so easy reproducable as it in Java 1.6. In Java 1.5 I see 2 streams open and this number is not increasing, while in Java 1.6 I see about 20 streams and it seems their number grows if I run more tests.

        Maybe it is safer to use Class.getResourceAsStream instead of URLs.

        Show
        Pavel Sher added a comment - Well, I tried to fix this issue in the same way, however this does not seem to work. The opened input stream seems to be left after the getLastModified() call inside void download(URL src, File dest, CopyProgressListener l) method: long lastModified = srcConn.getLastModified(); if (lastModified > 0) { dest.setLastModified(lastModified); } if I add additional check to this code: if (!(srcConn instanceof java.net.JarURLConnection)) { long lastModified = srcConn.getLastModified(); if (lastModified > 0) { dest.setLastModified(lastModified); } } The stream is not open anymore, and everything looks fine. On Windows you can check it with help of SysInternals Process Explorer. On Unix you can probably use lsof utility (however I did not try it). Basically it looks like a bug in JVM, and it is not critical for those who use Ivy inside short lived processes. I've reproduced this problem in our tests which start artifacts resolution process via Ivy API, however I am not sure whether these not closed input streams do any harm. I also tried different versions of JVM and it looks like in Java 1.5 this bug is not so easy reproducable as it in Java 1.6. In Java 1.5 I see 2 streams open and this number is not increasing, while in Java 1.6 I see about 20 streams and it seems their number grows if I run more tests. Maybe it is safer to use Class.getResourceAsStream instead of URLs.
        Hide
        Maarten Coene added a comment -

        Ok, I've changed the class XmlReportOutputter to use Class.getResourceAsStream instead of Class.getResource.
        I don't have time to test it at the moment, could you give it a try?

        Thanks,
        Maarten

        Show
        Maarten Coene added a comment - Ok, I've changed the class XmlReportOutputter to use Class.getResourceAsStream instead of Class.getResource. I don't have time to test it at the moment, could you give it a try? Thanks, Maarten
        Hide
        Pavel Sher added a comment -

        It seems the problem is fixed. I also found a workaround (cause I can't easily use new version of Ivy) - I can disable output report generation in ResolveOptions. This helps too.

        Thank you!

        Show
        Pavel Sher added a comment - It seems the problem is fixed. I also found a workaround (cause I can't easily use new version of Ivy) - I can disable output report generation in ResolveOptions. This helps too. Thank you!

          People

          • Assignee:
            Maarten Coene
            Reporter:
            Pavel Sher
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development