[I sent this mail to wicket-develop as well, but I have not seen it 
there yet, is that list filtered?]. This is a workaround method for the 
wicket developers to solve the problem with "Too many open files" that a 
lot of people have been having. It's a bug in Sun's JarURLConnection (I 
reported it). The workaround should solve the problems even in 
development mode.

Hi,

When you open an URL connection to an entry in a jar, you get a
JarURLConnection. The JarURLConnection in the package
sun.net.www.protocol.jar has an internal field

    /* the url connection for the JAR file */
    private URLConnection jarFileURLConnection;

which you cannot access in any way. When you ask for the last modified
time, the JarURLConnection will ask for the header field
"last-modified", which in turn will ask the jarFileURLConnection for the
that header field, which in turn will cause the initializeHeaders() call
in FileURLConnection, which in turn calls connect() and opens the file
(even though for the last modified header that is quite unnecessary).
The way to close the file is to call getInputStream().close() on the
jarFileURLConnection field, but unfortunately you can't since it is hidden.

There is a very simple workaround though. In code:

            URL url = new URL("jar:file:jarfile.jar!Entry.class");
            URLConnection connection = url.openConnection();
            if (connection instanceof JarURLConnection) {
                JarURLConnection jarUrlConnection = (JarURLConnection)
connection;
                URL jarFileUrl = jarUrlConnection.getJarFileURL();
                URLConnection jarFileConnection =
jarFileUrl.openConnection();
                long lastModified = jarFileConnection.getLastModified();
                jarFileConnection.getInputStream().close();
                System.out.println("last modified=" + new
Date(lastModified));
            }

[note: you could probably do something like a while (connection 
instanceof JarURLConnection) for jars in jars, but I haven't tested that 
yet].

In other words, to get the last modified time of a jar file *entry*, we
just get the last modified time of the jar *file*.  (Note that in the
current Sun implementation that's what it does anyway). This makes sense
since you cannot change a part of the jar file without changing the jar
file itself. Now we do have the input stream to actual jar file, and we
can close it.

I'm sure there's an even better implementations that does not open the
jar file in the first place, but this should be fine for most purposes
and at least it kills the file descriptor leak.

Regards,
Sebastiaan

Johan Compagner wrote:
> As i said before. we can apply this patch, but there is one problem
> and that is OSGI wicket solutions.. That do jar updates by just 
> dropping them in a running system
> How are we going to test that?
>
> Can you test something else? ( i also will try to test that)
>
> comment out this code:
>
> try
>                     {
>                         connection.getInputStream().close();
>                     }
>                     catch (Exception ex)
>                     {
>                         // ignore
>                     }
>
> because if i look in the debugger it seems to me that lastmodified 
> doesn't really open a stream.. (but i can be wrong i have to test this 
> further)
> But if that is not the case then we do here to much! we open the 
> inputstream and the resources while we are trying to close it..
>
> johan
>
>
> On 9/20/06, *SourceForge.net* <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
>
>     Patches item #1562130, was opened at 2006-09-20 13:57
>     Message generated for change (Tracker Item Submitted) made by Item
>     Submitter
>     You can respond by visiting:
>     
> https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1562130&group_id=119783
>     
> <https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1562130&group_id=119783>
>
>     Please note that this message will contain a full copy of the
>     comment thread,
>     including the initial issue submission, for this request,
>     not just the latest update.
>     Category: core
>     Group: None
>     Status: Open
>     Resolution: None
>     Priority: 5
>     Submitted By: Jean-Baptiste Quenot (quenotj)
>     Assigned to: Nobody/Anonymous (nobody)
>     Summary: File descriptor leak in URLResourceStream
>
>     Initial Comment:
>     See discussion at
>     
> http://www.nabble.com/File-descriptor-leak-in-DEVELOPMENT-mode-tf2280488.html#a6334936
>     
> <http://www.nabble.com/File-descriptor-leak-in-DEVELOPMENT-mode-tf2280488.html#a6334936>
>
>     A file descriptor leak is observed in DEVELOPMENT mode,
>     as resources are reloaded every second, and also in
>     DEPLOYMENT mode when serving resources.  This leads to
>     an OS error "Too many files open", quickly in
>     DEVELOPMENT (a few hours), and slowly in DEPLOYMENT.
>
>     Even if the real fix has to occur in the JDK (or the
>     JVM) itself, Wicket could simply prevent the reloading
>     of resources located in JARs as a workaround.  This is
>     what adresses the attached patch.
>
>     ----------------------------------------------------------------------
>
>     You can respond by visiting:
>     
> https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1562130&group_id=119783
>     
> <https://sourceforge.net/tracker/?func=detail&atid=684977&aid=1562130&group_id=119783>
>
>     -------------------------------------------------------------------------
>     Take Surveys. Earn Cash. Influence the Future of IT
>     Join SourceForge.net's Techsay panel and you'll get the chance to
>     share your
>     opinions on IT & business topics through brief surveys -- and earn
>     cash
>     http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>     
> <http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
>     _______________________________________________
>     Wicket-develop mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wicket-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to