[MAGNOLIA-3566] Cache filter should ignore ClientAbortException Created: 24/Feb/11 Updated: 13/Jun/13 Resolved: 27/Mar/13 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | cache |
| Affects Version/s: | 4.3.8, 4.4.2 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major |
| Reporter: | Danilo Ghirardelli | Assignee: | Ondrej Chytil |
| Resolution: | Not an issue | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||
| Patch included: |
Yes
|
||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||
| Description |
|
I don't know if I'm the only one, but the cache module catches and logs this exception: java.lang.RuntimeException: ClientAbortException: java.net.SocketException: Connection reset It's a quite common exception, that in most cases means the browser has closed the connection. Ok, there are a few cases in which this may be useful to trace borderline problems with https and internet explorer, but I'd really like to have something to turn this off completely instead of having something harmless cluttering log file at error level... |
| Comments |
| Comment by Danilo Ghirardelli [ 10/Mar/11 ] |
|
ClientAbortException is a Tomcat-specific exception, but I suppose each application server has its own for the same reason. I solved my problem replacing the cacheFilter class with a simple class that extends the original cacheFilter and does just this: public void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { try { super.doFilter(request, response, chain); } catch (RuntimeException e) { Throwable wrappedEx = ExceptionUtils.getCause(e); if (!((wrappedEx != null) && (StringUtils.equalsIgnoreCase(wrappedEx.getClass().getName(), "org.apache.catalina.connector.ClientAbortException")))) { // Propagate ONLY if it's not a client abort. throw e; } // Otherwise just ignore it. } } |
| Comment by Danilo Ghirardelli [ 10/Mar/11 ] |
|
I started thinking that in the filter chain there are a few point where a pluggable exception handler may be really useful. This and also rendering filter, just to name two. It may be just a class stated in the configuration node, maybe it's worth even defining the exception handler on the abstract filter and overriding it where needed. |
| Comment by Philipp Bärfuss [ 11/Mar/11 ] |
|
Thanks, especially for the code snipped. |
| Comment by Ondrej Chytil [ 27/Mar/13 ] |
|
Cannot reproduce the issue with current 4.4 and 4.5 snapshots. |
| Comment by Danilo Ghirardelli [ 27/Mar/13 ] |
|
Locally is almost impossible, you need real load to reproduce this.
The "problem" happens when a user closes it browser while the the server is streaming the response. In a local machine this is istantaneous, you need to simulate a little delay to have the time to stop the request. The "exception" generated is nothing bad, because the user already left, the point is just avoiding this in the log. And it is still perfectly reproducible on 4.4 (didn't try on 4.5). |
| Comment by Ondrej Chytil [ 27/Mar/13 ] |
|
Hi Danilo, my test case was big file in DMS workspace accessed from command line (curl), stopped in the middle of the request. While on 4.4.2 I got the exception, on 4.4.11-SNAPSHOT and 4.5.9-SNAPSHOT I was unable to do so.
Which version did you use? |
| Comment by Danilo Ghirardelli [ 29/Mar/13 ] |
|
Magnolia 4.4.8 on Tomcat 6.0.24 (which is not the last version), locally on a windows system (and in production on a linux system). Maybe the problem is more linked to Tomcat version/installation than to the filter itself. Anyway, more than the single patch for Tomcat (or other application servers), my real issue was about having a way to handle exceptions in the filter chain to fix cases like this... |
| Comment by Magnolia International [ 13/Jun/13 ] |
|
ochytil the issue still exists. The reason you didn't see it with a large file is because those go a different route (with DelegatingBlobCachedEntry) and never get cached. If you do it with a resource that's cached, thus served with UseCache, you'll see the fix. Fixed it in 4.5.x and 5.0 with |