2010-07-16 11 views
5

Bene, devo dire che finora, questo mi ha bloccato. La nostra applicazione web, che è in esecuzione in Tomcat 6.0.18, non funziona durante il caricamento dei file, ma solo quando il computer client è una macchina Windows, solo per alcune macchine e per tutti i browser, non solo IE.Caricamento file di Commons Apache - Stream terminato in modo imprevisto

C'è una traccia dello stack nei registri, che sembra indicare che il client ha chiuso la connessione o che lo stream è stato in qualche modo danneggiato. La causa principale nella traccia dello stack è data come segue:

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 

Il codice che causa la traccia sembra abbastanza semplice.

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; 
} 

La linea che ci sta dando il dolore è questa:

List<DiskFileItem> fileItems = upload.parseRequest(request); 

che per qualche motivo è decidere che i flussi da alcune macchine Windows sono in qualche modo danneggiato.

Penso di aver trovato qualcosa that may be related su StackOverflow. Sembra suggerire che ci sia qualche bug in Tomcat 6 che è stato risolto nella versione 6.0.20, una versione leggermente più alta di quella che stiamo usando. Sfortunatamente non menziona quale fosse il problema stesso. Ho had a look al log delle modifiche di Tomcat, ma non vedo alcun candidato probabile per un bug che potrebbe causare questo problema.

In ogni caso, alla mia domanda attuale, qualcuno ha riscontrato un problema simile e, in tal caso, qual era il problema di fondo e come lo hai risolto?

Grazie in anticipo per eventuali risposte.

EDIT: Questo sembra essere un qualche tipo di problema con il bilanciamento del carico e Tomcat. Se si ignora il bilanciamento del carico e si accede a Tomcat direttamente tramite l'indirizzo IP del server, il problema scompare. La cosa strana è che questo appare in entrambi i nostri ambienti di staging, in cui usiamo Apache/AJP1.3, e live, dove usiamo Zeus.

EDIT3: si è verificato un problema con il firewall dei client. Sembra che loro stessero .. ehm ... non essendo del tutto sinceri quando hanno detto che sapevano sicuramente che questo non era un problema del Firewall.

+0

Sarebbe disposto a specificare quale fosse esattamente il problema in una risposta a questa domanda? – MattC

+0

Matt, mi dispiace, ma non so esattamente quale fosse il problema del firewall. Siamo stati semplicemente contattati dal cliente post-Firewall-fix e abbiamo informato che si trattava di un problema del firewall. – Jon

risposta

1

Potrebbe essere necessario caricare e caricare correttamente tcpdump/wireshark e quindi confrontarli?

+0

Sì, l'abbiamo provato con Wireshark, che a dire il vero ho poca esperienza di interpretazione. Era reso più difficile dal fatto che il problema era intermittente e difficile da riprodurre. In ogni caso, si è rivelato essere il firewall. – Jon

Problemi correlati