j'ai demarré une rmiregistry sans l'arreter, je veux l'arreter sans devoir rebooter ma machine, comment puis-je?
je vois rien dans le task manager
 
(win2k)
 
 

Ctrl C sur la fenêtre MS DOS, ça marche pas ?

je l'ai demarrée depuis une appli java qui s'est crashée lamentablement
 
et mtnt le port est bindé et voila
 
bon... je vais recompiler mon bourdaÿl pour qu'il la ferme ça ira mieux je pense

la c'est probable que la registry soit fermée mais que le système n'ait pas capté que y'a plus rien derriere la socket, non ?

oué
 
remarque là je viens de relancer le bordel en utilisant un autre port... il crée la registry, mais apres je me prend une connection refused qd j'essaie de m'y binder
comprend rien
 
je reboot fais chier

vraiment bizare ton histoire, le port aurait du être rendu quand ton appli a crashé !
 
je crois que ton windows est dans les choux !

 
ouais je suis assez d'accord. Et voici pq. Lorsque tu démarres la registry depuis un prog Java c'est considéré comme une thread de la JVM en cours. Si ton soft se crashe lamentablement, tu as deux possibilités.
 
Soit tu as un process java / javaw dans ton task manager que tu kille et alors tu es tranquille
Soit tu n'en a pas. Dans ce cas la JVM s'est arreté et toute thread qui y est associée (y compris la registry bien sur).

 
Pas completement d'accord : ce n'est forcement vrai QUE pour le premier hop, ensuite si ton application est native tu n'as plus aucun controle. Voici un cas que j'ai du traiter :  
 
Si tu lances un prog externe a partir d'une applic java tu as un nouveau processus (et pas thread)... Mais les processus crees par ce processus fils ne sont pas forcement lie au processus fils (ils peuvent etre independants, ne plus faire partie du meme process tree). Donc si le processus createur meurt les petits fils peuvent toujours tourner...
 
Et ca c'est de la "belle caca" : processus tournant et bloquant des ressources... et ce ne sont meme aps des fantomes.
 
J'avais ce probleme avec realencoder en mode ligne de commande : seul moyen de killer l'application proprement etait de faire un ctrl-c sur la fenetre (a la main, impossible de lancer un signal ou d'ecrire sur les streams pour terminer proprement l'applic) , sinon (fermeture a partir de l'application ouplantage) des processus tournaient encore (genre le processus d'encodage... donc fichier non ferme, donc impossible de lancer un post processing, etc...) et on devait les killer a la main en les cherchant.
 
Cette "feature" a la con a empecher un postprocessing automatise des flux audio : un type devait stoper l'encodage a la main... Chez Real ils refusaient de faire quoi que ce soit et proposaient d'utiliser la version DCOM de l'encodeur ou de coder un outil gadget pour trouver les processus et les killer (il leur suffisait de lier les processus dans leur produit mais non ca leur faisait chier... vive les produits commerciaux) (alors qu'on avait besoin de portabilite entre win-solaris-irix (3 plateformes sur lesquelles tournait leur shell-encoder)
 
Finalement on a change de produit car Real se foutait de la gueule du monde.
 
Tout ca pour dire que c'est ce qui se passe "peut-etre" dans le cas de greg : processus qui accapare le port apres plantage de l'application.

Merci pour ce complément d'information. Je n'étais pas au courant (ah si je savais que real se fout de la gueule de ses clients. Ca effectivement c'est pas un secret).
 
Ceci dans le cas de la registry j'ai un sérieux doute. Le plus simple étant évidemment de lancer le meme soft sur un autre pc. Et puis je crois que greg lance son soft depuis un éditeur (IntelliJ) et ca peut aussi etre fortement la raison de son problème. (Moi je trouve foireux de faire ce genre de choses depuis un éditeur et il a pas voulu m'écouter. Si c'est ça qu'il ne vienne pas se plaindre   )
 
 

DarkLord a écrit a écrit : Merci pour ce complément d'information. Je n'étais pas au courant (ah si je savais que real se fout de la gueule de ses clients. Ca effectivement c'est pas un secret).   Ceci dans le cas de la registry j'ai un sérieux doute. Le plus simple étant évidemment de lancer le meme soft sur un autre pc. Et puis je crois que greg lance son soft depuis un éditeur (IntelliJ) et ca peut aussi etre fortement la raison de son problème. (Moi je trouve foireux de faire ce genre de choses depuis un éditeur et il a pas voulu m'écouter. Si c'est ça qu'il ne vienne pas se plaindre   )

plus maintenant
mais bon, pour dev, se retaper un build/deploy à chaque fois c un peu lourd quoi

bin je sais pas. Moi je relance pas tout le brol chaque fois que je fais un changement

DarkLord a écrit a écrit : bin je sais pas. Moi je relance pas tout le brol chaque fois que je fais un changement

 
make rulez !

ant rulezzz oui !!

emacs rulez !
 
 

 
Vas jeter un oeil sur javamake (va faire partie des bin de la jdk 1.5). C'est Dimitriev qui s'en occupe (responsable de Hot Swap chez Sun)
 
Leur but est simple : rien a configurer pas de fichiers de dependences, rien : javamake ton fichier source, et en s'aidant du classpath il make tout.
 
Pour l'instant ce n'est pas fini mais ca me plait deja.
 
moi je vous dis "du tout bon" :-)