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.
Sarebbe disposto a specificare quale fosse esattamente il problema in una risposta a questa domanda? – MattC
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