Re: [Wicket-user] [Wicket-develop] [ wicket-Patches-1562130 ] File descriptor leak in URLResourceStream
[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=detailatid=684977aid=1562130group_id=119783
https://sourceforge.net/tracker/?func=detailatid=684977aid=1562130group_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
Re: [Wicket-user] [Wicket-develop] [ wicket-Patches-1562130 ] File descriptor leak in URLResourceStream
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=detailatid=684977aid=1562130group_id=119783
https://sourceforge.net/tracker/?func=detailatid=684977aid=1562130group_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
Re: [Wicket-user] [Wicket-develop] [ wicket-Patches-1562130 ] File descriptor leak in URLResourceStream
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?] The old dev list is shut down. You should have received a message stating this. Now that we're incubating Wicket, we moved the dev list over to wicket-dev at incubator.apache.org (send an email to wicket-dev-subscribe at incubator.apache.org to subscribe). The user list will follow in due time. Eelco - 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.phpp=sourceforgeCID=DEVDEV ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] [Wicket-develop] [ wicket-Patches-1562130 ] File descriptor leak in URLResourceStream
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=detailatid=684977aid=1562130group_id=119783
https://sourceforge.net/tracker/?func=detailatid=684977aid=1562130group_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:
