Discussion :

[L'elfe d'Azur]

Bonjour,

dans mon application, j'ai besoin d'arreter parfois un processus client sauf que celui-ci partage des donnees via CORBA avec mon serveur.

Quand je parcours ma liste dans le serveur, bien evidemment certaines variable ne sont plus accessible sauf que je ne sais pas quel test utiliser pour les identifier (et nettoyer mon std::vector<corba_var> ).

Recuperer l'exception pour supprimer cet element n'est pas la meilleur facon de faire mais elle fonctionne.
J'ai essayer de verifier avec CORBA::is_nil(corba_var) ou carba_var->_nil() mais il ne detecte pas que l'instance n'est plus disponible.

Si quelqu'un a connait une methode qui m'eviterai de recuperer l'exception ce serait super.

Merci beaucoup

[CorbAddict]

Bonjour,

dans mon application, j'ai besoin d'arreter parfois un processus client sauf que celui-ci partage des donnees via CORBA avec mon serveur.

Quelles sont ces données ?
Si ce ne sont pas des objets CORBA (i.e. implémentation d'une interface définie en IDL) alors le serveur a une copie des données. En effets tout les types basiques, struct, sequence... sont passés par copie du client au serveur.

Quand je parcours ma liste dans le serveur, bien evidemment certaines variable ne sont plus accessible sauf que je ne sais pas quel test utiliser pour les identifier (et nettoyer mon std::vector<corba_var> ).

Donc je crois comprendre que ce sont des objets CORBA implémentés par le client. Effectivement, lorsque le client n'est plus là, un appel à ces objets provoque une exception CORBA::TRANSIENT.

J'ai essayer de verifier avec CORBA::is_nil(corba_var) ou carba_var->_nil() mais il ne detecte pas que l'instance n'est plus disponible.

Ca ne peut pas marcher. Lorsque le client disparaît, l'objet CORBA qu'a le serveur ne change pas (il ne passe pas à nil). En effet cet objet CORBA n'est qu'un proxy encapsulant l'adresse (IP+port+identifiant) du véritable objet implémentant l'interface IDL.

Si quelqu'un a connait une methode qui m'eviterai de recuperer l'exception ce serait super.

Une autre solution est d'appeler CORBA::Object::_non_existent() et de vérifier si ça retourne false (i.e. l'objet existe bien et répond). Mais cette opération peut aussi lever une exception (TRANSIENT, COMM_FAILURE...).
Et rien ne dit que juste après cet appel le client ne va pas s'arrêter...
Donc: toujours récupérer les exceptions lors d'un appel distant !

[L'elfe d'Azur]

Je ne connaissais pas la methode CORBA::Object::_non_existent()

Trouver sur le site de support d'OmniORB

Using omniORB4 i get the right behaviour;
_non_existent returns true, if the object
has been deactivated, and i get a transient
exception, if i kill the server.
I do agree, that one of the points of using
_non_existent is to avoid getting an OBJECT_NOT_EXIST
exception, but TRANSIENT and COMM_FAILURE are
ok, since one can not conclude, that an object
does not exist based on inability to reach it.

Donc apparement c'est normal que meme avec cette methode je recupere une exception CORBA::TRANSIENT.

Je vais rester sur mon catch d'exception.

Merci de ton aide