Discussion :

[yotta]

Bonsoir,
J’essai d’écrire une routine dont l’objectif est de récupérer une image au format Jpeg à travers une URL de type http. Pour cela, j’exploite la méthode « openStream() » de la classe java.net.URL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

InputStream fluxIn = new URL(“http://.....truc.jpg”).openStream();

Ensuite, j’exploite la méthode « write(RenderedImage in, String formatName, OutputStream output) » de la classe javax.imageio.ImageIO :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
FileOutputStream OUT = new FileOutputStream(“chemin_fichier_de_sortie.jpg”);
ImageIO.write(ImageIO.read(fluxIn), "jpg", OUT);

J’ai fait plusieurs essais pour remarquer deux cas de figures particuliers. Le premier cas se produit lorsque la méthode « ImageIO.read(fluxIn) » renvoie null. Cela peut être du à une coupure de la connexion, ou une déconnexion du serveur. Dans ce cas, pas de problème puisqu’une exception est levée au niveau de ImageIO.write. Mais il y a un second cas, lorsqu’il n’y a pas de fermeture de connexion, mais qu’aucune donnée n’arrive ?! Dans ce cas, mon code bloque, et tant que la connexion n’est pas fermée par le tiers, alors mon code reste bloqué… Il me faut donc trouver un moyen de sortir de ce blocage lorsque ce cas se produit.
J’ai essayé de voir au niveau ImageIO un rapport avec une notion de timeout, mais je n’ai rien trouvé. Donc, je me suis dit que je n’avais pas d’autre choix que de surveiller le fichier de sortie pour remarquer que dans ce cas, un joli fichier jpeg vide, de taille nulle est créé. Donc, j’ai trouvé un moyen de surveiller la taille de ce fichier pendant qu’il se télécharge. Mon mécanisme est simple, je crée un Thread à partir d’une de mes classes qui implémente Runnable en fournissant à ce dernier le flux d’entrée, le flux de sortie et une référence de traitement sous forme de String. Ce Thread a pour rôle de remarquer l’absence d’évolution du fichier de sortie pendant un certain temps. Il est exécuté juste avant la méthode write de ImageIO.
Ce mécanisme fonctionne, mais je ne trouve pour autant aucun moyen de sortir de la méthode ImageIO.write(ImageIO.read(fluxIn), « jpg », OUT) … C’est pourquoi j’ai passé fluxIn à mon Thread, je me suis dit qu’en invoquant sa méthode reset, ou close j’arriverai à lever une exception auprès d’ImageIO, mais il n’en est rien ?!
Bref, je sèche complètement… Si quelqu’un a une idée pour débloquer cette situation, cela m’aiderai beaucoup.
Merci à vous.

[joel.drigo]

Salut,

Au lieu de charger l'image en mémoire et de la resauvegarder, ce qui consomme temps et mémoire pour rien, charges/écris plutôt le flux directement (par InputStream/OutputStream), ce qui te permettra de gérer ton problème par la notion de timeout en plus.

[yotta]

Merci pour votre réponse joel.drigo.
Effectivement, je n'avais regardé cela d'assez près, mais ImageIO.read renvoie un BufferedImage, donc éffectivement, je charge la mémoire pour rien... Bien vu
J'en ai profité pour regarder s'il existait une déclinaison de cette méthode qui me permettrait déviter cela, mais elles renvoient toutes la même chose, un BufferedImage.
Dommage, lorsque j'ai découvert cette méthode, de prime abord, elle correspondait exactement à ce que je voulais et me permettait de minimiser au maximum les lignes de codes (je suis de nature fainéant)...
Bref, si je comprends bien, ce que j'utilise est plutôt à utiliser pour de la visualisation que de la copie de fichier.
Je voulais l'éviter, mais je vais suivre votre conseil et gérer le flux moi-même dans l'immédiat, ça m'apprendra à être trop fainéant parfois.
Cependant, les images que je vais télécharger ainsi sont de petites tailles (800x800 en 72dpi pour les plus grandes au format Jpeg), et la machine qui va le faire a beaucoup de mémoire, donc je peux me permettre ce "gaspillage volontaire".
Donc, je me permet de maintenir mon post ouvert pour la cas où quelqu'un saurait me dire s'il est possible de sortir de cette situation bloquante, et comment...

[yotta]

Bonsoir,
J'ai modifié mon code et abandonné ImageIO. Je n'utilise plus qu'un flux d'entrée de type InputStream, et un flux de sortie FileOutputStream. Je n'utilise plus la méthode openStream() de URL, mais la méthode openConnection() afin de récupérer un URLConnection. Je règle le timeout pour la lecture via la méthode setReadTimeout(500), si je ne me trompes pas, cela fait une demie seconde.
Voilà le code que ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    private boolean ecritureFichierREV2(URLConnection url, FileOutputStream OUT, String ref) {
        boolean reponse;
        try {
            InputStream fluxIn = url.getInputStream();
            System.out.println("Valeur du ReadTimeOut : " + url.getReadTimeout());  // Un setTimeout(500) a été fait dans le code appelant lors de la construction de url.
            while (fluxIn.available() != 0) OUT.write(fluxIn.read());
            OUT.flush();
            OUT.close();
            reponse = true;
            }
        catch (IOException e) {
            reponse = false;
            }
        return reponse;
        }

Et bien, ça fonctionne exactement de la même manière. Cela va évidemment plus vite, et consomme significativement moins de mémoire, mais ça bloque exactement de la même manière ?!...
Le cas qui me préoccupe c'est lorsque la connexion est établie et active, fluxIn.read() est exécuté, et le Socket sous-jacent se met à attendre des données sur son port, mais rien ne vient. Le code lui aussi attend...
Je pensais qu'avec le préparation apportée à mon instance de URLConnection lèverait une java.net.SocketTimeoutException, mais ce n'est pas le cas ???....

Si quelqu'un a une idée ?

[yotta]

Je suis vraiment désolé, mais je suis un âne.
Il n'y a en fait aucun problème si ce n'est une mauvaise gestion de flux de ma part. Au mieux, ce post n'est pas dans le bon forum.
Quoi qu'il en soit, avec le conseil donné, et un test de contrôle de flux adapté, tout fonctionne à merveille.