Cyriaque a écrit 10 commentaires

Ouais enfin y a une différence entre un Crysis - qui a nécessité des millions d'investissement, des années de réalisation, à quelques 100aines d'intervenants et qui au final est à peine rentable parce que finalement pas si bien que ça trop piraté - et un Wesnoth d'envergure nécessairement plus modeste.

Même mieux que ça, à priori, cette année ils roulent à l'éthanol, comme quoi, même dans ce domaine des efforts sont faits...

La vache, c'est que j'aurais presque honte d'apprécier le sport-auto dites donc à lire certains commentaires :/

Voila qui est intéressant !

Va falloir que je teste ça moi aussi à l'occasion. Avec un peu de bol, je vais peut-être pouvoir ne plus avoir à rebooter pour rouler sur Nascar Racing 2003 ou GPL (c'est pas ce à quoi vous pensez hein, il s'agit ici de Grand Prix Legend).

Bon reste malheureusement le dernier soucis pour moi, à savoir les dernières simus en vogue (RFactor, GTR2, etc...) qui ne tournent qu'exclusivement sous Windows, et m'obligent à garder cette satanée partoche dédiée à cause de ça...

En tout cas, c'est encourageant, merci !

Moi la ou je me dis qu'ils doivent nous prendre pour des vaches à lait quoiqu'il arrive, c'est quand concrètement je vois des rayons DVD de plus en plus grands dans les supermarchés ou magasins spécialisés au fil des années.

Si les rayons sont si grands, c'est que ça doit bien se vendre nan ? Les DVDs doivent pas être la juste pour faire joli ? Avec des rayons aussi grands, c'est que ça doit être un marché juteux l'industrie du DVD ?

Mais à coté, ils vont nous rabacher que le piratage est en train de causer leur mort.
Je sais pas, j'arrive pas à compatir.

J'arrive d'autant moins à compatir, quand lorsque j'achète un DVD, de manière tout ce qu'il y a de plus honnête, je me retrouve à devoir me palucher 5 min de leur spot de merde et mal fait et impossible à interrompre, qui fait l'analogie du piratage avec le vol de voiture, de banque, et blablabla..., avant de pouvoir regarder mon film.
Ca aurait plutôt tendance à me faire l'effet inverse lorsqu'on force à me faire la morale alors que j'ai acheté honnêtement le DVD, ce qui est quand même un comble.

Bref , il a bon dos le piratage avec ces majors...

Je ne saurais pas vraiment aider sur la façon de faire tourner Eclipse et son plugin Sysdeo à partir d'un Tomcat packagé Debian.

Par contre ce que tu peux faire si vraiment ça ne marche pas, et vu que le Tomcat en local est utilisé pour du dev, c'est installer une instance de Tomcat custom avec le même compte que celui qui exécute Eclipse.

Aucune difficulté à installer localement (il n'y a qu'à dézipper le package dans un répertoire et changer le port).
Il n'y a même pas besoin des variables d'environnement habituelles (JAVA_HOME...), puisque l'on peut lier un JDK a un tomcat via Eclipse.
Même chose pour le JDK qui peut être installé avec ce user courant.
Ca n'est ensuite plus qu'une question de paramètrage dans les préférences d'Eclipse pour lier un JDK (Java -> Installed JREs) avec Tomcat (Tomcat -> JVM Settings).

L'avantage de la chose, c'est que l'on peut avoir plusieurs Tomcat sur différents ports bien sur (ex: un Tomcat 4 et un Tomcat 5, faut en avoir l'utilité bien sur, et c'est mon cas en l'occurrence) ainsi que plusieurs JDK, et switcher si besoin entre ces différents Tomcat sous Eclipse sans aucun soucis (et si on veut pas switcher, rien n'empêche d'avoir un Eclipse bien configuré par Tomcat), etc...

Je suis surement hors sujet par rapport à ce que tu souhaites faire, mais si ça peut aider au cas ou...

Je confirme qu'il ne faut pas chercher une explication niveau système, hardware ou autre lié à Red Hat.

Il s'agit très probablement bel et bien du serveur d'appli qui est fautif.

Une de vos applis sous JBoss provoque des fuites mémoires.

D'ailleurs si vous monitorez la mémoire prise par JBoss (par un simple top par exemple), vous verrez certainement la mémoire prise par celui allant en augmentant au fil du temps et de l'utilisation de l'appli fautive.
Et effectivement, une fois la RAM pleine, le Swap sera attaqué à son tour par JBoss sans jamais diminuer jusqu'à atteindre sa limite.
A ce moment, le kernel ne se posera plus de questions pour préserver la survie du système et fera le ménage en killant ce qui monopolise la mémoire.

Donc c'est bien au niveau des applis java sous JBoss qu'il faut investiguer.


Maintenant il ne s'agit pas nécessairement d'un problème d'objets mal gérés dont le Garbage Collector n'arriverait pas à se débarrasser. Car dans ce cas, théoriquement, vous finiriez par avoir des OutOfMemory Exceptions, et jamais ça ne dépasserait le cadre de la mémoire allouée à la JVM. Tout ce que vous auriez dans ces cas la, c'est un comportement instable de vos applis.


Le problème est donc plus "profond" et plus vicieux, car de la mémoire hors JVM est allouée et n'est jamais libérée.

Ca n'est pas particulièrement facile à diagnostiquer (bon courage d'ailleurs) mais ça peut être lié au système tout de même notamment dans la façon dont Java va interagir avec.

En gros, voyez si vos problèmes ne sont pas liés avec les points suivants (en vrac):
- mauvaise gestion de stream (ex: un InputStream ou OutputStream ouvert mais non fermé)
- par extension mauvaise manipulation de fichiers (ex: dans le cas d'un upload d'un fichier envoyé par un formulaire Multipart/form)
- mauvaise gestion des transactions avec la base de données (resultsets ouverts mais non fermés).
- ça peut dépendre encore du type d'interaction que vous avez avec ce File System OCSF2.
- Enfin essayez de mettre à jour vos librairies (.jar) voir si le problème se produit toujours.

Plutôt vague comme question.

Dans la mesure ou il existe des versions linux du JDK et de Tomcat, il doit très certainement être possible de les installer ne serait-ce que "manuellement". Quand à savoir les spécificités liées à Red Hat, je ne pourrai pas être plus précis, n'ayant aucune connaissance concernant cette distrib.

Quand à la façon de s'y prendre pour installer Tomcat et le JDK, il doit exister de nombreux tutoriels permettant de le faire (Google est certainement très bavard en la matière).

Si j'ai bien compris, le but est de faire tourner un Tomcat distant sous Eclipse via le plugin Sysdeo avec les sources de la webapp en local ?

J'ai jamais tenté l'expérience, mais sans vouloir être pessimiste, j'ai de gros doutes sur la faisabilité de la chose.

Mais je me trompe peut-être.

Dans le même ordre d'idées, recherche aussi du côté des Web Services, ça pourrait correspondre à ton besoin.

Il y a notamment Axis, d'Apache, qui permet d'utiliser ces Web Services:
http://ws.apache.org/axis/

Il me semble que sous Debian le port par défaut de Tomcat est le 8180 (Je suppose que c'est pareil sous Ubuntu).

Ca doit être précisé dans la doc /usr/share/doc/tomcat5 très certainement.

Sinon au pire, netstat peut te permettre de voir le port réellement utilisé par le processus Tomcat.

Et si c'est pas ça, les logs de /usr/share/tomcat5/logs indiquent-elles quelque chose d'anormal au démarrage ?