Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-783

SaxUtils leaks file handles, locks file on Windows

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Invalid
    • Affects Version/s: 2.1 GA
    • Fix Version/s: 2.1.1
    • Component/s: XML
    • Labels:
      None

      Description

      The method "createInputSource" in SaxUtils leaks the input stream in

      InputSource inputSource = new InputSource(resource.getInputStream());

      While this might be considered a small nuisance, it becomes a PITA on Windows, because the "SimpleXsdSchema" uses this method and therefore locks the "xsd" file in the file system, which is a pain when running "mvn clean install" because clean fails because the XSD/WSDL file is locked.

      There are basically 4 non-test usages of this method that need to be reworked to avoid leaking file handles.

        Activity

        Hide
        krosenvold Kristian Rosenvold added a comment -

        The enclosed patch adds a "CloseableInputSource" that can be properly closed.

        The test-cases on spring-ws seem to be quite far from working on windows, so I am unable to run them.

        I am unsure of how this should be tested (if necessary).

        Show
        krosenvold Kristian Rosenvold added a comment - The enclosed patch adds a "CloseableInputSource" that can be properly closed. The test-cases on spring-ws seem to be quite far from working on windows, so I am unable to run them. I am unsure of how this should be tested (if necessary).
        Hide
        krosenvold Kristian Rosenvold added a comment -

        It's locking on the WSDL too. Update coming soon

        Show
        krosenvold Kristian Rosenvold added a comment - It's locking on the WSDL too. Update coming soon
        Hide
        krosenvold Kristian Rosenvold added a comment -

        And here's version 2 that does not lock the wsdl file either

        Show
        krosenvold Kristian Rosenvold added a comment - And here's version 2 that does not lock the wsdl file either
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Thanks for work you put into those patches, but I cannot confirm the problem actually exists. According to the InputSource Javadoc, the underlying input stream should be closed as part of the parsing process:

        [...] standard processing of both byte and character streams is to close them on as part of end-of-parse cleanup, so applications should not attempt to re-use such streams after they have been handed to a parser.

        I did some further testing on this by putting a breakpoint on InputStread.close(), and it does get called as part of DocumentBuilder.parse(). All of this on MacOS X, using the standard Oracle JDK (1.7.0_04-b21).

        Are you using the standard Oracle JDK Xerces parser, or perhaps using something else, like the IBM JDK or a different parser?

        Show
        arjen.poutsma Arjen Poutsma added a comment - Thanks for work you put into those patches, but I cannot confirm the problem actually exists. According to the InputSource Javadoc , the underlying input stream should be closed as part of the parsing process: [...] standard processing of both byte and character streams is to close them on as part of end-of-parse cleanup, so applications should not attempt to re-use such streams after they have been handed to a parser. I did some further testing on this by putting a breakpoint on InputStread.close(), and it does get called as part of DocumentBuilder.parse(). All of this on MacOS X, using the standard Oracle JDK (1.7.0_04-b21). Are you using the standard Oracle JDK Xerces parser, or perhaps using something else, like the IBM JDK or a different parser?
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing as invalid for now.

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing as invalid for now.
        Show
        rogerdpack roger pack added a comment - also possibly related: http://betterlogic.com/roger/2013/04/documentbuilder-file-handle-leak-windows
        Hide
        krosenvold Kristian Rosenvold added a comment -

        @roger "not really", since I've been running on java7 all along.

        Show
        krosenvold Kristian Rosenvold added a comment - @roger "not really", since I've been running on java7 all along.

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            krosenvold Kristian Rosenvold
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - Not Specified
              Not Specified
              Logged:
              Time Spent - 35m
              35m