https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
Sebastien Tardif changed:
What|Removed |Added
CC||sebtar...@ncf.ca
--
You are receiv
https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 JARs. This wasn't
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 unpacking the JARs to
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 Tomcat with ro file
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 7.3.4)
takes ~3s t
https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
Mark Thomas changed:
What|Removed |Added
CC||abruzgu...@eisgroup.com
--- Comment #21
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 make itself useful here.
--
Yo
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 assignee for the bug.
-
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.
--
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 library in favour of m
https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
Thomas Meyer changed:
What|Removed |Added
Attachment #34980|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=60963
Thomas Meyer changed:
What|Removed |Added
Attachment #34902|0 |1
is obsolete|
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.
--
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 for the bug.
--
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 read anything in i
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, that's why the whole "fast
>
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 Oracle JVM,
> my conce
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 looked for
other le
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 guess your sugges
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 work, because ZipInputStream will
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
PushBackInputstream and the
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.
-
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 ZipInputStreamWithPosition constructor, should
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 affect all platforms.
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.
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 because:
You are the assi
27 matches
Mail list logo
