https://bz.apache.org/bugzilla/show_bug.cgi?id=63235
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #2 from Mark Thomas <ma...@apache.org> ---
Lazy loading simply defers the performance hit so a user experiences a delay
during a request rather than it happening at startup. The balance of opinion in
the past has been that it is better to take such a hit on startup rather than
during a request.
This has been discussed previously. For the history see these bugs and the bugs
linked from them:
- bug 57808
- bug 58859
If we take some ideas from each of the various solutions that have been
proposed at various points then I think it might be possible to come up with
something that addresses all of the various concerns:
- retain a cache of charset name to Charset
- populate the keys only from a list of known charsets generated off-line by
looking at the various JREs (OpenJDK, Oracle, IBM to start with) at system
start
- add a unit test to monitor for new Charsets in new JRE versions
- populate the cache values at start-up for 'popular' charsets (ISO-8859-1,
UTF-8
plus any others we think are likely to be used)
- lazily populate any cache values for other Charsets
- if a charset is requested, the key is present but the JVM can't create it,
remove the
key from the cache to speed up any future requests (saves trying to load
non-existent
Charset again)
As I typed the above I though of perhaps a simpler variation:
- retain a cache of charset name to Charset
- populate the cache values at start-up for 'popular' charsets (ISO-8859-1,
UTF-8
plus any others we think are likely to be used)
- lazily populate any cache values for other Charsets
- if a requested Charset does not exist, insert a special "NoSuchCharset"
object to speed
up future requests
The more I think about it, the more I like that second option.
Thoughts?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
