struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Newton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (WW-3143) JakartaMultiPartRequest and FileUploadInterceptor logging at "error" level on IO and user generated errors
Date Tue, 02 Jun 2009 14:24:42 GMT

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

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

Nope, don't really care, although I think if there's an invalid request that's a genuine error
(261/263/311 in 2.1.2) and indicates something has gone quite wrong.

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


Mime
View raw message