J'essaie de lire un fichier texte CSV à partir de S3, puis envoyez chacune de ses lignes à une file d'attente distribuée pour les faire traiter.
Lorsque vous essayez de le lire, je reçois "java.net.socketException: socket est fermé" Exception à différents points du fichier en cours de lecture (dans différentes exécutions). Ceci est le code: aucune idée sur la manière de résoudre ce problème? mise à jour: Cette exception se produit de la Deuxième fois que j'exécute la méthode, si j'arrête tout le programme et que je l'exécute à nouveau, la première fois que j'exécute la méthode, cela fonctionne correctement.
6 Réponses :
Fermer le flux d'entrée ou le flux de sortie d'une prise ou de tout emballage de flux / lecteur / écrivain autour d'eux, ferme la prise (et donc le flux de sortie ou d'entrée respectivement).
Mais aucun flux / lecteur / écrivain n'est fermé pendant l'exécution de la boucle.
@Fgblanch Il est fermé après l'exécution de la boucle, avant l'appel suivant à la méthode. Et / ou vous fermez la prise, ou un de ses ruisseaux, ailleurs.
Peut-être que vous devriez fermer des lecteurs3 dans votre enfin au lieu de "dans". C'est à dire. Fermez l'objet le plus externe, qui peut fermer ses enfants enveloppés.
Si vous fermez d'abord 'In' en premier, l'entréeStreamReader et la bufferedreader sont toujours ouvertes et s'ils essaient de faire quoi que ce soit avec l'objet qu'ils enveloppent, il sera déjà fermé.
Comme suggéré par "JSN" dans les commentaires à la question, le problème est que vous devez configurer amazons3 avec ClientConfiguration :
Quels sont les maladies d'un délai d'attente infini?
Merci, @jsn, votre suggestion était mon problème.
J'ai une méthode qui renvoie juste l'intrustream afin que l'objet Amazons3 obtienne des ordures recueillies et que cela ferme la fermeture de l'introuvream.
J'ai fait que cela garde une référence à l'objet Amazons3 et qui corrige mon problème.
Pourriez-vous donner un exemple comment garder une référence?
Faites une variable de classe comme celle-ci et définissez-la finale privée Amazons3 S3; .
Pas besoin de continuer à réinitialiser S3.
sur votre Oncreate Faites appel à l'initialisation de S3Object et S3Client.
Puis dans votre masque d'asyncaptage, utilisez simplement l'appel
En faisant ainsi que votre S3Client conservera les mêmes données et ne fermez jamais la connexion à la prise avec S3 lorsque vous en faites le moment. Soyez intelligent et apprenez.
J'ai eu le même problème et ce sujet m'a aidé à résoudre le problème: S3 Java Client échoue beaucoup avec" Fin de la longueur prématurée du corps de message délimité de la longueur de contenu "ou" Java.net.SocketException Fermé "
essentiellement Je créais un nouvel objet S3Client pour chaque fichiers, mais à un moment donné, cet objet était recueilli. Donc, au lieu de faire que j'ai transformé ma classe pour utiliser un singleton:
Non, mais c'est à l'intérieur d'une classe d'action de jambes de force
Essayez d'exécuter cela tout en conservant des références explicites à tous ces objets (si elle est utilisée et que cela n'a pas déjà été essayé):
S3Client ,S3Object etamazonons3client . Il peut y avoir un problème avec GC ramassant des objets et des connexions de fermeture.Tous ces objets sont dans la même portée tout en fonctionnant afin que ce soit des références devraient être manifestées correctement? Qu'en est-il de séparer son exécution à un fil différent?
Je veux aussi, assurez-vous également de ne pas faire quelque chose comme ceci: nouveau
conn c = Amazons3ClientInstance.geconn () . Dans ce cas, comme vous le savez peut-être,AmazonS3ClientInstance peut être ramassé par GC (oùAmazons3ClientInstance est de typeAmazonS3Client ). Serait utile pour poster du code complet, si possible.Aucune Amazone3, S3Object n'est pas modifiée. Je mettez à jour le code
Quelle est la taille du fichier? Peut-être que vous devrez peut-être changer le délai d'attente de socket (peut-être 0? -> infini)?
http://docs.amazonwebservices.com/awsjavasdk/latest/javadoc/ COM / Amazonaws / Configuration du client.HTML # G ETSOCKETTIMOUT ()Mauvaise URL (ne peut pas modifier le commentaire), bonne URL -> tinyurl.com/d75xffa
Je vais essayer, bien que le fichier soit seulement 10 m et que la prise étant fermée arrive parfois lorsque seulement 20 lignes sont en lecture
@jsn il n'a rien à voir avec (a) multithreading, (b) la collecte des ordures, (c) la taille du fichier, ou (d) chance. La seule phrase pertinente ici est «dans différentes exécutions».
@jsn La seule variable ici qui ne semble pas être locale est "IN", le flux d'entrée de la prise. Les variables locales sont soumises à ni gc ni multithreading, et les flux locaux enveloppés autour du flux d'entrée de socket conservent ce dernier et sa prise de GC. Les problèmes de réseau se manifestent comme des exceptions ou des blocs infinis. La taille du fichier n'affecte pas ce code, car il ne la lit pas dans la mémoire. Il n'y a pas grand-chose à gauche, sauf une prématurée de ce code même ou d'un autre code.
@jsn Augmentation du délai d'attente de socket ne résout pas le problème. C'est vraiment étrange car une fois la compilation du projet fonctionne, les suivants ne le font pas
Local Variables n'est pas soumis à GC. Les objets qu'ils indiquent sont. Vous fermez prématurément le socket quelque part. Ceci est un bogue dans votre code, pas un problème de serveur ou de réseau.
@jsn Changer le délai de lecture ne résoudra pas ce problème. Vous semblez simplement deviner.