[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 Sebastien Tardif changed: What|Removed |Added CC||sebtar...@ncf.ca

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #25 from Mark Thomas --- Having looked into this further, the only way I could see to improve things significantly was to pre-process the JAR files from a packed WAR and populate the cache with the contents of the

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #24 from Mark Thomas --- Any chance you could elaborate on "security reasons"? For a read-only file system, you'd be much better off deploying am unpacked WAR. And the tricks earlier Tomcat versions used (like

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #23 from Thomas Meyer --- I was told that all tomcats are run with unpackWARs=false for security reasons. I really tried to convince the ops from changing the parameter to true, but no chance. I think you can run

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #22 from Mark Thomas --- Unfortunately, Boot depends on the outer JAR/WAR being uncompressed. Tomcat does not have the option to require that. My current test (a WAR that just contains all the JAR files from Jira

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 Mark Thomas changed: What|Removed |Added CC|

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #20 from Thomas Maslen --- Just kibitzing, and likely way off base, but: I've been fairly impressed by the Spring Boot Loader code for handling JARs in (uncompressed) WARs, not sure whether it could

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #19 from Mark Thomas --- Just a quick note to say I haven't forgotten about this. It is still on my TODO list. I hope to get to it in the next week or so. -- You are receiving this mail because: You are the

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #18 from Mark Thomas --- That is probably overkill in terms of size of the library compared to the current patch. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #17 from Thomas Meyer --- The upcoming commons-compress 1.14 library will have support for fetching the offsets of the zip local headers - https://github.com/apache/commons-compress/pull/22 should we use that

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 Thomas Meyer changed: What|Removed |Added Attachment #34980|0 |1 is obsolete|

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 Thomas Meyer changed: What|Removed |Added Attachment #34902|0 |1 is obsolete|

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #14 from Thomas Meyer --- Hi, any news on this? Do you want me to attach the patch here? Anything else I can do? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #13 from Thomas Meyer --- Hi, I implemented a basic ZIP file parser. An updated patch is here: http://static.217.14.99.88.clients.your-server.de/501 -- You are receiving this mail because: You are the assignee

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #12 from Thomas Meyer --- (In reply to Konstantin Kolinko from comment #11) > (In reply to Thomas Meyer from comment #8) > > > > Theoretically we want those bytes to be counted, but the ZipInputStream > > doesn't

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #11 from Konstantin Kolinko --- (In reply to Thomas Meyer from comment #8) > > Theoretically we want those bytes to be counted, but the ZipInputStream > doesn't read anything in it's construction phase,

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #10 from Thomas Meyer --- (In reply to Mark Thomas from comment #9) > The one thing that worries me about this patch is the degree to which it > depends on the JVM internals. While this works with the current

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #9 from Mark Thomas --- I've spent a little time looking at this. I can confirm that I see similar performance improvements with local testing. I can also confirm I have not observed any file locking. I haven't

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #8 from Thomas Meyer --- (In reply to Christopher Schultz from comment #7) > (In reply to Thomas Meyer from comment #6) > > Regarding ZipInputStreamWithPosition: > > I think you found the ugly part of this patch. I

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #7 from Christopher Schultz --- (In reply to Thomas Meyer from comment #6) > Regarding ZipInputStreamWithPosition: > I think you found the ugly part of this patch. I guess your suggestion > wouldn't

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #6 from Thomas Meyer --- Regarding ZipInputStreamWithPosition: I think you found the ugly part of this patch. I guess your suggestion wouldn't work, because ZipInputStream will construct itself with a new

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #5 from Thomas Meyer --- Regarding file locking issue: I didn't check this. I'll try to test this. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #4 from Christopher Schultz --- It looks like isInWAR in getJarInputStreamWrapper can be leaked. Will calling getWebResourceSet().closeJarFile undo this performance optimization? For

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #3 from Mark Thomas --- Looking at this is on my TODO list. The main question I have is does it still avoid file locking issues? These will be more obvious Windows (you won't be able to delete the WAR) but they

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #2 from Thomas Meyer --- I did als upload the patch here: http://static.217.14.99.88.clients.your-server.de/501 -- You are receiving this mail because: You are the assignee for the bug.

[Bug 60963] Optimize class loading for unpackWARs=false case

https://bz.apache.org/bugzilla/show_bug.cgi?id=60963 --- Comment #1 from Thomas Meyer --- Depending on the deployed WAR files loading is up to 7 times faster. Would be nice if somebody from the tomcat developers could have a look at this. -- You are receiving this mail