[
https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46317#action_46317
]
Wes Wannemacher commented on WW-3143:
-------------------------------------
You can change it back if you want. I just see those sorts of errors as
something I can't do anything with (from a Struts perspective). It is sort of
like when we throw exceptions for 404s. I like 'em when I'm working on the app,
but out in the wild, there is really nothing I am going to do if I see one once
in a while. Maybe I could check for dev mode and make them errors in dev mode
and otherwise warn. Would that be better?
> 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
> Assignee: Wes Wannemacher
> 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.
