[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Request PMC approval for 157098 and 158329


I'm requesting review for these two bugs for 1.5.2:

157098 - [hotbug_request] Repetitive file I/O by TLDCMDocumentManager$IncludeHelper.getContents() , caching solution provided, JSP validator slow due to repetitive parsing of fragments
This patch introduces a new internal JSPFragmentBufferCache for use both by the JSP translator and the JSP model's custom tag library support.  The new class keeps a string buffer in memory as long as a model is using it and converts it into a weak reference so that when using (e.g. validating) multiple files that all refer to the same fragment, even if not at the same time, disk I/O is reduced with minimal impact on memory usage.  It also ensures that each retrieval of a fragment's contents updates the buffer if the file was modified, so that clients always retrieve the correct copy of the file's contents when they request it.


158329 - TaglibIndex cache files aren't read back properly
The TaglibIndex implemented a cache in 1.5.1 that greatly sped up the startup time by not searching the build path for tag libraries.  To do this, it wrote out a simple table of the build path information for each project into a UTF-16 encoded file within its plugin's metadata folder.  In order to support continuing development, the cache is ignored if the first line does not match the current "version" string according to a simple string comparison.  Reading the cache file relies on the platform's text file buffer APIs, which as reported in bug 160614, do not detect encodings properly for files that are not workspace resources.  Typically this means reading the 16-bit characters as 8-bit characters and treating the Byte Order Mark in front as characters at the start of the first line.  The result of this is that the cache is never successfully reloaded because the simple string comparison fails every time.  While this is not a catastrophic functional failure, it does negate the huge savings that the cache provides (see bug 148649).  The patch simply changes the reading in of the cache file to use a more basic InputStreamReader with a fixed UTF-16 encoding.  No released version has ever used a different encoding, making this assumption safe.


---
Nitin Dahyabhai