We could still apply this common case, and maybe test for the specific
ones (web logic, which uses a zip variant, right?) if possible. WDYT
Johan?

Eelco

On 11/27/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> So instead of opening a connection inside the jar we just open a connection
> to the jar only.
> That would work for the app servers that uses the jar url connection but it
> won't help
> for example WebLogic and others. Because they use there own kind of thing..
>
> johan
>
>
>
>
> On 11/27/06, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> > [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
> > >     Wicket-develop@lists.sourceforge.net
> > >     <mailto: Wicket-develop@lists.sourceforge.net>
> > >
> 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
> > > Wicket-develop@lists.sourceforge.net
> > >
> 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
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
> -------------------------------------------------------------------------
> 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
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
>

-------------------------------------------------------------------------
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
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to