2009-04-01 11 views
0

J'ai une application client et serveur qui transfère le message en utilisant la sérialisation sur TCP. J'ai l'erreur suivante lors de la désérialisation d'un objet:Java StreamCorruptedException

Des idées à la cause ou les prochaines étapes possibles dans l'analyse de ce problème?

java.io.StreamCorruptedException: invalid stream header: 383D4649 
    at java.io.ObjectInputStream.readStreamHeader(Unknown Source) 
    at java.io.ObjectInputStream.<init>(Unknown Source) 
    at com.aqua.NmsApi.ResiliantTCPServer$ServerThread.run(ResiliantTCPServer.java:248) 
    at java.lang.Thread.run(Unknown Source) 

Répondre

1

Il y a un problème avec le nombre magique en tête des données sérialisées. Vous aurez probablement besoin de capturer les données sérialisées et de le regarder par vous-même pour commencer. Ce flux ASCII est '8 = FI'.

+0

ce sont des journaux distants du processus serveur. l'utilisateur a redémarré le serveur et il a commencé à fonctionner. mais j'analyse toujours la cause. – richs

+0

Ce n'est pas trop improbable alors qu'il y avait un problème de communication transitoire. Vous devez ajouter la gestion des exceptions autour de l'emplacement d'exception d'origine, voir si vous pouvez capturer plus de données. –

1

Il y a deux raisons possibles pour cela:

  • Le flux a été effectivement corrompu (à savoir ce que vous lisez est différent de ce que vous avez écrit à l'autre bout). Dans ce cas, vous devez écrire dans un fichier local chaque contenu (émis et reçu), et les comparer. Les nombres magiques requis par la ou les implémentations de ObjectInputStream que vous utilisez sont différents à chaque extrémité, par exemple parce que vous utilisez des versions différentes des paquets de base Java. Ces constantes sont déclarées dans ObjectStreamConstants, vous devez les vérifier.

0

utilisez-vous exactement un ObjectInput/OutputStream par socket Input/OutputStream? recréer ces sur le même flux d'entrée/sortie est une cause commune d'une telle erreur.