[Bug 68227] AsyncListener::onComplete is not called on network error if error listener calls dispatch
https://bz.apache.org/bugzilla/show_bug.cgi?id=68227 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Mark Thomas --- TL;DR - yes. FYI: This change originated from a(n internal) discussion with the Spring team. The expectation from the Spring team (which is consistent with the wording in the specification) was that if dispatch() was called from onError() then the dispatch would be performed. If your async error handling calls dispatch then that dispatch is now processed (as it should be). If the target of the dispatch can start async processing then you will need to guard against loops. -- 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
[Bug 68546] Performance optimization in PageContextImpl.getELContext()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68546 Mark Thomas changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Mark Thomas --- Re-opening so this doesn't get forgotten -- 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
[Bug 68546] Performance optimization in PageContextImpl.getELContext()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68546 --- Comment #8 from John Engebretson --- This is an interesting callout, thanks - I assumed that `HashMap`/`LinkedHashMap` viewed initialCapacity as the number of entries to hold, and calculated the array size separately using initialCapacity and loadfactor as you illustrated. Looking at JVM source, that is not the case. However, `HashMap(int, float)` delegates the calculation to a static utility method, `tableSizeFor(int)` which rounds up to the lowest power of two >= the requested capacity. That will hide some of the penalty from the error. Other thoughts: 1. I *think* the impact of this is small, thanks to the power-of-two. Small is greater than zero. 2. Directly calculating the length of an internal table feels wrong, but will produce the best possible outcome. The power of two logic will often result in wasted space regardless but it's still better than not providing the capacity hint. -- 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
[Bug 68546] Performance optimization in PageContextImpl.getELContext()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68546 --- Comment #9 from Christopher Schultz --- Which operation are we trying to optimize, here? Is it startup-time of the JSP when it's first put into service? If so, simply multiplying the import count by a constant should create enough initial capacity to avoid re-hashes. I like the first proposal where we simply multiply by some factor (e.g. 4/3). I don't see a reason to add more math at runtime. But I don't see *any* per-request impact, here, unless I've very much missing something. -- 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
[Bug 68546] Performance optimization in PageContextImpl.getELContext()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68546 --- Comment #10 from John Engebretson --- I agree, no per-request impact. -- 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
[Bug 68546] Performance optimization in PageContextImpl.getELContext()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68546 --- Comment #11 from Mark Thomas --- My analysis agrees with Chris's. There might be a re-hash during start-up that multiplying by 4/3 would address although the impact of that is going to be pretty minimal. The runtime impact is going to be zero. -- 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
