Dave,
while I'd like to thank you for you're interest, I beg to differ on your
conclusions... after some investigations, I understood that those nasty jar
files were due to my Tomcat service not shutting down when Windows was
shutting down: hence, I think it is a Tomcat, rather than a Cocooon,
problem.
Anyway, provided you are using Tomcat 4 (possibly 4.0.1), Windows 2000,
IIS 5.0 and the ISAPI filter, could you do the following test ?
1) Shutdown Windows (without shutting down the Tomcat service first)
2) Restart Windows
3) Check whether all jar_cachexxxxx.tmp files, originated by the previous
Tomcat start were deleted
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
[EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Dave Pugh [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 23, 2002 10:15 AM
> To: [EMAIL PROTECTED]
> Subject: RE: How to clear the jar_cache files ?
>
>
> Sounds like BugId 4166799 in the Sun Bug Database
>
> hth,
> Dave
>
> Bug Id 4166799
> Votes 4
> Synopsis URL-downloaded jar files (jar_cache files) never get deleted
> Category java:classes_net
> Reported Against 1.2fcs, 1.2.1, 1.2.2, kestrel-beta
> Release Fixed kestrel-beta
> State Closed, fixed
> Related Bugs 4180369, 4215307, 4222586, 4233380, 4254020
> Submit Date Aug 17, 1998
>
> Description
> -----------
> The jar_cache temp files created by
> sun.net.www.protocol.jar.JarFileFactory
> never get deleted. As a result, you eventually run out of disk space, and
> deployed applications and services start failing. This is a
> serious problem
> when using downloadable jar files for codebases in RMI.
>
> The jar_cache temp files created by
> sun.net.www.protocol.jar.JarFileFactory
> never get deleted. As a result, you eventually run out of disk space, and
> deployed applications and services start failing. This is a
> serious problem
> when using downloadable jar files for codebases in RMI.
>
> Workarounds
> -----------
> none
>
> Evaluation
> ----------
>
>
> Using a fixed size hash table to cache the loaded jar files would
> solve the
> problem. A retirement policy can be used to retire entries in the
> cache when
> the cache becomes full. When a certain entry is retired, its
> corresponding temp
> file
> can be deleted. But this fix would be too complicated to put in
> at this stage,
> I am downgrading it to P4 for later possible considerations.
>
> The two suggested fixes will either not solve the problem
> correctly or totally.
> Deleting the temp file in the finally block is wrong, since the
> temp file is
> needed by the corresponding jar file if the jar file is to be
> cached. Using
> file.deleteOnExit will only delete the files when the JVM exits
> and will not
> solve the problem for long running applications.
>
>
> xxxxx@xxxxx 1998-08-17
>
> Respond to the new comments:
> If you call tmpfile.delete() while this tmpfile is being opened
> by a JarFile,
> on unix, the call would succeed while on win32 it will simply
> fail. So calling
> delete() in the finally clause will not solve the problem at all.
>
> xxxxx@xxxxx 1998-08-25
>
>
> This has been partly fixed in 1.2fcs by inserting an appropriate call to
> File.deleteOnExit. See 4180369. -- xxxxx@xxxxx 1998/10/9
>
> For the record, the partial fix for 4180369 didn't work on win32 because
> of bug 4171239.
>
>
> xxxxx@xxxxx 1999-04-27
>
> We have fixed this problem in Kestrel. The JarFileFactory will use special
> jar files which are deleted automatically once they are closed.
> This solves
> the problem on win32.
>
> xxxxx@xxxxx 1999-05-25
>
>
>
>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
