You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Lucas Nelson (JIRA)" <ji...@apache.org> on 2009/06/01 06:58:45 UTC
[jira] Created: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
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.
[jira] Updated: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "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.
[jira] Resolved: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "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 resolved WW-3143.
---------------------------------
Resolution: Fixed
Assignee: Wes Wannemacher
fixed in trunk
> 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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "Dave Newton (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "Lucas Nelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46302#action_46302 ]
Lucas Nelson commented on WW-3143:
----------------------------------
Would you please double check JakartaMultiPartRequest, I have it coming from:
struts-2.1.2/src/core/src/main/java/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.java
in my source archive, and javadoc'd here:
http://struts.apache.org/2.1.2/struts2-core/apidocs/org/apache/struts2/dispatcher/multipart/JakartaMultiPartRequest.html
> 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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "Wes Wannemacher (JIRA)" <ji...@apache.org>.
[ 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 dev@struts.a.o 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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "Dave Newton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/WW-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46303#action_46303 ]
Dave Newton commented on WW-3143:
---------------------------------
Oh, yep, there it is; I "find"ed the wrong thing.
> 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.
[jira] Commented: (WW-3143) JakartaMultiPartRequest and
FileUploadInterceptor logging at "error" level on IO and user generated
errors
Posted by "Wes Wannemacher (JIRA)" <ji...@apache.org>.
[ 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.