Bonjour,

Suite à une remontée d'anomalie, je suis actuellement en train de vérifier le code d'un composant RMI Java permettant de copier le contenu d'un répertoire d'un serveur vers un répertoire d'un autre serveur.

Après avoir fouillé le code et rechercher des infos sur le net, je suis arrivé à la conclusion que l'erreur venait d'une concurrence d'accès sur un fichier déjà ouvert (FileNotFoundException lors de l'instanciation d'un FileInputStream ou d'un FileOutputStream).
En effet, le fichier provoquant l'erreur existe bien.

Le code ci-dessous montre que les FileInputStream/FileOutputStream ne sont pas fermés (détruits) après utilisation.

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
// Déclaration des buffers
FileInputStream fi;
BufferedInputStream in;
 
FileOutputStream fo;
BufferedOutputStream out;
 
try
{
// Ouverture d'un buffer de lecture de fichier
fi = new FileInputStream(dirPub + nomfic);
in = new BufferedInputStream(fi,BUFFER_SIZE);
 
// Ouverture d'un buffer d'ecriture de fichier
fo = new FileOutputStream(dirPro + nomfic);
out = new BufferedOutputStream(fo,BUFFER_SIZE);
 
// Copie du fichier
int c;	        
byte b[] = new byte[BUFFER_SIZE];
 
while ((c = in.read(b)) != -1)
	out.write(b, 0, c);
	in.close();
	out.close();
 
	// On positionne la date de derniere modification du fichier de production à la date de dernière modification du fichier en publication
	new File(dirPro + nomfic).setLastModified(new File(dirPub + nomfic).lastModified());
 
} 
catch (FileNotFoundException fnf) 
{
	//Traitement de la FileNotFoundException
	// C'est cette exception qui est levée lors de l'instanciation du FileInputStream
}
catch (IOException ioe)
{
	// Traitement de l'IOException
}
Or, les fichiers sont déjà accédés un peu plus tôt lors de l'appel dans une autre méthode du composant. Et de la même manière, les FileInputStream instanciés ne sont pas fermés.

En ayant trouvé des infos ici :
http://www.developpez.net/forums/sho...d.php?t=443600
là :
http://www.developpez.net/forums/sho...d.php?t=200740
et là :
http://java.developpez.com/faq/java/...ererRessources

je penche vraiment pour ce type d'erreur. J'ai d'ailleurs un "Permission denied" dans le message de l'exception qui vient renforcer cette idée.

Du coup, j'essaie de reproduire le cas d'erreur en local sur ma propre machine et là, surprise : pas de plantage. Que je teste avec une copie de 1 fichier ou 10 ou 50000, le traitement se déroule correctement. Pas facile de valider une correction si on n'arrive pas à reproduire le cas d'erreur d'origine...

Auriez-vous une idée pour reproduire un cas de fichier déjà ouvert en local?

J'ai trouvé une phrase d'un support de cours qui me fait penser que l'environnement d'exécution pourrait jouer un rôle que je ne connais pas :
Classe FileOutputStream : java.io.FileOutputStream
Un flux de sortie de fichier est un flux de sortie permettant d’écrire des données dans un fichier ou dans un FileDescriptor. Qu’un fichier soit disponible ou puisse être créé dépend de la plate-forme sous-jacente. Certaines plates-formes autorisent un fichier à être ouvert en écriture par un seul FileOutputStream à la fois. Dans de telles situations les constructeurs de cette classe échouent si le fichier est déjà ouvert.
issue de : http://www.ensg.ign.fr/FAD/FAD_PDF/c.../IntroJava.pdf

En lisant ceci, j'en viens à me dire que c'est peut-être l'environnement de production qui provoque ce blocage. Le serveur de production est un Solaris équipé Sun de la tête au pied (y compris la version du jdk qui est fournie par Sun si j'ai bien compris ce qu'on m'a dit).

Auriez-vous entendu parler de ce genre de problème lié au système utilisé?

Toute aide ou info est la bienvenue.

D'avance merci.