MyFaces Trinidad
  1. MyFaces Trinidad
  2. TRINIDAD-73

trinidad-impl.jar file is left open during execution

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1-core
    • Fix Version/s: 1.2.10-core, 1.0.10-core
    • Component/s: None
    • Labels:
      None

      Description

      When running a Trinidad application, trinidad-impl.jar is getting locked with open FileInputStream objects. When GC occurs, the FileInputStreams are getting cleared, but as new FileInputStreams are opened on each request, the file is eternally locked. Other files are likely getting locked too.

      1. URLUtils-patch-on-660215.txt
        3 kB
        Thomas Jacob
      2. URLInputStreamProvider-patch-on-549615.txt
        1 kB
        Thomas Jacob
      3. URLUtils.java
        2 kB
        Thomas Jacob
      4. AggregatingResourceLoader-patch-on-547038.txt
        2 kB
        Thomas Jacob
      5. CachingResourceLoader-patch-on-549615.txt
        3 kB
        Thomas Jacob
      6. ProxyResourceLoader-patch-on-518820.txt
        3 kB
        Thomas Jacob
      7. ResourceServlet-patch-on-549620.txt
        3 kB
        Thomas Jacob

        Issue Links

          Activity

          Hide
          Adam Winer added a comment -

          It appears that URLConnection.getLastModified() is the culprit - when pointing at a jar: or file: URL, it opens an input stream but does not close it. getInputStream().close() works around this limitation of URLConnection.

          Show
          Adam Winer added a comment - It appears that URLConnection.getLastModified() is the culprit - when pointing at a jar: or file: URL, it opens an input stream but does not close it. getInputStream().close() works around this limitation of URLConnection.
          Hide
          Adam Winer added a comment -

          Fixed. Or, at least, fixed the failures to call close(), and verified that FileInputStream.finalize() now is only running with FileDescriptors whose "handle" is -1, indicating that they've been properly closed.

          Show
          Adam Winer added a comment - Fixed. Or, at least, fixed the failures to call close(), and verified that FileInputStream.finalize() now is only running with FileDescriptors whose "handle" is -1, indicating that they've been properly closed.
          Hide
          Thomas Jacob added a comment -

          Sorry, but the fix does not work. The JARUrlConnection to the entry delegates to a UrlConnection to the entire JAR file, which in turn has the problem described above.
          The close() in the fix is performed on the wrong connection.
          However, the JAR file UrlConnection is not accessable, but changing the code

          URLConnection connection = url.openConnection();
          long modified = connection.getLastModified();
          try

          { InputStream is = connection.getInputStream(); if (is != null) is.close(); }

          to

          URLConnection connection = url.openConnection();
          long modified;
          if (connection instanceof JarURLConnection)

          { JarURLConnection jarUrlConnection = (JarURLConnection) connection; URL jarFileUrl = jarUrlConnection.getJarFileURL(); URLConnection jarFileConnection = jarFileUrl.openConnection(); lastModified = jarFileConnection.getLastModified(); jarFileConnection.getInputStream().close(); }

          else

          { lastModified = connection.getLastModified(); }

          may work.

          See http://www.mail-archive.com/wicket-user@lists.sourceforge.net/msg20937.html as well.

          Show
          Thomas Jacob added a comment - Sorry, but the fix does not work. The JARUrlConnection to the entry delegates to a UrlConnection to the entire JAR file, which in turn has the problem described above. The close() in the fix is performed on the wrong connection. However, the JAR file UrlConnection is not accessable, but changing the code URLConnection connection = url.openConnection(); long modified = connection.getLastModified(); try { InputStream is = connection.getInputStream(); if (is != null) is.close(); } to URLConnection connection = url.openConnection(); long modified; if (connection instanceof JarURLConnection) { JarURLConnection jarUrlConnection = (JarURLConnection) connection; URL jarFileUrl = jarUrlConnection.getJarFileURL(); URLConnection jarFileConnection = jarFileUrl.openConnection(); lastModified = jarFileConnection.getLastModified(); jarFileConnection.getInputStream().close(); } else { lastModified = connection.getLastModified(); } may work. See http://www.mail-archive.com/wicket-user@lists.sourceforge.net/msg20937.html as well.
          Hide
          Thomas Jacob added a comment -

          ... sorry, I forgot the exception try-catch thing.

          Show
          Thomas Jacob added a comment - ... sorry, I forgot the exception try-catch thing.
          Hide
          Scott O'Bryan added a comment -

          Reopening issue. Please submit a patch.

          Show
          Scott O'Bryan added a comment - Reopening issue. Please submit a patch.
          Hide
          Simon Kitching added a comment -

          Apache Commons Digester also struct this issue. Maybe the patch that fixed Digester could be useful to read. See:
          http://issues.apache.org/jira/browse/DIGESTER-29

          Show
          Simon Kitching added a comment - Apache Commons Digester also struct this issue. Maybe the patch that fixed Digester could be useful to read. See: http://issues.apache.org/jira/browse/DIGESTER-29
          Hide
          Thomas Jacob added a comment -

          Simon, I believe that Digester addresses a different issue. However, I cannot 100% prove this, because the API says something like "any caching method should be skipped", and the implementation that would use the setting is private. Still, I believe that getLastModified() is not addressed by this, any I cannot find the time to test this approach.

          The other way round, what about my fix suggestion? Any comments?
          I will try to create a patch for this (which is the first time I try so please forgive any mistakes here).

          Show
          Thomas Jacob added a comment - Simon, I believe that Digester addresses a different issue. However, I cannot 100% prove this, because the API says something like "any caching method should be skipped", and the implementation that would use the setting is private. Still, I believe that getLastModified() is not addressed by this, any I cannot find the time to test this approach. The other way round, what about my fix suggestion? Any comments? I will try to create a patch for this (which is the first time I try so please forgive any mistakes here).
          Hide
          Thomas Jacob added a comment -

          Attached the requested patch. Please review before committing. Please forgive me, if the format is wrong, since it's my first time...

          Show
          Thomas Jacob added a comment - Attached the requested patch. Please review before committing. Please forgive me, if the format is wrong, since it's my first time...
          Hide
          Thomas Jacob added a comment -

          I just stumbled upon more occurrances of this problem. One more in the trinidad-impl component, and four more classes to patch in the trinidad-api component.

          The URLInputStreamProvider-patch-on-549615.txt fixes the other occurrance in trinidad-impl.
          The other files fix trinidad-api. The URLUtils.java is to be added. It may also be moved from impl to api, as they both are identical.

          Again, please review my patch suggestion.

          Upload 1 of 2...

          Show
          Thomas Jacob added a comment - I just stumbled upon more occurrances of this problem. One more in the trinidad-impl component, and four more classes to patch in the trinidad-api component. The URLInputStreamProvider-patch-on-549615.txt fixes the other occurrance in trinidad-impl. The other files fix trinidad-api. The URLUtils.java is to be added. It may also be moved from impl to api, as they both are identical. Again, please review my patch suggestion. Upload 1 of 2...
          Hide
          Thomas Jacob added a comment -

          And upload 2 of 2...

          Show
          Thomas Jacob added a comment - And upload 2 of 2...
          Hide
          Thomas Jacob added a comment -

          ... I have set a breakpoint in the errorneous JDK method, and unfortunatelly, the method is still getting called. Now by MyFaces... I fear the story continues...

          Show
          Thomas Jacob added a comment - ... I have set a breakpoint in the errorneous JDK method, and unfortunatelly, the method is still getting called. Now by MyFaces... I fear the story continues...
          Hide
          Matthias Weßendorf added a comment -

          added public URLUtils class, made internal @Deprecated.
          rest of the fix will show up very soon

          Show
          Matthias Weßendorf added a comment - added public URLUtils class, made internal @Deprecated. rest of the fix will show up very soon
          Hide
          Matthias Weßendorf added a comment -

          thanks to Thomas Jacobs for his patch. Converted to current trunk(s) and committedit

          Show
          Matthias Weßendorf added a comment - thanks to Thomas Jacobs for his patch. Converted to current trunk(s) and committedit
          Hide
          Harald Kuhn added a comment -

          Thanks.
          This fix reduces the used file handles on first request from about 50 to 2. That's great.

          But I want to share two points I have noticed:
          1) this fix seems to be useless if your webapp is deployed to Tomcat (Version 5.5.25) with option antiJARLocking="true".
          This might be a Tomcat issue.

          2) There are still multiple file handles for the generated css files
          (Output of lsof)
          java 30914 tomcat 4r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 15r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 43r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 54r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 58r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 61r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 86r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 88r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css
          java 30914 tomcat 97r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css

          Show
          Harald Kuhn added a comment - Thanks. This fix reduces the used file handles on first request from about 50 to 2. That's great. But I want to share two points I have noticed: 1) this fix seems to be useless if your webapp is deployed to Tomcat (Version 5.5.25) with option antiJARLocking="true". This might be a Tomcat issue. 2) There are still multiple file handles for the generated css files (Output of lsof) java 30914 tomcat 4r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 15r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 43r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 54r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 58r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 61r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 86r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 88r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css java 30914 tomcat 97r REG 8,2 90191 833043 /opt/apache-tomcat-5.5.25/work/Catalina/localhost/current/adf/styles/cache/airplus-desktop-uhtlx2-en-ltr-ie-6.0.css

            People

            • Assignee:
              Matthias Weßendorf
              Reporter:
              Adam Winer
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development