-
Notifications
You must be signed in to change notification settings - Fork 110
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
Do not log ClientAbortException #5072
Conversation
Translation of log messages is a bit a thing of the past. There's still the intention to remove i18n for log messages entirely. |
Is it right to be matching on |
Indeed, that would only work for Tomcat and servers using Catalina (such as GlassFish). |
Oh, I was not aware. I am indeed using TomCat, so this is how i stumbled upon this, looking for solutions. MyFaces further checks on another exception, but as I didn't know what it was I left it out, as only checking for ClientAbortException was enough to fix it for me.
Should I also check for this? I have also created an eclipse account now and signed the contribution agreements. That check should pass now. |
If this is a common occurrence and there is no action that can be taken by the server then why not just send the 404 and skip the log?
Not seeing the value of the log. |
c2b1393
to
fb2a951
Compare
fb2a951
to
ad33ec0
Compare
I still don't think matching for @arjantijms what are your thoughts? |
Not super happy about having product specific things in Mojarra. I have to admit that for customers we have been catching these same exceptions too in proprietary code, so I do understand the wish. Maybe a better course of action is to standardise this exception in Servlet? |
in the meantime it could be merged with a comment maybe this OmniFaces utility is related and could be ported / adapted ? https://showcase.omnifaces.org/exceptionhandlers/ExceptionSuppressor The docs suggests that these 2 exceptions are also good candidates to be ignored:
|
I think you should check the same way MyFaces does for both exceptions... private static boolean isConnectionAbort(IOException e)
{
return e.getClass().getCanonicalName().equals("org.apache.catalina.connector.ClientAbortException")
|| e.getClass().getCanonicalName().equals("org.eclipse.jetty.io.EofException");
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment
How about employ what is illustrated in the ExceptionHandler JavaDoc
|
Whatever we decide i would like to make sure MyFaces does the same thing as Mojarra. |
I have for now stuck to the way I did it initially. Added the check for Eof and added the comment about servlet. |
I do not favor this approach. @arjantijms What do you think about the code snippet I pasted above? Would that not be a more reasonable approach? Note that binding yourself to a specific underlying runtime if it can be avoided it should! |
Agree @mnriem a non specific solution would be great and then we can Migrate whatever we come up with to MyFaces. Cc @tandraschko |
Regarding
If I understand correctly, according to the docs:
With either approach, any Looking into the default ExceptionHandler does it not just log the error on level Severe again? |
yeah |
What is the current status of this PR? I would like to see this move forward, as my logs are still unneccesarily cluttered. |
I am all for it. |
If needed we can expand the section of well known client abort exceptions. If anyone wants to push for this being standardised, that would be even better. |
…e was a fix in 2.3.18 that addresses this undesirable log message (eclipse-ee4j/mojarra#5072)
…e was a fix in 2.3.18 that addresses this undesirable log message (eclipse-ee4j/mojarra#5072) (#11054)
…e was a fix in 2.3.18 that addresses this undesirable log message (eclipse-ee4j/mojarra#5072) (#11054) (cherry picked from commit d83c384)
…e was a fix in 2.3.18 that addresses this undesirable log message (eclipse-ee4j/mojarra#5072) (#11054) (cherry picked from commit d83c384)
Description
This is a horribly flaky issue and usually only happens when using in Firefox.
Reproducing this consistently is next to impossible.
The issue has been listed multiple times for Mojarra already, namely #547 and #4280
This occurs due to Firefox's behaviour, when sending requests for resources, but canceling/dropping the connection midway through, because the cache was faster. There are 4 possible behaviours as described on the Mozilla support-page. Of the 4 cases, the ClientAbortException only happens in case 4.
Current Behaviour
The ClientAbortConnection is logged as IOException in the method call to
send404(context, resourceName, libraryName, ioe, true);
It is logged on level
Warning
and prints the whole stacktrace into the log.This Change
The ClientAbortException is no longer logged, as there is no action that can be taken by the server.
Further Details / Questions
send404
?