[jimmi1977]

OK, then it has to be related to the staleness checks.

I see you've got the system configured for container IO mode, meaning our code obtains files via servletContext.getResource(). The WebLogic file descriptor leak has to be related to this call or the subsequent interactions with the URL object returned. Are you able to provide a real filesystem path for webroot instead (at least to test)?

How would I go about that? I have full control over jvm args/configuration of this test system

[Isomorphic]

Look in your server.properties file, you should see:

webRoot: __AUTODETECT__

Change this to a real filesystem path.

[jimmi1977]

Look in your server.properties file, you should see:

webRoot: __AUTODETECT__

Change this to a real filesystem path.

This is weblogic 10.3. No such file found, don't think we have one inside war either...

[Isomorphic]

We previously urged you to check with WebLogic support - why not do so now, ask them about how you can find a file descriptor leak, and also ask them about this deployment mode (sometimes called "exploded deployment").

[jimmi1977]

We don't have weblogic support readily available - we are just certifying/performance testing our app against their server.

And, being a java developer myself, I would like to see a line of code responsible for a leak - because it is your code that calls java APIs in a way that causes a file descriptor to leak under weblogic. In my books, the problem is 50/50 between smartclient and weblogic, so you are at least partially responsible. I.e., what exactly is that you do with List.ds.xml every request?

Then, I can see if anything pops up in google related to the code that is supposedly leaking descriptors...

[Isomorphic]

?

No, it is our code that calls WebLogic code in such a way that WebLogic leaks, but other engines do not.

As best as we can tell, the particular API (we told you yesterday) is lastModified() - since you are using container IO, as previously described, this is a call on the java.net.URL returned by servletContext.getResource().

[Isomorphic]

Note, have you checked whether in JBoss you're using Container IO? If so, the same APIs are producing different results across WebLogic and JBoss, if not, we are calling java.io.File.lastModified() in JBoss but URLConnection.lastModified() in WebLogic.

[Isomorphic]

We've confirmed this as a WebLogic bug - lastModified() in fact leaks a file descriptor if called repeatedly on a URLConnection received via servletContext.getResource().openConnection(), even if the file is always the same.

A moderately horrific workaround of urlConnection.getOutputStream().close() after the lastModified() call fixes the problem - we're unsure of the performance consequences of this and we think it would be better to get a patch for WebLogic if one is available.

[jimmi1977]

Thanks a lot for finding this out! Did you just reproduce the problem? Or there is an official weblogic bug that I can refer to? This way I can track a bug and see if it gets fixed in later release.

What I don't understand is why you need to check if this file was changed, it is deployed as a part of war file and will never change between container restarts.

[Isomorphic]

We reproduced it. We haven't looked at whether WebLogic has a bug or patch available.

We don't have enough information to reliably know whether a file came from a .war, .jar or elsewhere.

[jimmi1977]

Thanks! One last question, which version of WL did you use? We have 10.3, latest is 10.3.4.

[Isomorphic]

We used 10.3.4.

[jimmi1977]

From application point of view, List.ds.xml is never changed, it is an internal smartclient file and can only be changed as new version of smartclient arrives. But this means a new version of our application that packages smartclient has arrived as well and has to be redeployed anyways.

Not sure what is the use case this file can change after deployment and between restarts. Only debugging of smartclient itself comes to mind.

[jimmi1977]

From application point of view, List.ds.xml is never changed, it is an internal smartclient file and can only be changed as new version of smartclient arrives. But this means a new version of our application that packages smartclient has arrived as well and has to be redeployed anyways.

Not sure what is the use case this file can change after deployment and between restarts. Only debugging of smartclient itself comes to mind.

Really would be nice if some kind of flag can be set to prevent these lastModified() checks. On a real production system, files are never changed on the fly even if they are indeed unpacked by a container to some temp folder. This will also improve performance by 0.1%. Just my 2c

[Isomorphic]

In looking into this, we found and fixed a flaw that made the staleness checks too frequent - the available performance gain from completely disabling all such checks or hardcoding certain files as immutable would no longer even be measurable.

Also, we're uncomfortable with providing a flag to turn off staleness checking entirely - this is a uniform codepath accommodating many types of loading, including loading from true HTTP URLs.

See what you can get out of WebLogic - you're much better off with this fixed in the platform. If it's a no-go we can look at implementing WebLogic workarounds.