JBossDeveloper

Hi Tomaz,

can you please explain what you mean by "url.getContentLenght()" is opening file handles? If you mean, it is triggering undertow to open fds then maybe, but that's not the servlets fault.

There's nothing wrong with the servlet using "url.getContentLenght()".

I've looked at it and while there are some parts that could be refactored I do not see what would make undertow create >2000 open fd for a single webstart application download.

Furthermore, testing on Tomcat-7 and Tomcat-8, I do not see more than 20 fd open at anytime while downloading the same app (see Christian Bourque).

It is possible I did not understand points 2 and 3.

So, after more testing there is no doubt there is a problem and it doesn't look like it's "webstart related".

This is the test I did:

for (( i = 0; i < 10000; i++ )) do wget http://xo-vm-gui1:8080/appiagui-webstart/startup.jar; done

Open files goes through the roof!

The server crashes with:

2015-02-22 22:23:03,870 ERROR [io.undertow.servlet] (default task-25) Internal error:: java.io.FileNotFoundException: /home/masterdev/opt/wildfly/standalone/tmp/vfs/temp/temp120d28c709b6bd40/appiagui-webstart.war-6d4f781e2db67587/startup.jar (Too many open files)

The same on tomcat 7 and 8 results in an increase of 1-5 FD(s) open.

This makes no sense and makes wildfly unusable for us.

Would be nice to get some feedback.

Thanks guys.

(BTW, this test was done on latest 8 and 9-nightly).

I just tested this, and I see the same issue, however it does not really appear to be a bug in Undertow but rather a bug in the JnlpDownloadServet.

The code in jnlp.sample.servlet.JnlpResource#getLastModified(ServletContext, java.net.URL, java.lang.String) does the following:

long getLastModified( ServletContext context, URL resource, String path )
    {
        long lastModified = 0;
        URLConnection conn;
        try
        {
            // Get last modified time
            conn = resource.openConnection();
            lastModified = conn.getLastModified();
        }
        catch ( Exception e )
        {
            // do nothing
        }

In this case the URL instance is a file:// URL and the resulting connection is a FileURLConnection. When FileUrlConnection.getLastModified() is called the URLConnection implementation opens a FileInputStream. The only way to close this stream is to do: conn.getInputStream().close().

The only part of this that really has anything to do with Undertow is that it returns a file based URL, which is perfectly legitimate.

So, looking at "sun.net.www.protocol.file.FileURLConnection" I can see that you are right, the internal inputstream is never closed. However, this looks more like either bad code or crappy Java API.

getLastModified() should take care of opening and closing its stream and only when getInputStream is explicitly called should there be a "close()" by the user.

Anyways, it is what it is. Doesn't explain why tomcat doesn't break but it won't cost me much to add a "close()".

I agree its a crappy API (getLastModified() should not even need to open an InputStream).

Tomcat probably uses its internal DirContextURLConnection instead of a file:// url.

I have forked the jnlp-servlet ( bitstrings/jnlp-servlet · GitHub ) and fixed the leaks.

There were more leaks than on the Titanic.

Everything looks good now.

Thank you Stuart for your help.

(you can checkout the commits for the details)

You should also take fixed JNPL servlet that gqman69 put together. https://github.com/bitstrings/jnlp-servlet

as the biggest problem is that jnpl server is beyond buggy