[
https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46310#action_46310
]
Wes Wannemacher commented on WW-3143:
-------------------------------------
Dave, I agree with the OP on this one. I think we should reserve LOG.error for
things that are errors happening within the framework. These errors are results
of bad uploads. I see an error as something that someone needs to fix, in this
case, you can't stop users from trying to upload bad data (too big, wrong type,
bad requests altogether). Since there really isn't any action a sys admin or
developer can take (other than blocking an offender's IP or some other security
measure) then we should leave these as a warning. I'm going to go ahead and
make the change and commit. If you don't want it this way, chime in or start a
thread on [email protected] there will be plenty of time before I try to release
it.
> 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.
