Dans ce cas c'est différent, c'est une méthode à implémenter ..., et elle est déclenchée à la destruction d'un session. Elle ne la détruit en rien ...
Dans ce cas c'est différent, c'est une méthode à implémenter ..., et elle est déclenchée à la destruction d'un session. Elle ne la détruit en rien ...
http://alaindefrance.wordpress.com
Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
SDE at BitTitan
Hello,
Si g bien compris ton pb, tu veux lister les clients connectés.
Dans tous les protocoles, même si il est prévu un évènement de déconnexion, il n'est pas possible d'associer un évènement, à la déconnexion d'un client de façon sure. Tout simplement parce que les raisons de cette déconnexion peuvent êtres multiples :
-kill -9 du client
-débranchement réseau qui n'invalide pas forcément les connexions (par ex sous linux)
-engorgement réseau
-etc...
Ce genre de pb ressemble furieusement aux gestions de licences par réseau.
La seule solution est de faire une connexion régulière sur ton serveur. Lorsqu'un client ne s'est pas connecté depuis un certain temps, tu invalides sa session (ya pas besoin de le faire sur un serveur d'application cf timeout, ton listener pourra alors retirer le client d'une liste).
On appelle cela du heartbeat.
Le pb c que c gourmand
Il y a donc plusieurs solutions :
-Si tu peux faire du tcp, conserve la connexion et fais le heartbeat dedans (c pas possible en flash mais oui en air il me semble).
-Limiter le délais de heartbeat (y a un petit calcul à faire sur le ratio délais_de_détection/nbr_de_clients_max) sachant que si tu ajoutes du https, ça va plomber les perfs.
Pour moi la meilleur solution étant de faire un get depuis flash. La servlet renvoie un xml avec :
-versions du protocole
-info persos
-et surtout le prochain délais de connection (heartbeat).
Ce délais te permet de limiter la casse. La servlet fonctionne un peu comme un garbage collector : plus un client est connecté depuis longtemps, plus il y aura de chance qu'il reste connecté encore longtemps. Donc tu peux augmenter régulièrement son délais de heartbeat. Le client renvoie un get à cette adresse au bout de (heartbeat-epsilon), epsilon étant le temps de traitement du heartbeat que tu peux évaluer côté client entre le get et la reponse.
Voili.
http://alaindefrance.wordpress.com
Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
SDE at BitTitan
Toute façon je ne travaille qu'avec des évènement sous flex, alors il est possible de déconnecter un client et de façon sure.Envoyé par r1-1024
il n'est pas possible d'associer un évènement, à la déconnexion d'un client de façon sure
Encore désolé mais ce n'est pas des communication réseau comme tu l'entends, c'est juste une application java côté serveur et une application flex côté client et quand je dis serveur, un serveur J2EE(Tomcat, JBoss, Glassfish).Envoyé par r1-1024
La seule solution est de faire une connexion régulière sur ton serveur.
Flex et Java communique comme un EJB communiquerait avec une simple classe Java.
Si elle ne la détruit en rien comme tu dis, alors je peux insérer la session.invalidate() dans la medthode sessionDestroy, ainsi du côté client, la méthode écoutant la fermerture de naviagteur appelera la sessionDestroy et lancera la session.invalidate().Envoyé par Alain Defrance
Dans ce cas c'est différent, c'est une méthode à implémenter ..., et elle est déclenchée à la destruction d'un session. Elle ne la détruit en rien ...
Qu'est ce que vous en dites de cette solution??
THE CHANGE
Toujours en quête de connaissance
WINDOWS :Oracle 11G, SQL DEVELOPER 2.2, Eclipse Ganymede 3.4 plugins VE 1.4, Flex 4
MAC OsX 10.6.5 : Oracle 10G R2 SQL DEVELOPER 1.5.4, Eclipse Helios 3.6, plugins VE 1.4, Flex 4
tout dépend, en quoi t'as la garantie que ton client sera bien notifié de la fermeture du navigateur? Ta solution est abordable (appeleter un servlet / service / autre du serveur qui ferais un session.destroy() ) et marcherais probablement dans 90% des cas, mais ne fonctionnerais pas, comme on l'a dit, dans les cas suivant:
1) le client perd sa connection adsl (perte réseau) -> impossible de faire ledit appel au serveur
2) le browser crash -> ton code flex ne sera jamais appelé
3) le browser ne notifiant pas flash / flex de sa fermeture (pas impossible que ca existe)
La question de base qu'on est occupé de se poser est, pourquoi t'as besoin d'invalider la session aussi vite, et que tu ne peux pas attendre les 30 minutes de timeout?
Non, si la session ne se détruit pas, la méthode ne sera pas appelée. Si tu fait la destruction dans cette méthode, alors elle ne sera jamais détruite par ton code.
C'est un listener, et au même titre qu'il est inutile de notifier l'ouverture de fenêtre concernée dans un windowsListener sous swing, il en est de même avec les sessions.
http://alaindefrance.wordpress.com
Certifications : SCJP6 - SCWCD5 - SCBCD5 - SCMAD1
SDE at BitTitan
Je persiste, c kif kifToute façon je ne travaille qu'avec des évènement sous flex, alors il est possible de déconnecter un client et de façon sure.
Encore désolé mais ce n'est pas des communication réseau comme tu l'entends, c'est juste une application java côté serveur et une application flex côté client et quand je dis serveur, un serveur J2EE(Tomcat, JBoss, Glassfish).
Flex et Java communique comme un EJB communiquerait avec une simple classe Java.
Si tu ne veux pas avoir de clients qui ne déclarent pas leur déconnexion (une fuite ds le comptage quoi), t obligé de mettre un timeout sur la session.
Si tu veux avoir de la réactivité dans le comptage, le timeout doit être petit.
Ca c du heartbeat.
Si tu veux augmenter les perfs du serveur, il faut bidouiller avec un calcul de défaillance comme je t'ai dit.
Pour avoir pas mal bossé sur le sujet, j'peux t'affirmer que tu ne peux pas avoir d'évènement lié à une déconnexion autre que de faire du heartbeat (pense au kill -9 client, même si ton serveur écrit dans la réponse au moment du kill, sous linux il ne le verra même pas. Comment flash peut avertir qu'il vient de se faire butté, vu qu'il est mort).
Alors c'est sur que rajouter un évènement de déconnexion lorsque c'est possible, ça fait partie des trucs qui vont augmenter les perfs globales, mais tu ne peux pas compter dessus pour assurer le décomptage (tu dois prendre en considération que l'évènement peux ne jamais arriver jusqu'au serveur).
Mais qd ton serveur fonctionne depuis qq mois, sans le heartbeat tu auras des clients fantômes qui ne seront pas d'augmenter.
Si tu as 1000 clients, une coupure réseau de ton FAI serveur suffisamment longue te rajoutera 1000 clients fantômes dans ton comptage.
Pour t'en convaicres, tu peux matter la doc de flexLM (ça n'a rien a voire avec as3, mais bon courage).
A+
Merci à vous, je pense que je vais opter pour le time out. Si aucune réaction au bout de ce time out, déconnection. Je vais l'appliquer, mais je vais continuer de chercher de mon côté mon idée première, voir si elle tient.
Merci et bonne journée
THE CHANGE
Toujours en quête de connaissance
WINDOWS :Oracle 11G, SQL DEVELOPER 2.2, Eclipse Ganymede 3.4 plugins VE 1.4, Flex 4
MAC OsX 10.6.5 : Oracle 10G R2 SQL DEVELOPER 1.5.4, Eclipse Helios 3.6, plugins VE 1.4, Flex 4
G mis un peu de temps à retrouver ça ... mais je pense que ça peut être utile à d'autres qui travaillent sur le sujet (faut se réveiller un peu).
-Si on considère que la déconnexion d'un client est une loi de poisson (http://www.techno-science.net/?ongle...efinition=6212 pour ceux qui veulent chauffer), ce qui est pas mal du tout sauf pour les heures creuses du serveur (ça fait trop longtemps que j'suis au boulot donc je rentre, qui est incompatible avec la loi de poisson)
-Si T est le temps moyen de connexion (ici le temps entre la première requête du client et son évènement de déconnexion)
-Soit hb le délais de heartbeat.
Sans aucune stratégie d'optimisation des perfs serveurs, on trouve facilement un majorant de la précision du nombre de clients connectés : hb/T
Par exemple, mes clients restent connectés en moyenne 1h. Mon hearbeat est de 6 min (ici mon timeout session est de 6min et toutes les 6min mon client fait un get). Je connais donc mon nombre de client à chaque instant à 10% près (6/60=0.1).
On estime facilement le temps moyen de connexion avec le session listener
lors d'un sessionDestroyed
SessionTracking peux ensuite faire une moyenne des délais comme il veut.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12 sessionDestroyed(HttpSessionEvent ev) { HttpSession session=ev.getSession(); long delay; synchronized(session) { delay=System.currentTimeMillis()-session.getCreationTime(); } SessionTracking.getInstance().registerSessionDelay(delay); }
Maintenant si une autre loi de stat intervient (coupure du réseau serveur par exemple) on est dans les choux pendant le délais de heartbeat (ici on verra que tous les clients sont KO au bout de 6 min).
Maintenant le nombre de connexions par secondes liées au heartbeat est N/hb si N est le nombre de clients. (ici pour 1000 clients ça fait environ 3 requêtes par secondes ce qui commence à faire et pour 100 000 clients on approche les 300 requêtes/sec qui me semble être la limite de conf de base pour tomcat).
Voili
Si tu as un moyen de compter plus finement (comme l'évènement de déconnexion) tu devrais l'inclure dans la boucle. Tu auras alors dans 90% des cas un comptage exacte mais en cas de coup dur tu peux compter sur le timeout.e vais l'appliquer, mais je vais continuer de chercher de mon côté mon idée première, voir si elle tient
A+
Meric l'ami, j'opte pour ta soluce... Bon après midi à tous
THE CHANGE
Toujours en quête de connaissance
WINDOWS :Oracle 11G, SQL DEVELOPER 2.2, Eclipse Ganymede 3.4 plugins VE 1.4, Flex 4
MAC OsX 10.6.5 : Oracle 10G R2 SQL DEVELOPER 1.5.4, Eclipse Helios 3.6, plugins VE 1.4, Flex 4
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager