We need a last modified timestamp for the http HEAD request for resources inside jars
We could cache that result if we see that it comes from a jar. But as i said then we have
to make sure that we have some sort of soluton for OSGI containers where the jar is updated
from beneath us.
johan
On 4/13/06, Juergen Donnerstag
<[EMAIL PROTECTED]> wrote:
I don't meant to completely remove it, but remove the troublesome
piece. If we can not fixed it completely, the question is shall we
deliberately allow memory leaks or shall we disable lastModifiedTime()
for the resource which we can not close and which cause memory leaks.
I'd prefer the latter one, especially at it is important for
development only. In production mode, at least for markup files, it is
no issue. Yet another approach for the URL in question would be to
remove the markup cache entry after X secs. Which reminds me that we
need an eviction strategy for the markup cache anyway.
Juergen
On 4/13/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> That can't be removed from there.
> Because that is also used with (shared)resources and so on.
>
> We could optimize it there. That we look if it is inside a jar and cache the
> result.
>
> The problem is that with OSGI you could just upgrade the jar in a running
> system....
>
> johan
>
>
>
> On 4/13/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > Either that way or remove the code from
> > UrlResourceStream.lastModifiedTime/() and check well
> known urls (file,
> > http) only.
> >
> > Juergen
> >
> > On 4/13/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > we could do that i guess. Test if we can make a real file first before
> > > adding them to the markup watcher.
> > >
> > > johanm
> > >
> > >
> > >
> > > On 4/12/06, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:
> > > >
> > > Can you imagine a workaround like using UrlConnection only if no other
> > > means exist.
> > > Aren't markup file are usually (99%) either files or files within
> > > jars? Lets say we do polling only for URL type which refer to files
> > > and files within jars and all other ones can not be checked.
> > >
> > > Juergen
> > >
> > > On 4/12/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
> > > > it is the polling!
> > > > All the url connections to the markup checking the last modified..
> > > >
> > > > That whole url connections and not letting me clean it up (there is a
> > > > url.openConnection but no disconnect or URLConnection.connect () and
> now
> > > > disconnect() )
> > > > But there are many more places in java that don't let me control the
> > > cleanup
> > > > this is just plain stupid. And one big flaw is some api's of java.
> > > >
> > > > for example this is also such a thing:
> > > >
> > >
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715154
> > > > will not be fixed... tseee
> > > >
> > > > johan
> > > >
> > > >
> > > >
> > > > On 4/12/06, Juergen Donnerstag < [EMAIL PROTECTED] > wrote:
> > > > > That is kind of strange. We don't reload markup files anymore in
> 1.2,
> > > > > we just remove the cache entry if the file modify time has changed.
> > > > > Only if required, the file is reloaded. In case of a jar, the file
> > > > > doesn't change and hence doesn't/shouldn't get reloaded.
> > > > >
> > > > > would it be possible to analyse which files are open?
> > > > >
> > > > > Juergen
> > > > >
> > > > > On 4/12/06, Eelco Hillenius <[EMAIL PROTECTED] > wrote:
> > > > > > Yeah, the problem /should/ be gone, as in production you would
> have
> > > > > > resource polling turned off, which is the cause of the problem in
> the
> > > > > > first place.
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > > > On 4/12/06, Tom Desmet < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > >
> > > > > > > After switching to production mode, the problem does not seem to
> > > > appear any more at first sight.
> > > > > > > As the problem cannot be simulated by carrying out a specific
> > > action,
> > > > but only occurs after a while,
> > > > > > > I cannot confirm that it does not re-occur in production mode
> any
> > > > more.
> > > > > > > Again I have monitored file usage in production mode, and it
> seems
> > > > that indeed at this moment,
> > > > > > > the wicket main jar file is not opened multiple times as in
> > > > development mode.
> > > > > > > Opposed to the main jar, the extension jar has a growing number
> of
> > > > file handles.
> > > > > > > Right now I cannot tell if this will make the problem re-occur.
> > > > > > >
> > > > > > > I'll keep you posted on future experience.
> > > > > > >
> > > > > > > Thank you for the advice!
> > > > > > >
> > > > > > > Tom Desmet
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "Johan Compagner" < [EMAIL PROTECTED] >
> > > > > > > Verzonden door:
> > > > [EMAIL PROTECTED]
> > > > > > >
> > > > > > > 11/04/2006 15:51
> > > > > > >
> > > > > > > Antwoord a.u.b. aan
> > > > > > > wicket-user@lists.sourceforge.net
> > > > > > >
> > > > > > >
> > > > > > > Aan wicket-user@lists.sourceforge.net
> > > > > > >
> > > > > > > Cc
> > > > > > >
> > > > > > >
> > > > > > > Onderwerp Re: [Wicket-user] Wicket 2 (beta 3) and Resin 3.0.18
> on
> > > SuSE
> > > > 9.3 FileNotFoundException Too many open files
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > When you set it to deployment mode what happens then?
> > > > > > >
> > > > > > > If you want markup polling to see changes do set the
> > > > > > > public void setResourcePollFrequency(final Duration
> > > > resourcePollFrequency)
> > > > > > >
> > > > > > > to a higher number like 10 seconds..
> > > > > > >
> > > > > > > johan
> > > > > > >
> > > > > > >
> > > > > > > On 4/11/06, Tom Desmet < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > On my company, we have an issue with wicket 2.0 beta 3 and
> Resin
> > > > 3.0.18.
> > > > > > > After resin is active for a while, a stack trace occurs in the
> > > > logfile with the following exception ...
> > > > > > > FileNotFoundException (Too many open files). The exception
> occurs
> > > > multiple times.
> > > > > > > We have tested with our own application, and afterwards also
> with a
> > > > clean resin installation with only the wicket sample application.
> > > > > > > In both cases the problem occurs.
> > > > > > >
> > > > > > > We are using SuSE 9.3 ( Linux linux01 2.6.11.4-21.7-smp #1 SMP
> Thu
> > > > Jun 2 14:23:14 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux )
> > > > > > > on an intel xeon.
> > > > > > >
> > > > > > > We are using Sun JRE:
> > > > > > > java version " 1.5.0_06"
> > > > > > > Java(TM) 2 Runtime Environment, Standard Edition (build
> > > 1.5.0_06-b05)
> > > > > > > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_06-b05, mixed
> mode)
> > > > > > >
> > > > > > > Problem also occurs on JRockit:
> > > > > > > java version " 1.5.0_04"
> > > > > > > Java(TM) 2 Runtime Environment, Standard Edition (build
> > > 1.5.0_04-b05)
> > > > > > > BEA JRockit(R) (build
> > > > R26.0.0-188-52875-1.5.0_04-20051110-0920-linux-x86_64
> , )
> > > > > > >
> > > > > > > When investigating open file handles with lsof, it seems that
> the
> > > > wicket jar files have a very high amount of open file handles (+/-
> 1000).
> > > > > > > (I think the problem occurs when more than 1024 files are
> opened
> > > > simultaneously)
> > > > > > >
> > > > > > > All these file handles are allocated to the wicket jar files.
> > > > > > >
> > > > > > > We have other resin instances running without wicket, and there
> the
> > > > phenomenon does not occur,
> > > > > > > so it is probably related to the combination Resin / Wicket.
> > > > > > >
> > > > > > >
> > > > > > > Contents of /proc/sys/fs/file-max
> > > > > > > 203357
> > > > > > >
> > > > > > > Contents of /proc/sys/fs/file-nr
> > > > > > > 5835 0 203357
> > > > > > >
> > > > > > > Alle entries in /etc/security/limits.conf are commented out.
> > > > > > > Resin is running as user root for testing purposes.
> > > > > > >
> > > > > > > When investigating open file handles on other files, no
> extremely
> > > > high file usage on other processes is detected.
> > > > > > > Does someone have a clue what could be going on here? Has
> someone
> > > > experienced something similar?
> > > > > > >
> > > > > > > After googling for the problem, I did not bump in any eventual
> > > > solution. All help would be welcome.
> > > > > > > Thanks in advance for any reaction.
> > > > > > >
> > > > > > > Tom Desmet
> > > > > > >
> > > > > > >
> > > >
> > >
> ____________________________________________________________________________________________________________________________________
> > > > > > >
> > > > > > > ATTENTION !!
> > > > > > >
> > > > > > > This email and any files transmitted with it are confidential
> and
> > > > intended solely for the use of the individual or entity to whom they
> are
> > > > addressed.
> > > > > > > If you are not the intended recipient of this message you are
> > > hereby
> > > > notified that any use, distribution or reproduction of this message
> and
> > > any
> > > > files is prohibited.
> > > > > > > If you have received this email in error please notify the
> system
> > > > manager by sending this email to [EMAIL PROTECTED] .
> > > > > > > Any views expressed in this email are those of the individual
> > > sender
> > > > and may not necessarily reflect the views of TVH - Group Thermote &
> > > > Vanhalst.
> > > > > > >
> > > > > > > This footnote also confirms that this email message has been
> swept
> > > by
> > > > our virus-scanning software for the presence of computer viruses.
> > > > > > >
> > > >
> > >
> ____________________________________________________________________________________________________________________________________
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > -------------------------------------------------------
> > > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > > language
> > > > > > that extends applications into web and mobile media. Attend the
> live
> > > > webcast
> > > > > > and join the prime developer group breaking into this new coding
> > > > territory!
> > > > > >
> > > >
> > >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > > > > > _______________________________________________
> > > > > > Wicket-user mailing list
> > > > > > Wicket-user@lists.sourceforge.net
> > > > > >
> > > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > > > >
> > > > >
> > > > >
> > > > >
> -------------------------------------------------------
> > > > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > > language
> > > > > that extends applications into web and mobile media. Attend the live
> > > > webcast
> > > > > and join the prime developer group breaking into this new coding
> > > > territory!
> > > > >
> > > >
> > >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > > > > _______________________________________________
> > > > > Wicket-user mailing list
> > > > > Wicket-user@lists.sourceforge.net
> > > > >
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > > > >
> > > >
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > >
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > > that extends applications into web and mobile media. Attend the live
> webcast
> > > and join the prime developer group breaking into this new coding
> territory!
> > >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > > _______________________________________________
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> > that extends applications into web and mobile media. Attend the live
> webcast
> > and join the prime developer group breaking into this new coding
> territory!
> >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
