Java et IP6

Delf wrote:

[...]

Oula, le process Java me prend 433Mo de Ram pour 1 socket et 2
threads... ça me fait bien marrer-jaune...

--
Delf

Bonjour.

Bonjour,

Ah les joies de l'ipv6 :)
(petite pub au passage pour une noble cause http://ipv6pourtous.free.fr/ )

Je développe une application Java (Diablo Caffe FreeBSD-6.1 1.5.0_07)

Je souhaite que cette application supporte IP6/IP4 ou uniquement IP4
(comme c'est possible en C/C++ ou dotnet).

Le support de IPv6 existe pour Solaris et Linux depuis le JDK 1.4.0 et
le JDK 1.5.0 pour WinXP et Win2003 ... et tout ce fait automatiquement.

Pour FreeBSD, aucune idée quelle est le niveau réel du portage disponible.

Sinon, toute application Java est defacto compatible IPv6 sans
modification de code source, ni recompilation, ni redéploiment :)

http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html#ipv6-networking

Vous dites : "comme c'est possible ..."

Il me semble qu'en C++, il faut recompilation et généralement
modification du code ;-)
Pour .net, désolé mais MS l'a répété : on ne supportera que les SE
Microsoft (logique non ?). Et oui, la citrouille Rotor (Estampillé aussi
parfois SSCLI) ne sera jamais Carosse. "On m'aurait mentiiiii ?" Non,
simplement un marketing efficace de MS ;-)

Voici un extrait du code:

CLoader.PROTOCOL ipProtocol = loadInstance.getIpProtocol();

if (ipProtocol == CLoader.PROTOCOL.IP4)
{
System.setProperty("java.net.preferIPv4Stack", "true");
}
else
{
System.setProperty("java.net.preferIPv6Addresses", "true");
}

Mais je m'étonne de n'avoir jamais un socket Tcp6 via netstat.
Pourtant, mon OS a la double pile IP4/IP6.

Merci d'avance pour toute précision.

On touche là potentiellent à un autre domaine ...

Pour que deux applications discutent en ipv6 il faut également que :
- les deux machines (client et serveur) sont parfaitement configuré en
ipv6
- le nom du serveur soit résolvable par le client via AAA sur le DNS
lui faisant autorité
- le service serveur écoute sur un Socket compatible Ipv6
- le routage entre la machine client et la machine serveur soit un
chemin valide en ipv6

Le fait de ne pas avoir de socket en ipv6 indique que la VM lui préfère
un chemin ipv4, assurez vous de bien avoir Dans le code exécuté par la VM :

System.setProperty("java.net.preferIPv6Addresses", "true");

Si celà est le cas, vérifiez l'ensemble des points énnumérés précédement.

Enfin, faites une "simple classe" de test de socket accédant à un hôte
via ipv6 ...

Quand à la mémoire utilisée par votre application, du code qui utilise
beacoup de mémoire fait utiliser beaucoup de mémoire à la VM ;-)
A vous de voir si celà vous parrait justifier par les traitements que
vous faites. Si ce n'est pas le cas, alors sautez sur un outil analyseur
de performance pour voir où est le problème dans le code ...

Bonne chance !
A+
TM

TestMan wrote:

Le support de IPv6 existe pour Solaris et Linux depuis le JDK 1.4.0 et
le JDK 1.5.0 pour WinXP et Win2003 ... et tout ce fait automatiquement.
Pour FreeBSD, aucune idée quelle est le niveau réel du portage disponible.

Je souhaiterais que celà fonctionne sous Linux/BSD.

Vous dites : "comme c'est possible ..."

Il me semble qu'en C++, il faut recompilation et généralement
modification du code ;-)

Je parlais du fait que l'on puisse avoir le support IP4/6 en utilisant
un socket IP6.

Quand à la mémoire utilisée par votre application, du code qui utilise
beacoup de mémoire fait utiliser beaucoup de mémoire à la VM ;-)

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)

--
Delf

On Sun, 23 Jul 2006 11:49:47 +0200, Delf <none@none.org> wrote:

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)

433 Mo de quoi ? Taille résidente, taille virtuelle ? Taille des zones
mémoires anonymes, des fichiers mmapés ? Y a beaucoup de type de
mémoire sous Java. Entre les différents zone du heap, les jar mmapés,
la mémoire reservé pour la compilation JIT et j'en passe. Evaluer les
besoins en mémoire d'une application Java, c'est pas évident. Un
passage par jconsole est conseillé. Sans oublier que certain OS (Linux
par exemple) indique la mémoire reservé (mais pas consommé) dans la
taille de la mémoire virtuelle, ce qui peut-être surprenant.

Delf wrote:

[...]

Oula, le process Java me prend 433Mo de Ram pour 1 socket et 2
threads... ça me fait bien marrer-jaune...

Tu dois avoir un problème dans ton programme parce que même Azureus qui
fait du thread et socket a fond n'occupe pas tant de ram.

On Sun, 23 Jul 2006 11:49:47 +0200, Delf <none@none.org> wrote:

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)

433 Mo de quoi ? Taille résidente, taille virtuelle ? Taille des zones
mémoires anonymes, des fichiers mmapés ? Y a beaucoup de type de
mémoire sous Java. Entre les différents zone du heap, les jar mmapés,
la mémoire reservé pour la compilation JIT et j'en passe. Evaluer les
besoins en mémoire d'une application Java, c'est pas évident. Un
passage par jconsole est conseillé. Sans oublier que certain OS (Linux
par exemple) indique la mémoire reservé (mais pas consommé) dans la
taille de la mémoire virtuelle, ce qui peut-être surprenant.

Ben quelque soit le type de mémoire utilisé ca reste énorme 433 Mo, donc
soit ya une fuite mémoire dans son programme, soit la JVM alloue toute
la ram au lancement

Bonjour,

TestMan wrote:

Vous dites : "comme c'est possible ..."

Il me semble qu'en C++, il faut recompilation et généralement
modification du code ;-)

Je parlais du fait que l'on puisse avoir le support IP4/6 en utilisant
un socket IP6.

Java utilisant les même bibliothèques et fonctions du système, vous
n'aurez pas de différence de comportement d'avec le C++

Les seuls points blocants avec Java est l'abscense d'access direct à
l'option SOCK_RAW ;-)

Quand à la mémoire utilisée par votre application, du code qui utilise
beacoup de mémoire fait utiliser beaucoup de mémoire à la VM ;-)

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)

Clairement :) Aller un coup d'analyseur et vous devriez trouver ce qui
alloue autant de mémoire dans votre code... (vérifiez les paramètres de
démarages de la VM à tout hazard).

A+
TM

On Mon, 24 Jul 2006 10:39:44 +0200, Kupee <rien@rien.rien> wrote:

On Sun, 23 Jul 2006 11:49:47 +0200, Delf <none@none.org> wrote:

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)

433 Mo de quoi ? Taille résidente, taille virtuelle ? Taille des zones
mémoires anonymes, des fichiers mmapés ? Y a beaucoup de type de
mémoire sous Java. Entre les différents zone du heap, les jar mmapés,
la mémoire reservé pour la compilation JIT et j'en passe. Evaluer les
besoins en mémoire d'une application Java, c'est pas évident. Un
passage par jconsole est conseillé. Sans oublier que certain OS (Linux
par exemple) indique la mémoire reservé (mais pas consommé) dans la
taille de la mémoire virtuelle, ce qui peut-être surprenant.

Ben quelque soit le type de mémoire utilisé ca reste énorme 433 Mo, donc
soit ya une fuite mémoire dans son programme, soit la JVM alloue toute
la ram au lancement

Java n'a jamais été économe en mémoire, mais selon le type de
consommation mémoire, la solution est à chercher à des endroits tout à
fait différent. Et sur un Linux 2.6 j'avais dernièrement une JVM de
2Go de virtual size, sauf que la somme de la mémoire physique occupé
plus le swap occupé, pour tout le système, était inférieur à 1 Go,
donc en fait y avait pas de problème.

On Mon, 24 Jul 2006 10:39:44 +0200, Kupee <rien@rien.rien> wrote:

On Sun, 23 Jul 2006 11:49:47 +0200, Delf <none@none.org> wrote:

Oui mais ouvrir un socket et lancer 2 thread qui disent 'coucou'... ça
fait un peu beaucoup 433Mo :)
433 Mo de quoi ? Taille résidente, taille virtuelle ? Taille des zones

mémoires anonymes, des fichiers mmapés ? Y a beaucoup de type de
mémoire sous Java. Entre les différents zone du heap, les jar mmapés,
la mémoire reservé pour la compilation JIT et j'en passe. Evaluer les
besoins en mémoire d'une application Java, c'est pas évident. Un
passage par jconsole est conseillé. Sans oublier que certain OS (Linux
par exemple) indique la mémoire reservé (mais pas consommé) dans la
taille de la mémoire virtuelle, ce qui peut-être surprenant.
Ben quelque soit le type de mémoire utilisé ca reste énorme 433 Mo, donc

soit ya une fuite mémoire dans son programme, soit la JVM alloue toute
la ram au lancement

Java n'a jamais été économe en mémoire, mais selon le type de
consommation mémoire, la solution est à chercher à des endroits tout à
fait différent. Et sur un Linux 2.6 j'avais dernièrement une JVM de
2Go de virtual size, sauf que la somme de la mémoire physique occupé
plus le swap occupé, pour tout le système, était inférieur à 1 Go,
donc en fait y avait pas de problème.

Oui reste que 2 threads et un socket qui font 433 Mo ca reste
inconcevable a moins d'une erreur de programmation ou d'un bug de la jvm.

Kupee wrote:

Oui reste que 2 threads et un socket qui font 433 Mo ca reste
inconcevable a moins d'une erreur de programmation ou d'un bug de la jvm.

Bizarre, regardez ceci:

package javaapplication4;

public class Main {

public static void main(String[] args) {
try
{
Thread.sleep(10000000);
}
catch (Exception x) { }
}
}

Je lance l'application...

last pid: 8749; load averages: 0.30, 0.16, 0.10 up 0+04:07:55
22:56:11
55 processes: 1 running, 54 sleeping
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100%
idle
Mem: 254M Active, 206M Inact, 110M Wired, 18M Cache, 111M Buf, 405M Free
Swap: 2048M Total, 8K Used, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU CMD
8431 delf 4 20 0 433M 188M kserel 0:26 0.00% java
8462 delf 2 20 0 218M 11700K kserel 0:00 0.00% java

Si quelqu'un pouvait m'expliquer ce qu'il se passe vraiment...

--
Delf