Yep - lately, I've switched from once a month to try to have 1.2 branches in sync with the 1.0 releases - so we'll have a 1.2.1 release along with the 1.0.1 release and the two line up. If we follow that line, then the fix would go into 1.2 around the same time as we're getting ready to release 1.0.2.
-- Adam On 6/22/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
Yes, the 1.2-branch is created once in a while (currently once per month) based on the trunk (all fixes go in here) + a bit of Adam's magic to get JSF 1.2 in. -M On 6/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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 > > > _____________________________________________________________ > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
