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

["Dave Newton (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46298#action_46298 ] 

Dave Newton commented on WW-3143:
---------------------------------

We won't change the error logging levels for non-Struts projects--you'd need to file an issue with them (we're not responsible for commons fileupload; don't recall where JakartaMultiPartRequest comes from, but it's not Struts).

261/263/311 seem like real errors to me, which your comment seems to back up.

I don't see any issue w/ 318/325, but will wait to see if anybody else does.

Not sure why 228 is at error level; someone else may have a better handle on that one.

> 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
>
> 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.