Bonjour,
 
je voudrais savoir est-il possible de créer et envoyer un fichier par FTP sans pour autant le créer en local (cad sans pour autant le créer sur le serveur et aprés l'envoyer par FTP).
 
Merci.

ben t'envoies un flux, oui c'est possible, mais faut bien lire les données de quelque part

en fait j'ai un webservice qui m'envoie les données aprés moi je les crées dans un fichier et je l'envoie par FTP

data over xml over http over ftp ?
 
'fin bon, c'est jouable, mais faut voir la tronche de la lib que tu utilises. Si l'interface se limite à l'envoi d'un fichier sans possibilité de passer un stream quelconque, ça le fera moins.

j'ai la berlue moi.
au début, j'avais mal lu "java", mais "pda" à la place (allez savoir pkoi).
 
du coup là ça commençait à devenir chelou le coup du pda qui cherche une donnée par webservice puis la pose sur un autre serveur via ftp... d'autant plus que le pda était appelé "serveur".
 
pfiou ! il est temps que je prenne des vacances moi

@MagicBuzz: excuses, je me suis trompé au début et j'avais mis PDA mais j'ai corrigé.
 
@sicram: pour le moment mon appli crée le fichier en local et l'envoie par FTP, mais je voudrais éviter de le créer sur le serveur de prod et envoyer le flux directement mais à ce qu'il parait c ça doit etre chaud c'est ça?

Ah oui, si c'est du java et si c'est lourd, c'est tout de suite moins chelou

ah, j'avais donc pas rêvé
ceci dit, c'est plus logique maintenant
bon, je me sauve de ce topic, je sais pas faire de java
 
 
sinon, à la base, j'imagine que les librairies Java permettent d'envoyer un flux binaire via FTP. la source peut donc être un flux de fichier, ou même directement un flux mémoire que tu allimentes avec les méthodes de ton webservice.
 
(enfin, je fait des plans sur la comète, c'est du moins ce qu'on fait en C# qui est assez similaire)

tume conseilles quoi, je reste sur mon truc et je tente l'envoi direct sans passer par une création de fichier en local?

Buzz> Oui, ça doit être idem en "Java", mais ça dépend en réalité de la librairie. Faut lire le fine manual, la doc, quoi
 
Ca n'a rien de chaud ou de gore : la lib le permet ou ne le permets pas. Il n'y aura peut-être pas de place (ni d'intérêt) pour une situation intermédiaire.

ça dépends surtout de la taille de ton flux.
 
je ne sais pas trop ce que ça peut donner avec les problèmes de buffers. si ton flux fait quelques ko, c'est évidement stupide de créer le fichier sur le disque. si ça fait 200 Mo, c'est peut-être pas plus mal : ça évite de risquer de se retrouver avec des objets en mémoire de taille pharaonique.
 
dans tous les cas, je ne peux guère t'en dire plus, je ne connais vraiment pas du tout java.

Beh ouais, si t'as tout sous la main et que la librairie le permet, faut pas se farcir une étape supp pour le plaisir

Meuh non! Tu dois pas tout avoir en mémoire. Tu peux brancher un flux sur l'autre. Tu lis à gauche et tu envoies à droite. Tout n'est que streams. Pas la peine de tout stocker en mémoire. Pas la peine de stocker quoique ce soit implicitement en mémoire, en fait.

bah le problème c'est que je connais pas de librairie ou interface qui permets d'envoyer un flux binaire par FTP, donc il faut que je code tous à la mano, en ce qui concerne le flux ça ne dépasse pas les 2 Mo donc ce n'est pas énorme

bah chais pas.
mais moi en C# je me retrouve toujours avec des EXE que 20 Ko qui font rien, et qui prennent 200 Mo à l'exécution
 
alors je me méfie de tout maintenant

Oué mé java cai bieng

M'enfin? T'as cherché? Ce serait gore de se farcir ça à la main!  

sauf que la JVM bouffe déjà 500 Mo avant que le moindre programme ne démarre
 
bon, faut que j'arrête de troller aujourd'hui. j'ai bu du vin à midi c'est mal

Légende urbaine.

Ben là j'ai un éditeur de fichiers XML tout bête.
Je le lance : 40 Mo
Je charge un fichier de 7 Mo... proutch, 300 Mo

Tssss, mal codé.

c pas pire que mon petit programme bd2xml...
 
comme je disais : 28 Ko.
il se connecte à une base de données, fait quelques requêtes dedans après avoir lu une poignée de fichiers de configuration en XML et génère un fichier xml de 33 Ko.
occupation mémoire : 21 Mo

le prog est mal codé
y en a un paquet de prog gérant le XML qui ont une empreinte mémoire monstrueuse
Rien à voir avec Java intrinsèquement

Oué bon, pour les petites tailles, la JVM est handicapée, cé triste.

(ici, moi c'est du C#, pas du Java. Mais c'est le même souci)
 
Ceci dit, vu le volume de données gérées et les traîtements effectués, je ne pige pas du tout pourquoi c'est aussi gros.
 
Je vais d'ailleurs poster un topic sur le sujet, parceque c'est bizarre.
 
D'autant plus bizarre que si je gère beaucoup plus d edonnées, ça prend grossomodo la même place, quand bien même je gère tout en mémoire, notamment le fichier de sortie).
J'ai l'impression que mes objets allouent d'énormes buffers pour rien.

Beh ouais. Tu peux essayer de jouer avec les params de la JVM pour réduire la conso. Tu peux peut-être t'amuser à gagner ici et là sur certaines allocations par défaut. Mais n'espère pas arriver à 1-2Mb comme certains ch'tits programmes dans d'autres langages.