Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #5022 Filter Cache cleanup #5271

Merged
merged 6 commits into from Oct 5, 2020

Conversation

gregw
Copy link
Contributor

@gregw gregw commented Sep 15, 2020

Issue #5022 Filter Cache cleanup:

  • Fixed many compiler warnings
  • removed old LazyList leftovers
  • Don't create holder string for source unless required
  • Only have a single type of chain, so it can be wrapped regardless of cache
  • Reverse mappings lists to make filter chain creation easier
  • build chain directly rather than build a list then a chain

Signed-off-by: Greg Wilkins gregw@webtide.com

Issue #5022 Filter Cache cleanup:
 + Fixed many compiler warnings
 + removed old LazyList leftovers
 + Don't create holder string for source unless required
 + Only have a single type of chain, so it can be wrapped regardless of cache
 + Reverse mappings lists to make filter chain creation easier
 + build chain directly rather than build a list then a chain

Signed-off-by: Greg Wilkins <gregw@webtide.com>

// Servlet name filters
if (servletHolder != null && _filterNameMappings != null && !_filterNameMappings.isEmpty())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Servlet Spec requires that the first filters in the chain are the url style mappings, and then the servlet name mappings. This does it the other way around, doesn't it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would hope we fail some of our unit tests then.
We should have basic tests that validate these kinds of requirements from the servlet spec.
Unless Greg has done some kind of trickery and his "Reverse mappings" statement is really "mappings done in reverse" making the change he made valid again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@janbartel The lists are in reverse so we apply the inner onion skin first. The order the filters are executed is not changed.

Signed-off-by: gregw <gregw@webtide.com>
@gregw gregw marked this pull request as ready for review September 15, 2020 20:03
@joakime
Copy link
Contributor

joakime commented Sep 15, 2020

Test failure on "JDK8 / testHTTP2 – org.eclipse.jetty.osgi.test.TestJettyOSGiBootHTTP2" ?

turn off debug in OSGI test
@gregw
Copy link
Contributor Author

gregw commented Sep 16, 2020

thanks @janbartel .... but as I was about to merge, I've got cold feet!!!! I think this should be faster and better than the cache we currently have.... but I don't really know. So I'm not going to merge for this release cycle. @lorban @sbordet when you have time, we should chat about the possible performance impact of this change... it is on the main path to a Servlet and many big users have many many filters, so we need to get this right.

@gregw gregw added this to In progress in Jetty 9.4.33 via automation Sep 22, 2020
# Conflicts:
#	jetty-servlet/src/main/java/org/eclipse/jetty/servlet/FilterHolder.java
#	jetty-servlet/src/main/java/org/eclipse/jetty/servlet/ServletHandler.java
@gregw
Copy link
Contributor Author

gregw commented Oct 5, 2020

@lorban @sbordet can you find time to look at this and comment on possible performance impacts before I merge.

Previously we either build a one time filter chain class that used an iterator OR a cacheable chain that was put into both a the cache and a LRU list, so full cache could pop off single entries.

Now I build a filter chain the same way no matter what: a nested set of filter chain wrappers, that can be cached or used and discarded. This avoids creating a temporary array, but there can be more wrappers. The cache doesn't maintain an LRU and we just flush the entire cache if it fills.

@lorban
Copy link
Contributor

lorban commented Oct 5, 2020

I don't expect any perf impact from the lower-level changes, but these two higher-level changes may have some:

  • you doubled the default cache size
  • when the cache is full, it's dumped instead of trying to evict the oldest entry
    but I don't know if that could have an impact in practice.

If those two don't bother you (I assume they don't) then this LGTM.

@gregw
Copy link
Contributor Author

gregw commented Oct 5, 2020

@lorban my thinking goes that for a webapp with few unique paths, then the cost of the LRU will be wasted as the cache will never fill up.
For apps with many unique paths it is a toss up between is it cheaper to remake the cache entirely vs keep a LRU cache... and that just depends so much on the URI usage pattern.

So I thought let's make it work as best we can for the many webapps that only have a few unique URIs and then double the cache size just to capture more webapps in that category.

@gregw gregw merged commit c40b955 into jetty-9.4.x Oct 5, 2020
Jetty 9.4.33 automation moved this from In progress to Done Oct 5, 2020
@gregw gregw deleted the jetty-9.4.x-5022-FilterChainCleanup branch October 5, 2020 11:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Jetty 9.4.33
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

4 participants