Problème de timeout et de déconnexion cliente

Bonjour,

<<PBL RESOLU>> voir
post plus bas pour pbl actuel

----------------------------


j'ai récupéré un projet Java qui utilise Corba mais je ne connais rien du tout a cette techno. Coté serveur tout est ok mais coté client, lors de l'initialisation j'ai cette erreur :

EXCEPTION while running protocol SSOTRnull org.omg.CosNaming.NamingContextPackage.NotFound

qui est catché par le block catch suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
}catch(Exception e){
          isOrbRunning = false;
          cat.error("EXCEPTION while running protocol SSOTR"+e.getMessage()+ " " + e.toString());

=> donc e.getMessage est null

Le code qui cause cette exception est le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
org.omg.CORBA.Object rootObj = orb.resolve_initial_references(System.getProperty("resolve_initial_references"));
org.omg.CosNaming.NamingContext root = NamingContextHelper.narrow(rootObj);
    // Locate an account manager through the Naming Service.
NameComponent []path = new NameComponent[]{
     new NameComponent(System.getProperty("NameComponent"), "")
    };
    org.omg.CORBA.Object mgrObj = root.resolve(path);

Je sais (par les logs) que c'est la derniere ligne (root.resolve) qui genere l'exception mais je connais rien a corba, ca m'a l'air bien compliqué et je n'ai pas vraiment le temps non plus.

Je sais pas si vous avez assez d'infos pour m'aider, je me dis que c ptetre un probleme tellement con qu'un spécialiste corba pourra me dire en 10 sec ce que c'est ...

Merci

Je sais (par les logs) que c'est la derniere ligne (root.resolve) qui genere l'exception mais je connais rien a corba, ca m'a l'air bien compliqué et je n'ai pas vraiment le temps non plus.

Si tu n'as pas le temps, alors il ne faut pas utiliser CORBA. Ce n'est pas une technologie qui s'apprend en 5 minutes. Je te conseille vivement la lecture des FAQ CORBA et pour bien comprendre la technologie, d'un ouvrage CORBA.

Dans ton cas, tu dois simplement vérifier que ton serveur de nom est bien lancé, que ton ORB est bien installé et que ton client peut accéder au serveur de noms.

Bonjour

j'ai pu résoudre mon probleme, maintenant toute la plateforme fonctionne correctement ( le client se connecte et recoit des données).De plus j'ai suivi une petite formation a RMI/Corba qui me permet d'y voir un peu plus claire. Mais il y tjs a part un bug qui est sans doute assez général a corba : (EDIT : on utilise Visibroker sous linux)

D'un coté j'ai un composant (qu'on appellera S= Serveur) qui est donc un serceur Corba et qui recoit des données en temps réel de systèmes amonts.
d'un autre coté, j'ai mon client (C) qui se connecte en tant qu'abonné a S avec des paramatres de notification, le client demande des infos sur des données précises et quand S recoit les données adéquates, ils les renvoie a C en temps réel.
C se connecte donc a S via corba et S notifie les données a C via un callback (qui contient un numero d'identifiant).
Le probleme, c'est que quand un client se déconnecte violemment (cad qu'il n'appelle pas la methode logout qui le désabonne sur S), S ne s'apercoit pas que C n'existe plus et continue d'envoyer des données.
Ce que je comprends pas, c'est qu'aucune exception n'est générée lorsque S envoie ses données (ie il appelle la méthode cliente a distance) a C qui n'existe plus. De plus, comme S considere toujours C connecté, C ne peut plus se reconnecter.

Encore un autre probleme, lors de la notification des données de S vers C, il arrive parfoit qu'un exception Corba object not found apparaisse mais ne gene en rien la communication entre C et S.

Des réponses pour tous ces problemes?

Merci

Des réponses pour tous ces problemes?

CORBA n'est pas une méthode de communication client-serveur comme les autres. Le point le plus important pour répondre à ta question est la notion d'objet et d'instanciation d'objet qui distingue une communication CORBA d'un client serveur réseau normal. Si il n'y a plus d'objet client, il n'y a plus de communication entre le serveur et le client et c'est tout. Ce n'est pas à ton application de s'occuper de gérer les communications réseau (sauf les timeouts). Ton application s'occupe de créer des objets serveurs et d'instancier des clients et ton ORB de faire communiquer tout ca dans un environnement hétérogène en réseau.

Il semble que ce que tu cherches à faire s'apparent à un Event, et je pense que tu devrais lire les réponses que j'au donnée sur un autre thread:
http://www.developpez.net/forums/viewtopic.php?t=210860

Cordialement.

Envoyé par Sylvain.Barthelemy

CORBA n'est pas une méthode de communication client-serveur comme les autres. Le point le plus important pour répondre à ta question est la notion d'objet et d'instanciation d'objet qui distingue une communication CORBA d'un client serveur réseau normal. Si il n'y a plus d'objet client, il n'y a plus de communication entre le serveur et le client et c'est tout. Ce n'est pas à ton application de s'occuper de gérer les communications réseau (sauf les timeouts).

Mais s'il n'y a plus d'objet clients, pourquoi une exception OBJECT_CORBA NOT_FOUND n'est pas renvoyé ? J'ai eu un autre spécialiste corba par tel qui m'a dit que cette exception devait etre renvoyée si l'objet distant n'existe plus.
De plus, comme aucune exception n'est renvoyée et que le serveur continue d'envoyer ses données, ou arrive ces donnnées ?

N'y a t'il pas des parametres que l'on peut donner a l'ORB pour qu'il voit que la méthode client n'est pas accessible.

Malheureusement je suis en maintenance sur ce tres gros projet depuis 3 mois et ne connaissait rien a corba il y a encore 2 semaines, donc développer une surcouche event m'est presque impossible tout seul, et je n'ai pas le temps non plus.

Mais s'il n'y a plus d'objet clients, pourquoi une exception OBJECT_CORBA NOT_FOUND n'est pas renvoyé ?

Si tu veux pouvoir lever cette exception dans une appli temps réel, c'est au niveau du RTScheduling qu'il faut le faire. Cette exception est levée que l'objet n'est pas connu du scheduler (qui gère le timing du temps réel). Si ton client se déconnecte, ton objet est toujours connu du scheduler et il n'y a pas de raison de lever cette exception.

N'y a t'il pas des parametres que l'on peut donner a l'ORB pour qu'il voit que la méthode client n'est pas accessible.

Comment ca la méthode cliente ? Tu peux appeler une méthode client en utilisant CORBA si tu fais un callback mais sinon... J'ai l'impression que tu confonds le client et le serveur CORBA. Si ce n'est pas le cas, il faut que tu m'en dises un peu plus sur ton application pour que je puisse t'aider.

Tu as un doc pas mal fait sur le temps réel et plus généralement RT CORBA sur:
http://www.lfbs.rwth-aachen.de/rofes/01-08-34.pdf

Tu as aussi une présentation pas mal faite de RT CORBA de 140 pages sur:
http://www.ois.com/images/RTCORBA_Tutorial_2003-07_OMG_Workshop_on_DOC_for_RTES_Virginia.pdf

Enfin sur le site de l'OMG tu as un bon tutoriel sur
http://www.omg.org/news/meetings/workshops/presentations/embedded-rt2002/03-2_Aslam-Mir_1_rtws-0.pdf
Et des exemples de code sur
http://www.omg.org/news/meetings/workshops/presentations/realtime_emb_presentations/Real-time_Tutorial_Slides/RTCORBA_workshop_examples.pdf

Merci pour tout

Je confonds en effet les clients/serveurs car le serveur appelle des méthodes implémentés cotés clients via un callbak.

Par contre on m'a dit que pour détecter que l'objet distant n'existait plus, on pouvait définir une méthode partagée en plus qui n'aurait pas la propriété oneway. apparemment quand cette propriété est activée pour une méthode (en callback dans ce cas), le serveur se contente d'envoyer les données sans se soucier si son exécution se passe bien (oneway dit a la méthode de ne pas générer d'erreur/exception dans tous les cas)
On nous a donc proposée de vérifier toutes x secondes si les clients étaient présent en appelant cette méthode, ondevra donc redéfinir les idl et réimplémenter cette méthode coté client.
Je me pose tout de même un question, si on chisit cette option, on ne pourra pas mettre à jour tous les clients et certains d'entre eux n'implémenteront pas la nouvelle méthode, est ceque l'erreur généré par cette méthode non oneway sera la même si le client n'implémente pas cette méthode et si le client implémente cette méthode mais n'est plus actif ? (je ne sais pas si je très clair, ce n'est pas facile a expliquer)

Je pose cette question sans vraiment avoire regardé les docs que tu m'as mis, je me pencherais plus en détail sur tout ceci en temps voulu.

Merci tout de même

EDIT : je viens de voir que la solution proposée n'est pas bonne puisqu'on redéfinit l'interface et que certains clients n'implémenteront même pas toutes les méthodes de cette interface.

J'ai finalement pu résoudre le bug en implementant des nouvelles méthodes non oneway dans l'idl et a chaque fois que le seveur a besoin d'envoyer des données, il appelle une méthode ping qui ne fait rien, mais qui sert juste à détecter la présence du client.
Mais un autre probleme se pose : Lorsqu'un client se connecte et recoit des données, si on enleve le cable réseau du client, le serveur détecte sa déconnexion 17 min apres, alors que quand on kill le client, le serveur le voit tout de suite.
Je pensais que c'était une propriété de l'orb du client (17min= 1020 sec)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
  porper.setProperty("ORBtcpTimeOut", "1000");

mais j'ai mis a 120 et c'est pareil.

Des idées ?
merci

J'ai abordé les problèmes de timeout sur le thread suivant:
http://www.developpez.net/forums/viewtopic.php?t=219267

Si ca ne résoud pas ton problème. Donne moi le nom et la version ton ORB et je regarderai ca de plus près.

Cordialement.

Bonjour et merci

L'orb utilisé est visibroker 5 sous une linux redhat 7.3
Du coté du client (serveur web sous apache), on utilise juste la librairie vbjorb.jar
J'ai regardé l'autre topik et les différents policies utilisés, mais je n'ai acces a aucune d'entre elle sur le client. je me demande si c'est pas visibroker qui interdit l'usage des policies d''origine.
les policies définit actuellement sont

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
rootPOA.create_lifespan_policy(LifespanPolicyValue.TRANSIENT),
rootPOA.create_request_processing_policy(RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY),
      rootPOA.create_id_assignment_policy(IdAssignmentPolicyValue.USER_ID)

Par contre j'ai trouvé cette doc
http://info.borland.com/techpubs/bes/v6/html_books/vbjava_dg/clients.html
qui explique comment gérer les timeout en visibroker. (milieu de page)

J'ai copier-coller le code en l'adaptant (coté client et serveur) mais rien a faire, toujours 16-17 mn (956sec au dernier essai :o)
Je vais continuer d'autres tests demain.

J'avoue qu'avec tout ce que tu sembles avoir essayé, c'est assez bizarre que ca ne fonctionne pas cette histoire de timeout. Je te laisse regarder et si tu ne trouves pas, viens peut être inscrire le bout de code que tu utilise pour le timeout, la ligne de commande pour lancer le serveur et les version des softs clients et serveur. De mon côté, si j'ai tout ce qu'il faut, j'essaierai de reproduire ca quand j'aurai un moment.

J'ai rajouté la propriété porper.setProperty("ORBtcpTimeOut", "120"); du coté du serveur en parametre de orb.init() selon la recomandation d'un collegue, c'est toujours pareil.
Je ne sais plus quoi faire comme test, la déconnexion est toujours détecté en environ 15-17 min (selon les logs)....

Je récapitule

Serveur : JDK 1.3.1, visibroker 5 sous linux redhat 7.3
commande de lancement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
vbj  -VBJjavavm java -Xmx800m -DORBpropStorage=$APPLI_PARAM/vbj.properties -Dvbroker.se.iiop_tp.scm.iiop_tp.listener.port=1200 -DORBInitRef=NameService=iioploc&#58;//localhost&#58;6131/NameService com.<XXXXX>.Controleur $APPLI_PARAM/ssotr.properties  &

$APPLI_PARAM est un répertoire qui contient les fchiers de config

Client : serveur web sous Apache Tomcat 4.0 sous windows 2000 utilisant la librairie vbjorb.jar

A l'initialisation de l'orb, coté serveur ET client, j'utilise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
proper.setProperty("ORBtcpTimeOut", "120"); 
orb = ORB.init(args, proper);

Le client s'abonne a des données et le serveur lui envoie les infos via un callback.
Au bout de 16 min, je vois ceci dans les logs du serveur
[Problème de notification de l'abonnement (PB DE COM): 1 (utilisateur AM) -> org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Aucun chemin d'accès pour atteindre l'hôte cible: Aucun chemin d'accès pour atteindre l'hôte cible minor code: 0 completed: No]

bout de core serveur pour l'init de l'orb

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Properties ORBproperties = new Properties();
ORBproperties.setProperty("ORBtcpTimeout","120");
orb_ = org.omg.CORBA.ORB.init(argv_, ORBproperties);

org.omg.CORBA.Object rootPoaObjet = orb_.resolve_initial_references("RootPOA");
rootPOA_ = POAHelper.narrow(rootPoaObjet);

org.omg.CORBA.Policy[] policies ={
rootPOA_.create_lifespan_policy(	LifespanPolicyValue.PERSISTENT),
rootPOA_.create_id_assignment_policy(IdAssignmentPolicyValue.USER_ID)};

connectionPOA_ = rootPOA_.create_POA(
poaConnectionName, rootPOA_.the_POAManager(), policies);

si on enleve le cable réseau du client, le serveur détecte sa déconnexion 17 min apres, alors que quand on kill le client, le serveur le voit tout de suite.

Si tu enlèves un cable, il n'y a pas que l'ORB qui intervient mais aussi le système. Si tu es sous Windows, essaies de retirer le "Media Sens for TCP/IP" avec la clé de registre DisableDHCPMediaSense:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Tout es bien expliqué ici:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q239924

Sinon, juste par curiosité, pourquoi veux tu gérer la possibilité de déconnexion d'un cable ? C'est une application critique ? Si c'est le cas, il faut peut être envisager un clustering et plutot une machine Unix.

Amicalement.

Je viens d'essayer mais comme je le pensais, ca ne change rien car je voudrais que ce soit le serveur linux qui détecte l'arrachage du cable du client sous windows. Peut-être il ya-t il la même configuration à faire sous linux?

Sinon, ce n'est pas une application si critique, mais en cas de coupure réseau même minime (gros réseau WAP) entre client et serveur, le fait que le client puisse se reconnecter seulement 17' après la coupure ne serait pas très bien vu chez le client :p

Et je n'ai pas le choix des machines car je suis en maintenance, et il a été décidé des OS utilisés et des soft il ya bien longtemps deja.

Je viens d'essayer mais comme je le pensais, ca ne change rien car je voudrais que ce soit le serveur linux qui détecte l'arrachage du cable du client sous windows... Sinon, ce n'est pas une application si critique, mais en cas de coupure réseau même minime (gros réseau WAP) entre client et serveur, le fait que le client puisse se reconnecter seulement 17' après la coupure ne serait pas très bien vu chez le client :p

Je ne sais pas comment est gérée ton application mais il serait plus simple que se soit le client qui se rende compte que le cable n'est plus connecté et qui tente une reconnexion. Par principe, sauf exception, sous CORBA, le serveur ne s'occupe pas de savoir comment les clients font pour se connecter aux objets hébergés.

Si tu veux détecter un problème de cable réseau sur ton client, le plus simple serait peut être de faire un petit module de ping à intervalles réguliers sur le serveur. On fait ca en général en implémentant une méthode ping sur un objet serveur qu'on appelle quand on a besoin de vérifier la connexion. On installe en même temps un timeout pour éviter qu'elle boucle si l'objet n'est plus accessible.

J'avoue que je bute un peu car je ne comprend pas bien comment fonctionne ton application et si elle est basée sur des Events ou pas.

En tout les cas, je pense que la méthode du callback pour ce genre d'application, surtout si c'est du temps réel, est à proscrire au profit d'une gestion temps réel à l'aide d'Events qui me parait beaucoup plus adaptée. Voici une liste de docs:
http://www.cs.wustl.edu/~schmidt/events_tutorial.html
http://www.ittc.ku.edu/workshops/spartan/1998/levine.pdf
http://www.opengroup.org/rtforum/oct2000/slides/corba.pdf
http://www.omg.org/news/meetings/workshops/presentations/embedded-rt2002/03-2_Aslam-Mir_1_rtws-0.pdf
http://www.comp.lancs.ac.uk/computing/users/geoff/GOPI/gopi_paper2.pdf
http://www.omg.org/news/meetings/workshops/presentations/realtime2001/4-1_O'Ryan_OMG_RT01.pdf

Je suis d'ailleurs en train d'écire une doc sur les Events mais je ne l'ai malheureusement pas terminée.

Cordialement.

Le fait que le client puisse se reconnecter tout seul était le tout premier probleme à l'origine du topik, mais c vrai que ca fait deja presque 2 mois.
Depuis j'ai réussi a résoudre le pbl justement en rajoutant une méthoe non oneway ping() que j'appelle avant chaque envoie de données au client et l'exception comm_failure est donc renvoyée au bout de 17 minutes qd on enleve le cable du client, alors qu'une exception apparait tout de suite lorsqu'on kill le client. Par contre je n'ai pas mis de timeout en particulier sur la méthode ping et je ne sais pas comment en mettre un sur une méthode en particulier, je vais regarder.

On a un callbak sur le client mais pas de gestion d'event.
Le probleme avec ce projet, c'est que comme je suis en maintenance corrective, je ne peux quasiment rien toucher au niveau de l'architecture, choix pris lors du développement et de l'analyse, donc je suis obligé de faire avec les choix du début. Ca m'a meme étonné que mon chef m'ait permis de touchers aux idl pour rajouter deux méthodes non one-way.

Par contre je viens de m'apercevoir (totalement au hasard) que lorsqu'on enleve le cable du client, et qu'on le reconnecte 5 min apres, les deux machines re-arrivent à dialoguer avec l'ancienne session. Cela suffira peut-etre, il faudra juste que je regarde comment seront gérées les données arrivé en retard coté client

Cordialement

Aurélien

Je ne sais pas quels ORB tu utilises, mais est ce que tu as essayé de faire quelque chose comme ca ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
CORBA::Environment& env;
CORBA::Long timeoutValue = ...;
Bank_var bVar;
try {
  env.timeout(timeoutValue);
  bVar = Bank::_bind(":AIB","",env);
}
catch (const CORBA::COMM_FAILURE&) {
  cout << "--- Timed out after " << timeoutValue
      << "msecs..." << endl;
&#125;

Pour l'instant on va garder le comportement que j'ai décrit juste au dessus.
si jamais on a besoin de mieux faire, je garde cette info dans un coin

Merci.

Une petite précision, tu peux le faire aussi pour tous les appels distants:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
//C++
    // In class CORBA::ORB.
    unsigned long defaultTxTimeout
      (CORBA::ULong val, CORBA::Environment& IT_env =
        CORBA::IT_chooseDefaultEnv())