batyann811 , dans le message <4b0ef4b7$0$893$, a écrit :
Je le connais assez pour en faire le moins possible.
Oui, ça se voit. Je te conseille d'en parler le moins possible également.
Comme toi des des enums et des booleens du C ?
JKB
Le 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 26-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Disons que j'ai un soft qui est un serveur en java et qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu ne veux pas que le truc se mette à bouffer toute la mémoire avec des connexions TCP (et donc des threads) mortes qui continuent à polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de gag.
Des serveurs d'application java qui tournent 24h/24 ce n'est pas exceptionnel. Je ne vois pas dans quel cas des connexions TCP pourraient être conservées comme ça. Tu as un exemple (sur un serveur d'application ou un serveur que tu écris toi-même, qui est peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement développé par une équipe maison (qui connaît parfaitement ces technos). Le truc était utilisé entre la France et des pays à accès internet aléatoires que je ne citerais pas. Il a fallu bricoler tout un système pour faire le ménage dans les threads morts sur des timeout de sockets et des trucs plus bizarres encore. Au début, ça se soldait par un redémarrage du truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple. La solution a été de coller un thread de surveillance qui 'pingue' le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée. Tous les mécanismes prévus par Java fonctionnaient parfaitement avec une socket locale, mais plus avec une socket réseau dès lors que l'accès était de mauvaise qualité.
c'est un très vieux bug connu qui doit dater du 1.1 ou 1.2 peut être même plus vieux
le time out n'était pas remonté de mémoire donc pas de désalocation du socket puisqu'il n'était pas fermé ce n'est pas un problème de gc
change de jmv
Ouaips ! Le problème existe sur :
cauchy:[~] > java -version java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.5) (6b16-4) OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode) cauchy:[~] > uname -a Linux cauchy 2.6.30.5 #2 SMP PREEMPT Wed Sep 2 15:14:49 CEST 2009 x86_64 GNU/Linux
lebegue:[~] > java -version java version "1.4.2_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) lebegue:[~] > /opt/jdk1.6.0_01/bin/java -version java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) lebegue:[~] > uname -a SunOS lebegue 5.9 Generic_122300-44 sun4u sparc SUNW,Ultra-2
tchaikovski:[~] > java -version java version "1.5.0_17" Java(TM) Platform, Standard Edition for Business (build 1.5.0_17-b04) Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode) tchaikovski:[~] > uname -a SunOS tchaikovski 5.10 Generic_127127-11 sun4v sparc SUNW,SPARC-Enterprise-T1000
Je pense que Sun ne sait donc pas écrire une JVM correcte. Quant aux versions 1.1 ou 1.2, tu repasseras puisque en 1.6, le problèem est _toujours_ là. Par ailleurs, le problème est indépendant de l'OS comme tu le vois.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 26-11-2009, ? propos de
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 26-11-2009, ? propos de
Re: go,
Yliur ?crivait dans fr.comp.os.linux.debats :
Disons que j'ai un soft qui est un serveur en java et qui
tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu
ne veux pas que le truc se mette à bouffer toute la mémoire avec des
connexions TCP (et donc des threads) mortes qui continuent à
polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de
gag.
Des serveurs d'application java qui tournent 24h/24 ce n'est pas
exceptionnel. Je ne vois pas dans quel cas des connexions TCP
pourraient être conservées comme ça. Tu as un exemple (sur un
serveur d'application ou un serveur que tu écris toi-même, qui est
peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement
développé par une équipe maison (qui connaît parfaitement ces
technos). Le truc était utilisé entre la France et des pays à accès
internet aléatoires que je ne citerais pas. Il a fallu bricoler tout
un système pour faire le ménage dans les threads morts sur des
timeout de sockets et des trucs plus bizarres encore. Au début, ça se
soldait par un redémarrage du truc tous les jours à 6h00 du matin.
Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple.
La solution a été de coller un thread de surveillance qui 'pingue'
le client. Si le client ne répond pas à trois ping consécutifs, sa
session sur le serveur est libérée. Tous les mécanismes prévus par
Java fonctionnaient parfaitement avec une socket locale, mais plus
avec une socket réseau dès lors que l'accès était de mauvaise
qualité.
c'est un très vieux bug connu qui doit dater du 1.1 ou 1.2 peut être
même plus vieux
le time out n'était pas remonté de mémoire
donc pas de désalocation du socket puisqu'il n'était pas fermé
ce n'est pas un problème de gc
change de jmv
Ouaips ! Le problème existe sur :
cauchy:[~] > java -version
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (6b16-4)
OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode)
cauchy:[~] > uname -a
Linux cauchy 2.6.30.5 #2 SMP PREEMPT Wed Sep 2 15:14:49 CEST 2009 x86_64
GNU/Linux
lebegue:[~] > java -version
java version "1.4.2_08"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
lebegue:[~] > /opt/jdk1.6.0_01/bin/java -version
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode)
lebegue:[~] > uname -a
SunOS lebegue 5.9 Generic_122300-44 sun4u sparc SUNW,Ultra-2
tchaikovski:[~] > java -version
java version "1.5.0_17"
Java(TM) Platform, Standard Edition for Business (build 1.5.0_17-b04)
Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode)
tchaikovski:[~] > uname -a
SunOS tchaikovski 5.10 Generic_127127-11 sun4v sparc
SUNW,SPARC-Enterprise-T1000
Je pense que Sun ne sait donc pas écrire une JVM correcte. Quant aux
versions 1.1 ou 1.2, tu repasseras puisque en 1.6, le problèem est
_toujours_ là. Par ailleurs, le problème est indépendant de l'OS
comme tu le vois.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 26-11-2009, ? propos de Re: go, Yliur ?crivait dans fr.comp.os.linux.debats :
Disons que j'ai un soft qui est un serveur en java et qui tourne 24h/24. Là, tu es _obligé_ de faire le ménage toi-même si tu ne veux pas que le truc se mette à bouffer toute la mémoire avec des connexions TCP (et donc des threads) mortes qui continuent à polluer la JVM. Les problèmes, ça arrive _très_ vite avec ce genre de gag.
Des serveurs d'application java qui tournent 24h/24 ce n'est pas exceptionnel. Je ne vois pas dans quel cas des connexions TCP pourraient être conservées comme ça. Tu as un exemple (sur un serveur d'application ou un serveur que tu écris toi-même, qui est peut-être le cas dont tu parles) ?
J'ai des exemples avec un progiciel écrit en java effectivement développé par une équipe maison (qui connaît parfaitement ces technos). Le truc était utilisé entre la France et des pays à accès internet aléatoires que je ne citerais pas. Il a fallu bricoler tout un système pour faire le ménage dans les threads morts sur des timeout de sockets et des trucs plus bizarres encore. Au début, ça se soldait par un redémarrage du truc tous les jours à 6h00 du matin. Aujourd'hui, la chose est stabilisée, mais ça n'a pas été simple. La solution a été de coller un thread de surveillance qui 'pingue' le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée. Tous les mécanismes prévus par Java fonctionnaient parfaitement avec une socket locale, mais plus avec une socket réseau dès lors que l'accès était de mauvaise qualité.
c'est un très vieux bug connu qui doit dater du 1.1 ou 1.2 peut être même plus vieux
le time out n'était pas remonté de mémoire donc pas de désalocation du socket puisqu'il n'était pas fermé ce n'est pas un problème de gc
change de jmv
Ouaips ! Le problème existe sur :
cauchy:[~] > java -version java version "1.6.0_0" OpenJDK Runtime Environment (IcedTea6 1.5) (6b16-4) OpenJDK 64-Bit Server VM (build 14.0-b15, mixed mode) cauchy:[~] > uname -a Linux cauchy 2.6.30.5 #2 SMP PREEMPT Wed Sep 2 15:14:49 CEST 2009 x86_64 GNU/Linux
lebegue:[~] > java -version java version "1.4.2_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) lebegue:[~] > /opt/jdk1.6.0_01/bin/java -version java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Server VM (build 1.6.0_01-b06, mixed mode) lebegue:[~] > uname -a SunOS lebegue 5.9 Generic_122300-44 sun4u sparc SUNW,Ultra-2
tchaikovski:[~] > java -version java version "1.5.0_17" Java(TM) Platform, Standard Edition for Business (build 1.5.0_17-b04) Java HotSpot(TM) Server VM (build 1.5.0_17-b04, mixed mode) tchaikovski:[~] > uname -a SunOS tchaikovski 5.10 Generic_127127-11 sun4v sparc SUNW,SPARC-Enterprise-T1000
Je pense que Sun ne sait donc pas écrire une JVM correcte. Quant aux versions 1.1 ou 1.2, tu repasseras puisque en 1.6, le problèem est _toujours_ là. Par ailleurs, le problème est indépendant de l'OS comme tu le vois.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Le Thu, 26 Nov 2009 16:21:12 +0100 remy a écrit :
Nicolas George a écrit :
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
au mieux 16 bits et un int sur un proc de 64 bits il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques n'était pas spécifiée ? Et que selon le compilateur et la plate-forme on pouvait avoir des tailles différentes, la seule garantie étant que short <= int <= long (en nombre d'octets) ? D'ailleurs je suis presque sûr d'avoir vu des int stockés par un programme C dans un fichier et qui étaient sur 2 octets (compilateur Borland).
Tu as fini de raconter des conneries ? Le Turbo C que j'utilisais sur mon PS/2 (i386DX, donc vrai 32 bits) avait des ints sur 16 bits. Pour avoir des 32 bits, il fallait utiliser un long.
bool Booléen Même taille que le type int, parfois 1 sur quelques compilateurs
un bool sur un sur processeur 64 bits 8 octets peut etre? super pour 2 état
Et ce n'est pas idiot. C'est même pour cela qu'il y a des logical*8 en Fortran pour permettre des alignements de données. C'est fou le temps qu'on peu perdre en n'alignant pas les données !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 26-11-2009, ? propos de
Re: go,
remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Le Thu, 26 Nov 2009 16:21:12 +0100
remy <remy@fctpas.fr> a écrit :
Nicolas George a écrit :
batyann811 , dans le message
<4b0e86cf$0$923$ba4acef3@news.orange.fr>, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des
types scalaires. Les entiers aussi sont des types scalaires mais
en aucun cas les types énumérés et le type booléen ne sont des
entiers.
au mieux 16 bits et un int sur un proc de 64 bits
il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes
par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques
n'était pas spécifiée ? Et que selon le compilateur et la plate-forme
on pouvait avoir des tailles différentes, la seule garantie étant que
short <= int <= long (en nombre d'octets) ?
D'ailleurs je suis presque sûr d'avoir vu des int stockés par un
programme C dans un fichier et qui étaient sur 2 octets (compilateur
Borland).
Tu as fini de raconter des conneries ? Le Turbo C que j'utilisais
sur mon PS/2 (i386DX, donc vrai 32 bits) avait des ints sur 16 bits.
Pour avoir des 32 bits, il fallait utiliser un long.
bool Booléen
Même taille que le type int, parfois 1 sur quelques compilateurs
un bool sur un sur processeur 64 bits 8 octets peut etre?
super pour 2 état
Et ce n'est pas idiot. C'est même pour cela qu'il y a des logical*8
en Fortran pour permettre des alignements de données. C'est fou le
temps qu'on peu perdre en n'alignant pas les données !
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 26-11-2009, ? propos de Re: go, remy ?crivait dans fr.comp.os.linux.debats :
Yliur a écrit :
Le Thu, 26 Nov 2009 16:21:12 +0100 remy a écrit :
Nicolas George a écrit :
batyann811 , dans le message <4b0e86cf$0$923$, a écrit :
Ce sont des entiers en C dans un vrai langage ce sont juste des types scalaires. Les entiers aussi sont des types scalaires mais en aucun cas les types énumérés et le type booléen ne sont des entiers.
au mieux 16 bits et un int sur un proc de 64 bits il a quelle taille ?
bon bref, tout ça pour juste 2 états
et je l'ai relu, donc pas trop de fautes par contre pour le c ce sont des souvenirs
remy
Il me semblait qu'en C la taille (en octets) des types numériques n'était pas spécifiée ? Et que selon le compilateur et la plate-forme on pouvait avoir des tailles différentes, la seule garantie étant que short <= int <= long (en nombre d'octets) ? D'ailleurs je suis presque sûr d'avoir vu des int stockés par un programme C dans un fichier et qui étaient sur 2 octets (compilateur Borland).
Tu as fini de raconter des conneries ? Le Turbo C que j'utilisais sur mon PS/2 (i386DX, donc vrai 32 bits) avait des ints sur 16 bits. Pour avoir des 32 bits, il fallait utiliser un long.
bool Booléen Même taille que le type int, parfois 1 sur quelques compilateurs
un bool sur un sur processeur 64 bits 8 octets peut etre? super pour 2 état
Et ce n'est pas idiot. C'est même pour cela qu'il y a des logical*8 en Fortran pour permettre des alignements de données. C'est fou le temps qu'on peu perdre en n'alignant pas les données !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 26-11-2009, ? propos de Re: go, Stéphane CARPENTIER ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée.
Si la politique sécurité du client est de ne pas répondre au ping (je sais que c'est de la sécurité d'imbéciles, mais ça existe) ça se passe comment ?
C'est un ping entre le client et le serveur sur la socket utilisée par l'application, pas un ping au sens ICMP du terme. Si le client ferme sa socket applicative, son client ne fonctionnera pas, donc la remarque est caduque.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 26-11-2009, ? propos de
Re: go,
Stéphane CARPENTIER ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
le client. Si le client ne répond pas à trois ping consécutifs, sa
session sur le serveur est libérée.
Si la politique sécurité du client est de ne pas répondre au ping (je
sais que c'est de la sécurité d'imbéciles, mais ça existe) ça se passe
comment ?
C'est un ping entre le client et le serveur sur la socket utilisée
par l'application, pas un ping au sens ICMP du terme. Si le client
ferme sa socket applicative, son client ne fonctionnera pas, donc la
remarque est caduque.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 26-11-2009, ? propos de Re: go, Stéphane CARPENTIER ?crivait dans fr.comp.os.linux.debats :
JKB wrote:
le client. Si le client ne répond pas à trois ping consécutifs, sa session sur le serveur est libérée.
Si la politique sécurité du client est de ne pas répondre au ping (je sais que c'est de la sécurité d'imbéciles, mais ça existe) ça se passe comment ?
C'est un ping entre le client et le serveur sur la socket utilisée par l'application, pas un ping au sens ICMP du terme. Si le client ferme sa socket applicative, son client ne fonctionnera pas, donc la remarque est caduque.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Stephane TOUGARD
JKB wrote:
La question est donc : peut-on directement attaquer par un truc comme java ?
Et la reponse est "Oui, bien sur !".
JKB wrote:
La question est donc : peut-on directement attaquer par un truc
comme java ?
Le C est un excellent language. D'ailleurs, Perl est ecrit en C.
Perl est aussi écrit en perl.
Ce qui prouve que perl est un excellent language aussi.
Nicolas George
batyann811 , dans le message <her6pl$kcv$, a écrit :
De plus les idées de Ritchie sur les enums ou l'absence de booleens ne devaient pas être si bonne puisque Stroustrup s'est senti obligé d'y apporter quelques corrections.
Ne me fais pas rire. Prendre Stroustrup comme référence !
batyann811 , dans le message <her6pl$kcv$1@aioe.org>, a écrit :
De plus les idées de Ritchie sur les enums ou l'absence de booleens ne
devaient pas être si bonne puisque Stroustrup s'est senti obligé d'y
apporter quelques corrections.
Ne me fais pas rire. Prendre Stroustrup comme référence !
batyann811 , dans le message <her6pl$kcv$, a écrit :
De plus les idées de Ritchie sur les enums ou l'absence de booleens ne devaient pas être si bonne puisque Stroustrup s'est senti obligé d'y apporter quelques corrections.
Ne me fais pas rire. Prendre Stroustrup comme référence !
