阿帕奇共享文件上传 - 流意外结束 [英] Apache Commons File Upload - Stream ended unexpectedly
问题描述
好吧，我不得不说，到目前为止，这其中有我难住了。我们的Web应用程序，这是在Tomcat中6.0.18运行的文件上传过程中失败，而是只有当客户机的Windows机器上，只对一些机器，并为所有的浏览器，而不是IE浏览器的。
Well, I have to say that so far, this one has me stumped. Our web application, which is running in Tomcat 6.0.18 is failing during file upload, but only when the client machine is a windows machine, only for some machines, and for all browsers, not just IE.
有在日志中的堆栈跟踪，这似乎表明，无论是客户端关闭了连接，或者该流在某种程度上破坏。在堆栈跟踪的根本原因给出如下：
There is a stack trace in the logs, which seems to indicate that the client either closed the connection, or the stream was somehow corrupted. The root cause in the stack trace is given as follows:
Caused by: org.apache.commons.fileupload.MultipartStream$MalformedStreamException: Stream ended unexpectedly
at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:983)
at org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
at java.io.InputStream.read(InputStream.java:85)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
... 70 more
在code这将导致跟踪看起来相当直截了当。
The code which causes the trace looks fairly straight forward.
private Map<String, Object> getMap( ActionRequest request ) {
HashMap<String, Object> parameters = new HashMap<String, Object>();
if ( request == null ) {
return parameters;
}
if ( request.getContentType() == null ) {
return parameters;
}
try {
if(PortletFileUpload.isMultipartContent(request)){
DiskFileItemFactory factory = new DiskFileItemFactory();
PortletFileUpload upload = new PortletFileUpload(factory);
List<DiskFileItem> fileItems = upload.parseRequest(request);
for( DiskFileItem fileItem : fileItems ) {
String name = fileItem.getFieldName();
//now set appropriate variable, populate hashtable
if( fileItem.isFormField() ) {
String value = fileItem.getString( request.getCharacterEncoding() );
if( parameters.get( name ) == null ) {
String[] values = new String[1];
values[0] = value;
parameters.put( name, values );
} else {
Object prevobj = parameters.get( name );
if( prevobj instanceof String[] ) {
String[] prev = ( String[] ) prevobj;
String[] newStr = new String[prev.length + 1];
System.arraycopy(
prev, 0, newStr, 0,
prev.length
);
newStr[prev.length] = value;
parameters.put( name, newStr );
} else {
//now what? I think this breaks the standard.
throw new EatMyHatException(
"file and input field with same name?"
);
}
}
} else {
// Yes, we don't return FileParameter[] for multiple files of same name. AFAIK, that's not allowed.
FileParameter fp = new FileParameter( fileItem );
parameters.put( name, fp );
files.add( fp );
}
}
} else {
// Not multipart
return toObjectMap(request.getParameterMap());
}
} catch (FileUploadException e) {
throw new RuntimeException(e);
} catch (UnsupportedEncodingException e) {
throw new RuntimeException(e);
}
return parameters;
}
这是给我们的悲痛线这是其一：
The line which is giving us the grief is this one:
List<DiskFileItem> fileItems = upload.parseRequest(request);
由于某种原因被决定，从一些Windows机器流都是以某种方式损坏。
Which for some reason is deciding that streams from some Windows machines are in some way corrupted.
我想我已经找到了<一个href=\"http://stackoverflow.com/questions/1586843/apache-commons-fileupload-tomcat-cant-cope-with-out-flush\">that可在StackOverflow的相关。这似乎表明有在Tomcat中6的一些bug而固定在6.0.20版本，略高版本比我们使用的人。遗憾的是它并没有提什么问题本身。我已曾在Tomcat的更新日志一看，但看不到任何可能的候选人这可能导致此问题的错误。
I think I have found something that may be related on StackOverflow. It seems to suggest there is some bug in Tomcat 6 which was fixed in version 6.0.20, a slightly higher version than the one we're using. Unfortunately it doesn't mention what the issue itself was. I've had a look at the Tomcat changelog, but can't see any likely candidates for a bug which could cause this problem.
反正到我的实际问题，有没有人遇到过类似的问题，如果是这样，什么是根本问题，你是怎么解决的？
Anyway, on to my actual question, has anyone encountered a similar problem, and if so, what was the underlying issue and how did you resolve it?
感谢您事先的任何答复。
Thank you in advance for any responses.
编辑：这似乎是某种具有负载平衡和Tomcat的问题。如果您绕过负载均衡器，并通过服务器的IP地址直接访问Tomcat中，问题消失。奇怪的是，这出现在了我们的临时环境，在此我们使用Apache / AJP1.3，和生活，在这里我们使用宙斯。
This appears to be some kind of problem with load balancing and Tomcat. If you bypass the load balancer and access Tomcat directly via the server IP address, the problem goes away. The strange thing is that this appears in both our staging environment, in which we use Apache/AJP1.3, and live, where we use Zeus.
EDIT3：事实证明，这是与防火墙客户端的问题。看来他们是..呃..不是完全真实的，当他们说，知道这绝对不是一个防火墙问题。
This turned out to be an issue with the clients firewall. It appears that they were.. er.. not being entirely truthful when they said that the knew definitely this was not a Firewall issue.
推荐答案
可能是你需要的tcpdump / Wireshark的坏，右上传，然后比较它们？
May be you need tcpdump/wireshark bad and right uploads, and then compare them?
这篇关于阿帕奇共享文件上传 - 流意外结束的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
