On 05/06/17 21:48, Christopher Schultz wrote: > Mark, > > On 6/3/17 4:25 PM, Mark Thomas wrote: >> All, > >> I wanted to provide a little more context to the SMAP changes I >> have started working on. > >> The primary driver for all of this is this bug: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=49176 > >> Particularly comment #4. > >> Currently, the SMAP implementation is more generic than it needs to >> be for Jasper. I am currently working on removing those elements >> Jasper will never need. > >> The SMAP is produced in String format as required for insertion >> into a .class file. My expectation is that the API will need >> modification to expose the SMAP in object form (details TBD). The >> SMAP will then be retained for each class and used in preference to >> the page nodes for constructing error pages. > >> The final solution is far from fixed. I need to do some >> performance testing with the current page nodes solution so I can >> compare the SMAP approach. There are various design decisions still >> to be made: - cache SMAP vs read it from the .class file as >> required - cache all, some (LRU), none - cache SMAP with the >> compiler (like page nodes) or some new web application wide cache? >> - no access to page nodes means we'd also need to parse the source >> JSP/tag to display the source extract > >> I hope this provides some useful context to my current commits. > >> Thoughts / comments / suggestions welcome. > > Would an object-based SMAP description be any more memory-efficient > than one that has been "serialized" to String?
Almost certainly not. However, it will be a lot faster to use to lookup line mappings as otherwise we'd have to parse the String first. I also expect it to be a lot more memory efficient than the current page nodes structure. > If there is a lot of > re-use of information (e.g. class names, method names, etc.) then I > can see a big benefit to retaining an object structure instead of a > String; the String can be complied-into the .class file and then > discarded for runtime. > > What kinds of runtime failures require SMAP-like information to be > available? Anything where we want to convert the .java line number from the stack trace to the .jsp / .tag line number so we can display a source snippet. At compile time, we'll still need to use the page nodes. At runtime, the plan is to use the SMAP. i.e. from JspServletWrapper.handleJspException() > If using an LRU-type cache, it should be tunable. That way, > it can be given a large amount of memory for high-performance > error-handling or small for sites that don't want to waste memory. Is > there utility in supporting a setting for "discard SMAP data after > successful JSP compile" where *no* SMAP-like information would be > used? That option already exists. Mark > That is more than just setting LRU_size = 0 because an runtime > error would generate a "normal" stack trace instead of an "enriched" one > . > > -chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
