Apache Commons Téléchargement de Fichier de Flux est terminé de façon inattendue

Eh bien, je dois dire que jusqu'à présent, cela m'a déconcerté. Notre application web, qui est en cours d'exécution dans Tomcat 6.0.18 est de ne pas en cours d'upload de fichier, mais uniquement lorsque le client de la machine est une machine windows, uniquement pour certaines machines, et pour tous les navigateurs, et pas seulement IE.

Il y a une trace de la pile dans les journaux, ce qui semble indiquer que le client soit mis fin à la connexion, ou le flux a été quelque peu endommagé. La cause racine dans la trace de la pile est donnée comme suit:

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

Le code qui provoque la trace a l'air assez simple.

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 ligne ce qui nous donne de la peine est celle-ci:

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

Qui, pour une raison quelconque, c'est de décider que les flux de certains ordinateurs Windows sont en quelque sorte corrompu.

Je pense avoir trouvé quelque chose qui peuvent être liés sur StackOverflow. Il semble suggérer qu'il y a certains bug dans Tomcat 6, qui a été corrigé dans la version 6.0.20, un peu plus récente que celle que nous utilisons. Malheureusement, il ne parle pas de ce que la question elle-même a été. J'ai eu un coup d'oeil à l'Tomcat changelog, mais ne peuvent pas voir les candidats probables pour un bogue qui pourrait causer ce problème.

De toute façon, à ma question, quelqu'un a rencontré un problème similaire, et si oui, quel était le problème sous-jacent et comment l'avez-vous résolu?

Je vous remercie d'avance pour toutes les réponses.

EDIT: Cela semble être une sorte de problème avec l'équilibrage de la charge du serveur Tomcat. Si vous ignorez l'équilibrage de charge et l'accès Tomcat directement via l'adresse IP du serveur, le problème disparaît. La chose étrange est que cela apparaît à la fois notre mise en scène de l'environnement, dans lequel nous utilisons Apache/AJP1.3, et de vivre, où l'on Zeus.

EDIT3: Ce qui s'est avéré être un problème avec les clients pare-feu. Il semble qu'elles étaient.. er.. pas toute la vérité quand ils ont dit que le savaient certainement ce n'était pas un problème de Firewall.

OriginalL'auteur Jon | 2010-07-16