Will this fix also have been applied to the 1.2 branch?
"Adam Winer" <[EMAIL PROTECTED]> wrote on 06/21/2007 05:28:32 PM: > On 6/21/07, Simon Lessard <[EMAIL PROTECTED]> wrote: > Hmmm, I assume this is used mainly to detect skin files' version? > > > It's used in a bunch of places to detect modification - skin > files, ResourceServlet, jsp modifications, etc. > I've checked in a fix that should resolve this, > but I'm not 100% sure. I've mostly been looking at > the calls to FileInputStream.finalize() - there were a > lot coming in that had still-open FileDescriptors. > I'd appreciate further testing. > > It'd be worthwhile to look at optimizing further to block > any attempt to call getLastModified() on a JAR, but > for now I'm hoping it'll be enough to close up all URLConnections. > In a bit of googling, it'd seem that this has bitten a lot > of developers. > > -- Adam > > Maybe we could create a kind of ResourceDescriptor file that would > include two URLs, the real one and the container file's (the .jar > URL for instance, but would be the same as the real URL most of the > time). The getLastModified method of the ResourceDescriptor could > then use that second URL for purpose of modification checks, > theorically preventing the JVM from opening the JAR file. > > > Regards, > > ~ Simon > > On 6/21/07, Adam Winer < [EMAIL PROTECTED]> wrote: > I think I've found the problem - Trinidad calls > URLConnection.getLastModified() in a number > of places. If that's pointing at an URL from > inside a JAR, this will implicitly open the > JAR file, and not release the file until GC. > Looking at solutions now. > > > -- Adam > > On 6/21/07, Fleischer Peter <[EMAIL PROTECTED]> wrote: > The problem is reproducable. After restarting tomcat and some > requests to my application the jar file will again be opened > multiple times. Every (initial?) request to a page increases the > number. Eventually after some time the files are garbage collected. > > Peter > -----Ursprüngliche Nachricht----- > Von: Scott O'Bryan [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 21. Juni 2007 00:29 > An: MyFaces Discussion > Betreff: Re: [Trinidad] Causing Too many open files error? > I saw this as well using Oracle JDeveloper so I agree that I don't > think this is a Tomcat issue. I'm not sure what might be causing > this though because I shut down my webserver and restarted it and > everything has been working fine since. > > What happens when you restart tomcat? > > Scott > On 6/20/07, Fleischer Peter <[EMAIL PROTECTED] > wrote: > Hello, > > we are developing a quite simple application based on MyFaces, > Trinidad and Facelets. After deploying this application to a Tomcat > 5.5.23 and using the application for a while we are facing > connection errors in Tomcat caused by too many open files. > > Checking the running Tomcat process with lsof (list open files) we > discovered, that <application>/WEB-INF/lib/trinidad- impl-1.0.1- > incubating-SNAPSHOT.jar was open for about 300 times. The number > rises with every request. At some time eventually a garbage > collection closes all these files. > > I don't think this is a Tomcat error, because this jar is the only > jar file opened so many times. Perhaps some Trinidad code fails to > close a file? Is this a known issue? > > Many thanks in advance. > > Peter Fleischer > > _____________________________________________________________ > > Munich Airport International > Flughafen München GmbH > Peter Fleischer > ITED Competence Center Application Development > Support Division Information Technology > P. O. Box 23 17 55 > 85326 München > Phone: +49 89 975-3 24 30 > Fax: +49 89 975-3 24 06 > <mailto:[EMAIL PROTECTED] .de > > > Vorsitzender des Aufsichtsrats: - Chairman of the Supervisory Board: > Staatsminister Prof. Dr. Kurt Faltlhauser > Geschäftsführung: - Executive Board: > Dr. Michael Kerkloh, Walter Vill und Peter Trautmann > Handelsregister: - Commercial Register: RG München, HR-Nr. B 5448 > Sitz der Gesellschaft: - Registered Office: München > _____________________________________________________________ > > >
