https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #11 from Mark Thomas ---
I've put together an alternative proposal:
https://github.com/apache/tomcat/pull/146
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #10 from Phillip Webb ---
@Mark
I've updated the PR based on your comments. There is now a cache for concurrent
access as well as protection against DoS attacks. I've also tried to add some
tests. The list of common charsets and
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #9 from Phillip Webb ---
> Can you provide some context around why 31ms is significant for the use
> case you are considering? It doesn't seem significant for the typical use
> cases we see.
Spring Boot uses Embedded Tomcat as
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #8 from Mark Thomas ---
Just to note that the performance issue with unknown charsets wasn't memory
related. It was lock contention. Bug 51400 has the details.
Can you provide some context around why 31ms is significant for the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #7 from Phillip Webb ---
> I don't see the benefit as there's a clear downside and the
> complexity skyrockets. IMO you should focus on the String
> optimization since it doesn't have these issues.
I'll continue with the String
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #6 from Remy Maucherat ---
I don't see the benefit as there's a clear downside and the complexity
skyrockets. IMO you should focus on the String optimization since it doesn't
have these issues.
On my desktop computer, I measured
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #5 from Phillip Webb ---
@Mark Thanks for pointing me at those previous issues, I should have thought to
search first!
It seems like I may have misunderstood the reason for the cache existing in the
first place. My original
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #4 from Mark Thomas ---
Of course. That makes option 2 a non-starter.
The other option isn't that far from the current code. I think it is worth
looking at what it does to memory footprint and start-up time so we can see if
the
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #3 from Remy Maucherat ---
I think this adds complexity and possible problems for no real benefit. For
example option 2 could have a very big cache (all you need to do is request
random charset values) and could need a lot more
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
Mark Thomas changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Mark
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
Andy Wilkinson changed:
What|Removed |Added
CC||awilkin...@pivotal.io
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
--- Comment #1 from Phillip Webb ---
Pull request for consideration: https://github.com/apache/tomcat/pull/142
--
You are receiving this mail because:
You are the assignee for the bug.
13 matches
Mail list logo
