We only do this in the markup cache checker for urls:
URLConnection urlConnection = null;
try
{
urlConnection = url.openConnection();
// update the last modified time.
long lastModified = urlConnection.getLastModified();
if (lastModified != this.lastModified)
{
this.lastModified = lastModified;
this.contentLength = urlConnection.getContentLength();
}
}
catch (IOException e)
{
log.error("getLastModified for " + url + " failed: " + e.getMessage());
}
finally
{
// if applicable, disconnect
if (urlConnection != null)
{
if (urlConnection instanceof HttpURLConnection)
{
((HttpURLConnection)urlConnection).disconnect();
}
else
{
try
{
urlConnection.getInputStream().close();
}
catch (Exception ex)
{
// ignore
}
}
}
}
Ad you can see we do everything in our power to close everything .
The problem is that that disconnect() method is only there for http resources.
Why you can have a Connection object without the possibility to close it is beyond me..
The stupid thing is if you look at the source code of all the JarXXX classes
There are plenty of close and cleanup methods. We just can access them..
johan
On 2/19/06, Jesse Sightler <
[EMAIL PROTECTED]> wrote:
That seems EXTREMELY unlikely. If this were the case, I would think a lot of apps would have fairly major and constant problems with open file limits. Why would it need one connection per entry within a single Jar?
Could it be something else that we are using (creating too many JARClassLoaders for the same jar or something)?
--
JessOn 2/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:don't know how it reports that,
But it seems to report a connection to that jar file that is made for every entry in the jar file.
johanOn 2/19/06, Jesse Sightler <[EMAIL PROTECTED]> wrote:I'm somewhat confused by now this relates. Why would this result in thousands of extra open files? Wouldn't it just be one open file per URLClassLoader?On 2/19/06, Johan Compagner <[EMAIL PROTECTED]> wrote:No this is already discussed long time ago on this mailing list.
It is a bug of sun. We can't do ONE thing about it.. It really sucks i know but its out of our hands.
Here is the bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4950148
Please vote for it, because we as wicket really have problems with it because we have many resources.
Maybe we can make the polling smarter.. If the resources comes from a jar file then don't test it anymore.
But don't know if we can see that (its the instance of the url connection that specifies that i guess)
johanOn 2/19/06, Gili < [EMAIL PROTECTED]> wrote:
Eek, XML files! ;)
That aside, I assume this means there is a bug in resource polling? ...
or is it normal for it to open all these files and never close them?
Gili
Igor Vaynberg wrote:
> seems there is a problem with how application.configure() works.
>
> if you call configure("deployment") from application.init() it doesnt
> really help, because a webapp.internalinit() runs before and already
> called configure("development") (if you did not speicfy deployment
> through web.xml or system prop) and so the resource thread is started
> already.
>
> my thought on this would be to get rid of public configure(string)
> methods and let deployment mode be configured either from web.xml or a
> system prop.
>
> and yes, turning off that thread solves andrew's problem.
>
> -Igor
>
>
>
>
> On 2/18/06, *Eelco Hillenius* < [EMAIL PROTECTED]
> <mailto: [EMAIL PROTECTED]>> wrote:
>
> Still, does the polling have that effect?
>
> On 2/18/06, Andrew Lombardi < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> > Yeah, I agree. I found the problem, in 1.2 versions, the servlet
> > variable has been changed to "configuration:deployment/development"
> > instead of "deployment:true/false".
> >
> > So I was checking in my base application class for deployment servlet
> > var, and calling configure("deployment") .. wasn't helping though
> > since the poll frequency was already set internally when
> > configuration variable is not found, so assumed development mode. So
> > it was polling every 1 second, even though I had set configure
> > ("deployment")
> >
> > Doh!
> >
> >
> > On Feb 18, 2006, at 9:31 PM, Eelco Hillenius wrote:
> >
> > > That sounds pretty crazy. Did you turn off template reloading? That
> > > would be the first thing to try, and actually wize in a production
> > > environment anyway. /If/ that helps, we might have something that
> > > should be done differently there.
> > >
> > > Eelco
> > >
> > >
> > > On 2/18/06, Andrew Lombardi < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> > >> When deploying one of our wicket-developed applications to our
> > >> production linux server, we've been seeing something very odd,
> maybe
> > >> someone can shed some light. This morning I awoke to error
> messages
> > >> in our Resin app server logs about "Too many open
> files". Checking
> > >> the max value, it was set at 65000.
> > >>
> > >> A check using lsof showed that the jar file where I have the Page
> > >> classes/html/prop files, had several entries. And it would
> vary up
> > >> and down from 1000 to well over 15000 entries for that single
> jar.
> > >> I'm in the process of setting up a test environment to see if
> I can
> > >> recreate the issue locally, or if it might be a linux-based issue.
> > >> I'm using Resin 3.0.17 with JDK 1.5.0_06 , and using the latest
> > >> snapshot from Wicket 1.2 branch.
> > >>
> > >> Any ideas?
> > >>
> > >>
> > >>
> > >> -------------------------------------------------------
> > >> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > >> log files
> > >> for problems? Stop! Download the new AJAX search engine that
> makes
> > >> searching your log files as easy as surfing the web. DOWNLOAD
> > >> SPLUNK!
> > >> http://sel.as-us.falkag.net/sel ?
> > >> cmd=lnk&kid=103432&bid=230486&dat=121642
> > >> _______________________________________________
> > >> Wicket-user mailing list
> > >> Wicket-user@lists.sourceforge.net
> <mailto: Wicket-user@lists.sourceforge.net>
> > >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >>
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > > log files
> > > for problems? Stop! Download the new AJAX search engine that
> makes
> > > searching your log files as easy as surfing the web. DOWNLOAD
> > > SPLUNK!
> > > http://sel.as-us.falkag.net/sel?
> > > cmd_______________________________________________
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> <mailto:Wicket-user@lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep
> through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 >
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> <mailto:Wicket-user@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> <https://lists.sourceforge.net/lists/listinfo/wicket-user>
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 < http://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642>
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> <mailto:Wicket-user@lists.sourceforge.net >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
