[jira] Updated: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at "error" level on IO and user generated errors

["Wes Wannemacher (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wes Wannemacher updated WW-3143:
--------------------------------

    Fix Version/s: 2.1.7

might as well try to squeeze this in

> JakartaMultiPartRequest and FileUploadInterceptor logging at "error" level on IO and user generated errors
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: WW-3143
>                 URL: https://issues.apache.org/struts/browse/WW-3143
>             Project: Struts 2
>          Issue Type: Bug
>    Affects Versions: 2.1.2
>         Environment: Tomcat 6.0.18
>            Reporter: Lucas Nelson
>             Fix For: 2.1.7
>
>
> Having just gone live using the multi-part forms and the FileUploadInterceptor, we are getting noise in the logs coming from I/O errors (eg. read timed out) and user generated errors (eg. file too large). We have a production system where we alert on severe errors (error at fatal on your Logger class). As a short-term measure, we've had to disable the log messages from JakartaMultiPartRequest and FileUploadInterceptor, which is not ideal.
> Would you please consider lowering the log level to at least warning, but preferably lower for:
> (these line numbers are from 2.1.2)
> JakartaMultiPartRequest:138 - logs the exception raised from org.apache.commons.fileupload.FileUploadBase#parseRequest, eg. read timeout
> FileUploadInterceptor:228 - logs each of the previous exception messages that may have occurred.
> FileUploadInterceptor:261 - would seem to require an invalid HTTP request, was not able to trigger from a browser
> FileUploadInterceptor:263 - would seem to require an invalid HTTP request, was not able to trigger from a browser
> FileUploadInterceptor:311 - missing file, would seem to require an invalid request
> FileUploadInterceptor:318 - file is over the size limit
> FileUploadInterceptor:325 - file is not one of the permitted content types
> Having those cases create an error for the user is entirely appropriate. Having them log to the application logs is a pain in the butt for a highly loaded production system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.