問題描述

嗯，我不得不說，到目前為止，這個讓我很難過.我們在 Tomcat 6.0.18 中運行的 Web 應(yīng)用程序在文件上傳期間失敗，但僅當(dāng)客戶端機器是 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.

日志中有一個堆棧跟蹤，這似乎表明客戶端關(guān)閉了連接，或者流以某種方式損壞.堆棧跟蹤中的根本原因如下:

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

導(dǎo)致跟蹤的代碼看起來相當(dāng)簡單.

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.

我想我找到了一些可能相關(guān)的/a> 在 StackOverflow 上.似乎表明 Tomcat 6 中存在一些錯誤，該錯誤已在版本 6.0.20 中得到修復(fù)，比我們使用的版本略高.不幸的是，它沒有提到問題本身是什么.我已經(jīng)看過 Tomcat 變更日志，但不能看不到任何可能導(dǎo)致此問題的錯誤的候選對象.

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.

無論如何，關(guān)于我的實際問題，有沒有人遇到過類似的問題，如果有，根本問題是什么以及您是如何解決的?

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?

提前感謝您的任何回復(fù).

Thank you in advance for any responses.

這似乎是負(fù)載平衡和 Tomcat 的某種問題.如果您繞過負(fù)載均衡器并直接通過服務(wù)器 IP 地址訪問 Tomcat，問題就會消失.奇怪的是，這出現(xiàn)在我們使用 Apache/AJP1.3 的暫存環(huán)境和我們使用 Zeus 的生活環(huán)境中.

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.

這原來是客戶端防火墻的問題.當(dāng)他們說他們肯定知道這不是防火墻問題時，他們似乎.. er.. 并不完全真實.

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?

這篇關(guān)于Apache Commons 文件上傳 - 流意外結(jié)束的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！