Quote:
factory.close();
j'arrive toujours à récupérer mon fichier
Ca me parait normal. Une fois que le fichier est ouvert, il l'est. Fermer la fabrique est sans incidence sur ce point.
Quote:
par contre, si je mets un point d'arrêt à ce niveaux et que je ferme l'hébergeur de mon service, seules quelques boucles de relecture sont effectuées avant de remonter une erreur du type "canal de communication fermé". J'en déduis donc, à vous de me confirmer ou d'infirmer, que la mécanique interne du fonctionnement du streaming crée un canal (en gros un createChannel()) sans que je ne puisse rien y faire. Ma question est donc double, ai-je bien compris? et Comment cela fonctionne-t-il dans le détail? (appels successifs ou non, session, etc...).
Je ne sais pas si je comprends bien la question, ni même la réponse que je donne :) mais je vais quand même essayer de t'en donner une idée. (et essayer d'être clair...)
Le but du streaming, c'est d'économiser de la mémoire, c'est à dire ne pas charger en mémoire et transférer des grosses entités d'un seul coup.
Au lieu de cela, avec le streaming les données sont lues au fur et à mesure, à la demande.
Quand un fichier est streamé, deux descripteurs de fichiers sont ouverts, un de chaque côte. (serveur et client). Même avec ce procédé, je pense que le runtime travaille avec un buffer de faible taille. Cela parait normal pour éviter d'avoir trop d'accès disques. Donc côte client, quand tu lis une fois, sans doute plus de données que demandé sont placées dans un petit tampon par le runtime. Et tu peux faire quelques boucles de lectures, jusqu'à épuisement du tampon. A ce moment, le runtime veut lire dans le fichier, voit qu'il est fermé et émet le message d'erreur.
Enfin je pense que c'est comme ça.... Si quelqu'un connait mieux le sujet, qu'il ne se prive pas d'intervenir surtout :)
Ca me parait normal. Une fois que le fichier est ouvert, il l'est. Fermer la fabrique est sans incidence sur ce point.
Je ne sais pas si je comprends bien la question, ni même la réponse que je donne :) mais je vais quand même essayer de t'en donner une idée. (et essayer d'être clair...)
Le but du streaming, c'est d'économiser de la mémoire, c'est à dire ne pas charger en mémoire et transférer des grosses entités d'un seul coup.
Au lieu de cela, avec le streaming les données sont lues au fur et à mesure, à la demande.
Quand un fichier est streamé, deux descripteurs de fichiers sont ouverts, un de chaque côte. (serveur et client). Même avec ce procédé, je pense que le runtime travaille avec un buffer de faible taille. Cela parait normal pour éviter d'avoir trop d'accès disques. Donc côte client, quand tu lis une fois, sans doute plus de données que demandé sont placées dans un petit tampon par le runtime. Et tu peux faire quelques boucles de lectures, jusqu'à épuisement du tampon. A ce moment, le runtime veut lire dans le fichier, voit qu'il est fermé et émet le message d'erreur.
Enfin je pense que c'est comme ça.... Si quelqu'un connait mieux le sujet, qu'il ne se prive pas d'intervenir surtout :)