Support – Foire aux questions – L’ORB ACE

Support - Foire aux questions - L'ORB ACETAO FAQ

UNE:

Ceci est une FAQ pour The ACE ORB (TAO), un CORBA ORB open-source né de la recherche à l’Université de Washington à St. Louis ‘Center for Distributed Computing Object (http://www.cse.wustl.edu/

doc /). Si votre question n’a pas de réponse ici, vous voudrez peut-être consulter les liens suivants:

  • http://www4.informatik.uni-erlangen.de/

geier / corba-faq / index.html est un CORBA général FAQ

  • http://groups.yahoo.com/group/tao-users est une archive du groupe DOC tao-liste de diffusion
  • Nous fournissons un soutien au BEC de qualité commerciale pour cette ORB, ainsi que la documentation et des services de consultation (voir notre page Web à l’adresse http://www.ociweb.com pour plus de détails), et de fournir le site et le contenu de cette FAQ comme libre service à la communauté TAO.

    Si vous avez des questions, et surtout si vous avez des réponses à eux, s’il vous plaît envoyez-les à support@ociweb.com pour l’inclusion dans cette FAQ! Faites-nous savoir si vous souhaitez être crédité de la réponse et, si oui, comment.

    Q:

    Où puis-je trouver le code source pour les exemples dans le Guide du développeur TAO?;

    UNE:

    Le code source pour tous les exemples dans les versions récentes du Guide du développeur OCI TAO est disponible dans la distribution du code source OCI TAO, elle-même. Voir ACE_wrappers / TAO / DevGuideExamples /. Pour les anciennes versions de TAO et le Guide du développeur TAO. le code source pour les exemples peuvent être téléchargés à partir de notre site Web. Voir http://www.theaceorb.com/downloads/index.html pour plus de détails.

    Q:

    UNE:

    Selon votre situation, il peut y avoir plusieurs avantages à l’achat Distribtution d’OCI de TAO plutôt que de suivre de près les kits de code source bêta:

    • La stabilité. Répartition de l’OCI de TAO est basé sur une version stable, testée et prise en charge de TAO. Si vous avez besoin, une version solide cohérente de TAO sur lequel baser votre produit ou d’un projet, ceci est l’un pour vous. Si vous avez besoin pour rester au courant des nouvelles orientations de recherche ou si vous voulez essayer les dernières fonctionnalités, vous pouvez toujours obtenir des kits bêta TAO en forme de code source en visitant http://download.dre.vanderbilt.edu/.
    • Gain de temps. Achat et installation d’une distribution binaire prebuilt de TAO, plutôt que de télécharger le code source et construire vous-même, pouvez-vous épargner des heures de travail. En outre, vous pouvez être sûr qu’il a été construit correctement et testé sur plusieurs plates-formes, systèmes d’exploitation et les compilateurs, et dans plusieurs configurations différentes.
    • Assistance à l’installation. OCI fournit 90 jours de support d’installation pour les acheteurs enregistrés de distributions binaires précompilés de TAO. Nous voulons nous assurer que vous êtes opérationnel avec TAO le plus rapidement possible.
    • Documentation. Utilisation de la distribution de l’OCI de TAO est facile avec le Guide de TAO Développeur d’OCI (disponible à l’achat à http://www.theaceorb.com/purchase/index.html). En plus de l’ensemble de la documentation, vous pouvez consulter les dernières notes de TAO à http://www.theaceorb.com/releasenotes/index.html.
    • Questions fréquemment posées. OCI maintient une liste de questions fréquemment posées au sujet de TAO. Cette liste est mise à jour régulièrement par notre personnel de distribués ingénieurs en technologie objet informatique pour fournir des réponses aux questions courantes sur l’utilisation de TAO. Toute personne dans la communauté des utilisateurs TAO peut contribuer aux questions (et réponses) à la FAQ. Vérifiez d’abord pour voir si votre question a déjà été posée. La FAQ est situé à http://www.theaceorb.com/faq/
    • Professional support. Si vous avez besoin d’un soutien supplémentaire, au-delà des problèmes d’installation ou des questions fréquemment posées, telles que la formation de la technologie objet, conseil, mentorat, ou le développement d’applications, OCI a plusieurs offres de services pour vous. Visitez http://www.ociweb.com pour plus d’informations.

    Q:

    UNE:

    Non. La documentation nécessaire comprend uniquement le Guide propre TAO Developer OCI.
    CD contenant les versions préconstruits de TAO pour plusieurs plates-formes sont disponibles séparément.

    Q:

    UNE:

    En plus du code source complet pour ACE et TAO, le CD ensemble OCI comprend des bibliothèques pré-construits pour ACE, TAO, et les services CORBA de TAO, plus executables pour le compilateur IDL de TAO, gperf et serveurs pour les différents services.

    Le jeu de CD contient ces composants pré-construits pour de nombreuses plates-formes populaires, les systèmes d’exploitation et les compilateurs C de.

    En outre, le construit sur le plateau de CD comprennent plus d’une configuration de construction (par exemple de débogage ou désactiver, C ++ soutien d’exception native ou désactiver).

    Notez que le jeu de CD ne comprend pas les binaires pré-compilés des différents tests, tests de performance, et des exemples qui viennent avec ACE et TAO, mais le code source complet pour eux est là.

    Donc, si vous installez TAO à partir du CD OCI fixé pour l’une des combinaisons plate-forme existante / système d’exploitation / compilateur, vous pouvez commencer à écrire, la construction et l’exécution de vos propres applications qui utilisent TAO tout de suite.

    Bien sûr, puisque vous avez le code source complet, vous pouvez coutume construire vous-même (par exemple pour une plate-forme particulière, le système d’exploitation, compilateur, ou la configuration qui ne figure pas sur le CD).

    Q:

    Ils sont la table des matières et Index pour le Guide du développeur TAO disponibles en ligne?

    UNE:

    La table des matières et Index pour le Guide de TAO Developer d’OCI sont disponibles sous forme de PDF via:

    Il suffit de suivre les liens appropriés pour télécharger les fichiers que vous souhaitez.

    UNE:

    Il est possible d’installer à la fois le débogage et libérer les versions de TAO sur une machine Windows en sélectionnant un répertoire d’installation différent pour chaque installation et la mise en $ ACE_ROOT et $ TAO_ROOT appropriée. Plus efficienty, les versions de débogage et de libération de TAO peut être installé dans le même répertoire depuis les différentes versions des bibliothèques ont des noms légèrement différents.

    Q:

    UNE:

    Les DLLs sur le CD comprennent toutes les informations dont vous avez besoin pour déboguer les applications TAO. Ces informations sont normalement stockées par Visual C ++ dans les fichiers .pdb. Notre construit les stocker dans le fichier .dll d’une manière indépendante de l’emplacement (en utilisant l’option compatible C7 pour les informations de débogage). Cela vous permet de faire un pas dans le code TAO dans le C ++ débogueur Visual.

    Si vous désirez un plus petit ensemble de bibliothèques, soit installer les versions de libération du CD ou de reconstruire les bibliothèques de débogage avec la configuration de débogage par défaut.

    Q:

    UNE:

    Vous êtes toujours les bienvenus pour envoyer une question. Cependant, la disposition de votre demande dépend si oui ou non vous avez un contrat de support technique avec OCI:

    • Si vous avez un contrat de support technique avec OCI, quelqu’un va commencer à répondre à la question et sera suivi avec vous selon les dispositions énoncées dans votre contrat de support.
    • Si vous ne disposez pas d’un contrat de support technique avec OCI, quelqu’un va encore examiner la demande de soutien et peut revenir à vous, mais nous ne pouvons garantir que nous aurons le temps de travailler sur le problème sans un contrat de support.

    Si vous souhaitez ouvrir un contrat d’assistance technique avec OCI, s’il vous plaît contacter notre équipe de vente au sales@ociweb.com ou appelez +1.314.579.0066 poste 206. S’il vous plaît consulter http://www.theaceorb.com/support pour une description de le modèle de soutien TAO.

    Q:

    UNE:

    Voici quelques façons courantes d’utiliser l’option -ORBInitRef pour localiser le Naming Service (où bart est juste un nom d’hôte par exemple):

    # Stockez l’IOR du nommage racine contexte de nommage de service dans un fichier:

    # Spécifiez un point de terminaison IIOP lorsque vous démarrez le service de nommage:

    Vous pouvez également utiliser la variable d’environnement NameServiceIOR pour atteindre le même effet. Ici, nous montrons ce qu’il pourrait ressembler sur un système UNIX ou UNIX en utilisant le shell bash:

    Maintenant, lorsque votre client appelle resolve_initial_references ("NameService"). multidiffusion ne sera effectuée. L’option -m 0 se multicast off dans le serveur Naming_Service. Ceci est la valeur par défaut dans les versions TAO 1.1.17 et versions ultérieures. Les versions antérieures par défaut à la multidiffusion sur le serveur.

    Q:

    UNE:

    Il peut y avoir une multitude de raisons, dont beaucoup sont liés à des problèmes de réseau ou au niveau du système d’exploitation plutôt que TAO. Essayez de mettre sur -ORBDebugLevel 5 pour obtenir une idée de ce qui pourrait se produire en interne.

    UNE:

    Tout d’abord, nous sommes des développeurs de logiciels et non pas des avocats. Nous pourrions être en mesure d’écrire un bon logiciel, mais il faut un esprit beaucoup plus tordu que le nôtre pour comprendre la réglementation américaine sur l’exportation, en particulier sur les questions de cryptographie et de sécurité. Par conséquent, si vous avez des préoccupations, vous devriez consulter votre avocat.

    Cela dit, vous pouvez regarder http://www.bis.doc.gov/Encryption/ pour des informations actuelles du gouvernement des Etats-Unis si vous êtes sous sa juridiction.

    Q:

    UNE:

    Les emballages de ACE_SSL ne fournissent pas une méthode (s) API ou wrapper pour ce faire. Cependant, vous pouvez définir une fonction de rappel de passe en utilisant manuellement les fonctions OpenSSL. Par exemple, quelque chose comme ce qui suit devrait fonctionner:
    où "your_callback" est un pointeur à votre fonction de rappel passwork PEM. Voir lt; openssl / ssl.hgt; et lt; openssl / pem.hgt; pour la signature de la fonction de rappel nécessaire.

    Q:

    UNE:

    Si vous souhaitez créer et utiliser des certificats DSA, il y a un certain nombre de choses qui doivent être fait pour que cela fonctionne avec SSLIOP. Lors de l’utilisation des certificats DSA vous devez spécifier les paramètres DH. Vous pouvez le faire en obtenant le contexte SSL avant que les connexions sont effectuées à l’aide de l’ORB. Ceci est TAO spécifique donc pas portable vers d’autres ORB. Vous devez d’abord obtenir un ensemble de paramètres DH. Vous pouvez générer ces lors de l’exécution (ce qui prendra un temps très long), ou de générer eux une fois avec l’outil openssl et ajoutez-les à la fin de votre certificat.
    Cela va ajouter les paramètres DH 512 bits à la fin du fichier cert.pem. Après avoir créé ces paramètres, vous aurez besoin de les charger dans votre application.
    Cela devrait l’être. Ceci définit les paramètres DH nécessaires pour utiliser un certificat DSA avec SSLIOP. S’il vous plaît noter qu’un plus grand degré de contrôle d’erreur doit être fait que ce qui est prévu dans le présent code.

    Q:

    UNE:

    Lorsque la sécurité est activée dans le ORB d’un client CORBA, toutes les invocations seront tentées en utilisant une connexion sécurisée. Cependant, le service de nommage par exemple ne peut pas être configuré pour utiliser la sécurité. Invocations à ce service de nommage entraînera une exception CORBA :: INV_POLICY puisque le client est incapable de faire une invocation sécurisée / protégé que la non-sécurité activée Naming Service.
    Pour corriger ce problème, les invocations protégées par la référence de l’objet du service de nommage doivent être désactivées. Ceci est réalisé par la fixation d’un remplacement de la politique sur la dénomination référence d’objet de service comme ceci:
    Ceci est basé sur le test de Secure_Invocation code côté client de TAO en $ TAO_ROOT / orbsvcs / tests / Sécurité / Secure_Invocation / client.cpp. (TAO 1.2 ou mieux)
    Le code de priorité de la politique ci-dessus est standard et devrait être portable à tous les ORB qui soutiennent la politique SecurityLevel2 :: QOPPolicy qualité de protection côté client.
    Ne pas oublier d’inclure "orbsvcs / SecurityC.h" (Ce qui est TAO-spécifique) pour tirer dans les constantes et les types de politiques liées à la sécurité qop.

    Q:

    UNE:

    Utilisez l’interface AccessDecision du service de sécurité. Il est disponible via TAO / orbsvcs / orbsvcs / SecurityLevel2.idl. Un exemple d’utilisation de cette interface est fournie dans TAO / orbsvcs / Sécurité / mixed_security_test.

    L’interface AccessDecision donne la possibilité d’affaiblir les exigences de sécurité pour les références d’objets désignés. Voir ici, son fonctionnement unique est destiné à être appelé à partir d’un intercepteur, ou peut-être à partir d’un serviteur.

    TAO étend également cette interface afin de permettre la configuration d’exécution de l’objet AccessDecision fourni, pour ajouter ou supprimer des objets pour examen.

    En plus d’ajouter des opérations pour ajouter ou supprimer des références d’objet pour examen par l’objet AccessDecision, un accès étendu a permis le fonctionnement est également fourni, de travailler autour d’un déficit en comparant des références d’objet. Pour TAO, les références d’objets sérialisés ne peuvent pas être utilisés à titre de comparaison, car elles sont produites en utilisant le codage CDR. Ce codage utilise des octets de remplissage pour l’alignement des valeurs multi-octets, et les octets de remplissage sont non initialisée, ce qui signifie qu’ils contiennent des données aléatoires, et donc ne peut pas être utilisé lorsque l’on compare deux références d’objets sérialisés.

    En règle générale, votre application va initialiser l’objet AccessDecision en lui fournissant des informations permettant d’identifier sans ambiguïté la référence de l’objet, et de compter sur l’intercepteur intégré pour effectuer l’appel à access_allowed. L’intercepteur de sécurité de TAO, fourni dans le cadre de la bibliothèque TAO_Security, va d’abord vérifier avec l’objet AccessDecision pour voir si l’accès sans restriction est autorisée, et sinon ensuite évaluer la demande sur la base des règles d’accès sécurisé réguliers.

    Il est possible de mettre en œuvre votre propre objet AccessDecision pour fournir encore plus de contrôle, telles que les restrictions sur la base du contenu des informations d’identification fournies, et même sur un niveau par opération.

    Pour utiliser l’interface AccessDecision, vous devez d’abord obtenir une référence au gestionnaire de sécurité de niveau 2 de l’ORB. A partir de ce que vous obtenez le AccessDecision, et enfin étroite à un TAO :: référence SL2 :: AccessDecision.

    À ce stade, vous fournissez les références d’objets pour examen. Il est préférable de le faire lorsque vous créez les références de sorte que vous ne devez pas garder une trace de l’information requise.

    À ce stade, vous êtes prêt à aller, l’opération de AccessDecision :: access_allowed ajoute effectivement une -SSLNoProtection SSLIOP attribut uniquement sur les références d’objets ajoutés à l’objet AccessDecision.


    Boostrapping et mécanismes de découverte

    Q:

    UNE:

    Au lieu de références d’objets de liaison avec le service de nommage et exiger des clients de les résoudre par nom, vous pouvez le rendre possible pour les clients de se lier directement à des objets en utilisant CORBA :: ORB :: resolve_initial_references (). le même mécanisme utilisé pour se lier à d’autres objets importants, tels que le service de nommage.

    Par exemple, supposons que vous avez un serveur qui fournit un objet Bank (appelons-le "CORBABank"). Plutôt que de se lier cet objet par son nom dans un contexte de nommage dans le service de nommage, vous souhaitez aux clients d’accéder directement en appelant simplement

    Il y a plusieurs façons d’y parvenir.

    1. lier directement la référence d’objet dans la liste de l’ORB client de références en utilisant une fonction () initialiseur de ORB et les ORBInitInfo :: register_initial_references.
    2. Utilisez register_initial_reference () la fonction de membre de l’ORB du client.
    3. Utilisez l’option d’initialisation -ORBInitRef ORB sur le ORB client

    Les étapes suivantes décrivent une façon d’utiliser la troisième méthode décrite ci-dessus.

    1. Dans le serveur, générer un IOR de l’objet cible comme d’habitude.
    2. Donnez l’objet CORBA simple clé d’objet en enregistrant son IOR dans IOR Tableau de l’ORB du serveur (voir Comment puis-je utiliser un "corbaloc" Référence de l’objet avec un serveur TAO? pour plus de détails)
    3. Démarrez le serveur écoute sur un critère particulier en utilisant l’option -ORBListenEndpoints.
    4. Démarrez le client avec l’option -ORBInitRef et attribuer le nom du service à la simple référence corbaloc style de l’objet CORBA.
    5. Dans le client, appelez resolve_initial_references () et transmettre le nom du service.

    La combinaison de la clé d’objet simple et le point de terminaison fixe nous permet de référencer l’objet via une référence corbaloc de style dans l’option -ORBInitRef.

    Par exemple, nous pouvons commencer nos processus comme suit:

    Où BankObject est la clé de simple objet assigné à l’objet CORBA dans le serveur.

    Maintenant, sur le côté client, nous pouvons utiliser resolve_initial_references ("CORBABank") Pour lier directement à l’objet Banque vivant à l’intérieur du serveur Banque. Par exemple:

    Notez que sur les anciennes versions de TAO (avant 1.1.10) le format de référence d’objet est légèrement différent:

    Q:

    UNE:

    Remarque: On a ajouté la référence d’objet de style corbaloc à la norme CORBA via la spécification Interoperable Naming Service. Pour plus d’informations sur "corbaloc", Voir le 2.3.1 CORBA (ou plus tard) la spécification, l’article 13.6.6.

    TAO a ajouté le support pour les références de corbaloc dans la version 1.1.10. Avant cela, TAO pris en charge une version antérieure de la spécification qui a utilisé le format iioploc. Vous pouvez utiliser des références de corbaloc de contacter les serveurs construits avec toutes les versions de TAO (en supposant que l’ORB client les soutient).

    Pour simplifier l’utilisation si les références d’objets corbaloc, vous pouvez enregistrer votre objet CORBA dans la table IOR de l’ORB du serveur de sorte qu’il peut être localisé par l’intermédiaire d’une clé d’objet simple. Pour lier une référence d’objet à cette table dans les versions actuelles de TAO (1.1.10 et versions ultérieures):

    Vous devrez également #include "tao / IORTable / IORTable.h" et le lien avec la bibliothèque TAO_IORTable.

    Dans les anciennes versions de TAO (1.1.9 et avant) cette liaison est réalisée via le code suivant:

    Ces deux techniques permettent des références d’objets corbaloc de style pour localiser l’objet CORBA spécifié via une clé objet simple ("CORBABank"). La référence de l’objet de la Banque ne doit pas nécessairement être une référence d’objet persistant, mais il peut être. Pour plus d’informations sur les références d’objets persistants, voir Comment puis-je faire mes références d’objets persistants ?.

    Quand nous courons le serveur TAO, nous devons nous assurer qu’il écoute sur un hôte et le port qui sont connus pour le client. Nous utilisons -ORBListenEndpoints de ligne de commande l’option TAO pour ce faire. Le format de -ORBListenEndpoints est

    Par exemple, si je fais tourner mon serveur sur l’hôte "myhost", À l’écoute sur le port 11019:
    Lors de l’exécution du client, nous allons utiliser un "corbaloc" Référence de l’objet. Le format de la "corbaloc" Référence de l’objet est
    Par exemple:
    se connecte au serveur sur l’hôte "myhost" au port de 11019, et trouve la référence de l’objet dans le serveur correspondant à la "CORBABank" clé. Cette référence d’objet peut être transmis à ORB :: string_to_object (), puis est utilisé comme toute autre référence d’objet.

    Q:

    UNE:

    Dans la terminologie CORBA une référence d’objet transitoire est celle qui est seulement bon pour la durée de vie de l’exécution d’un serveur donné. Si vous exécutez un serveur, distribuer une référence passagère à un client, puis tuer le serveur, puis la référence d’objet est désormais inutile (même si le serveur est redémarré). Une référence persistante permet de continuer à utiliser la référence même si le serveur est redémarré.
    Afin de rendre vos références d’objets persistants, vous devez faire ce qui suit dans votre serveur:

    1. Créer un POA enfant avec les politiques PERSISTANTS et user_id.
    2. Créer un ObjectId pour chaque serviteur utilisant PortableServer :: string_to_ObjectId ().
    3. Activez l’objet dans le POA de l’enfant en utilisant activate_object_with_id ().
    4. Démarrez le serveur écoute sur un critère particulier en utilisant l’option -ORBListenEndpoints.

    Tout cela est CORBA standard, sauf pour l’étape 4, ce qui nécessite une option spécifique à ORB. Une alternative à l’étape 4 est d’utiliser le référentiel de mise en œuvre.
    Par exemple:

    Depuis la référence de l’objet de la Banque est un IOR persistante, lorsque nous invoquons le serveur de la Banque, nous avons besoin de spécifier un critère particulier pour l’ORB. Par exemple:

    Maintenant, tous les clients qui reçoivent ces références d’objets peuvent les utiliser entre les différents passages du serveur. Notez que vous devez toujours redémarrer manuellement le serveur, sauf si vous utilisez le référentiel de mise en œuvre.

    Q:

    UNE:

    Vous devez utiliser l’option -ORBListenEndpoints. Pour plus de détails, s’il vous plaît consulter le Guide du développeur TAO. le chapitre sur "ORB Options d’initialisation." Alternativement vous référer à $ TAO_ROOT / docs / Options.html.

    La réponse courte est:

    La partie V.v de @ de cette syntaxe informe le serveur d’utiliser une version spécifique majeur et mineur du protocole spécifié. Par exemple, pour forcer un serveur à utiliser IIOP v1.1 (au lieu de la v1.2 par défaut) sur un hôte nommé "barney" sur le port 22000:

    Si vous voulez toujours forcer l’utilisation de IIOP 1.0 ou 1.1, vous pouvez définir les valeurs de macro suivantes et reconstruire TAO (et votre application):

    #define TAO_DEF_GIOP_MAJOR 1
    #define TAO_DEF_GIOP_MINOR 0 [ou 1]

    Ces macros sont généralement définies dans $ TAO_ROOT / tao / orbconf.h ou $ ACE_ROOT / As / config.h.
    Correction à la "-ORBListenEndpoints" syntaxe. Il devrait être:
    -ORBListenEndpoints iiop: //1.0@~~number=plural [hôte] [: port]
    Le nom d’hôte est pas toujours nécessaire.

    Q:

    UNE:

    Par défaut, TAO tente d’utiliser efficacement tous les fils qui lui sont données. Ceci comprend "client" les discussions qui ont envoyé une demande et sont en attente d’une réponse du serveur. En attendant, ces fils entrent dans le pool de threads boucle d’événement normal du réacteur. Cela signifie que toutes les demandes entrantes (en supposant que le processus est également un serveur) peuvent être envoyés en utilisant ce fil. Une telle situation est appelée "upcall imbriquée".

    Cela a quelques effets secondaires qui surprenne beaucoup de gens. Tout d’abord, il est possible pour un seul serveur fileté pour traiter plus d’une demande au même moment. Deuxièmement, si vous essayez d’affecter les discussions exclusivement comme "serveur" threads et "client" threads, l’ORB ne faites pas attention à votre idée de ce que ces discussions sont et demandes d’expédition sur les deux.

    Pourquoi est-ce le comportement par défaut de TAO? Principalement parce que de nombreux appels ascendants imbriqués éviter les situations de blocage potentiels. Un exemple est une opération de rappel simple avec un client seul thread. Lorsque le client envoie une requête au serveur, le serveur envoie une demande de rappel au client. Si seulement thread du client attend la réponse et non l’envoi des demandes entrantes, puis une impasse est maintenant en place. Le comportement par défaut permet à l’ORB client pour traiter la demande de rappel et d’envoyer une réponse au serveur qui libère l’ORB du serveur pour envoyer sa réponse au client.

    Il existe cependant des situations où vous voudrez peut-être pour éviter imbriqués appels ascendants dans votre application. Voici quelques raisons courantes sont:

    • applications en temps réel qui imposent des temps de réponse strictes.
    • La limitation des ressources qui imposent des limitations de concurrence.
    • Temps de réponse court. La réponse sera tamponnée jusqu’à ce que le upcall imbriquée dévide.
    • récursifs imbriqués appels ascendants peuvent conduire à la croissance de la pile sans bornes, qui finira par bloquer l’application.

    Voir l’article Comment puis-je empêcher imbriqués dans appels ascendants ma demande? pour des techniques pour empêcher appels ascendants imbriquées.

    Q:

    UNE:

    Comme indiqué dans l’entrée Pourquoi mon "client" enfilez l’envoi des demandes? il y a des situations où l’on peut vouloir désactiver imbriqués appels ascendants dans notre application. Il existe plusieurs techniques disponibles pour prévenir appels ascendants imbriquées. Ceux-ci sont:

    • Utilisez le Recevez-Wait (RW) attendre la stratégie.
    • Employez la Deux ORB Solution.
  • La stratégie RW d’attente est le plus populaire et probablement le mécanisme le plus facile à prévenir appels ascendants imbriqués. Vous pouvez modifier la stratégie d’attente par défaut du client via le -ORBWaitStrategy (anciennement connu sous le nom -ORBClientConnectionHandler) Configurateur de service option.Specifying un "rw" attendre la stratégie provoque threads en attente de réponses pour ne pas entrer dans la boucle d’événement normal et au lieu de bloquer leur réponse en attente. Cela permet de maintenir l’ORB de l’envoi des demandes entrantes sur votre "client" threads. Un effet secondaire de cette option est que votre client est maintenant plus sensible aux blocages comme discuté dans Pourquoi mon "client" enfilez l’envoi des demandes ?. Voici les directives nécessaires (chaque directive doit apparaître sur une seule ligne):

    Notez que vous devez toujours définir la -ORBTransportMuxStrategy à exclusive. la -ORBConnectStrategy à bloquée. le -ORBFlushingStrategy pour le blocage et l’-ORBConnectionHandlerCleanup à 1 lors de l’utilisation de la stratégie rw d’attente.

    A noter également que -ORBConnectionHandlerCleanup ne sont pas disponibles dans les versions de TAO avant 1.4a_p11.

    La raison de l’utilisation exclusive de multiplexage de transport est que vous ne devez pas permettre à une autre demande d’être envoyé sur une connexion si cette connexion est déjà utilisé par un autre thread qui est en attente d’une réponse. Les stratégies de blocage connecter et de rinçage sont nécessaires parce que le gestionnaire d’événements pour une connexion utilisée pour envoyer une demande n’a pas été inscrit sur le réacteur de l’ORB. La stratégie de nettoyage de gestionnaire de connexion doit être activé pour bien nettoyer la fermeture de connexion côté serveur.

    Finalement, C’est important lorsque vous utilisez -ORBConnectionHandlerCleanup que la boucle d’événement ORB être exécuté, au moins périodiquement. L’option de nettoyage du gestionnaire de connexion fonctionne en utilisant une messagerie à base de réacteur interne. Si cette option est utilisée et la boucle d’événements de l’ORB est pas exécuté, l’application sera finalement une impasse.

  • La technique à deux ORB repose sur tous les appels sortants étant fabriqués à partir d’un «client ORB ‘désigné. Cela permettra d’éviter les discussions des clients d’entrer dans le ‘ORB du serveur’ thread-piscine et donc ne soyez pas expédié pour appels ascendants imbriqués. Pour vous assurer que les invocations sur les références d’objets toujours aller à travers le "client" ORB, assurez-vous juste les références d’objets sont toujours demarshalled en utilisant l’ORB du client. Cela peut devenir difficile. Par exemple, si vous recevez un IOR pour un objet de rappel en tant que paramètre à une opération, il aura été demarshalled par la "serveur" ORB (celui qui a reçu la demande). Pour forcer l’IOR à demarshalled via le "client" ORB, vous devez jouer un truc comme ceci:

    Maintenant, lorsque votre application effectue un appel sur le rappel IOR, il sera envoyé par la "client" ORB, où il ne peut pas être distribué pour appels ascendants imbriqués.

    Remarque: Les deux Deux-ORB et de la stratégie d’attente RW sont incompatibles avec BiDirectional GIOP.

    Q:

    UNE:

    Si vous souhaitez utiliser le modèle de concurrence thread par connexion côté serveur, quelques autres paramètres doivent également être présents dans votre fichier svc.conf. Voici un exemple de cette (chaque directive doit apparaître sur une seule ligne):

    Notez que -ORBConnectionHandlerCleanup ne sont pas disponibles dans les versions de TAO avant 1.4a_p11.
    Le raisonnement derrière ces paramètres est la suivante: dans un thread par connexion d’un fil est dédié au service de demandes qui viennent sur une connexion donnée. Afin de garder ce fil dédié à sa connexion, il faut empêcher le fil d’entrer dans le réacteur ou le chef-suit piscine même dans le cas où le fil tente de faire une demande sur un objet distant (voir les paramètres Client_Strategy_Factory) ou ne peut pas écrire une grande réponse de retour à la prise tout à la fois (le réglage de -ORBFlushingStrategy). Ceci est étroitement lié à l’utilisation de la stratégie d’attente RW afin d’éviter appels ascendants imbriqués.

    Q:

    UNE:

    Il existe deux techniques clés que vous pouvez utiliser dans cette situation. Vous pouvez utiliser plusieurs ORB, ou vous pouvez utiliser un seul ORB et utiliser la politique de point de terminaison TAO spécifique pour filtrer paramètres sur une base per-POA.

    L’approche à deux ORB fonctionne en passant collections d’extrémité séparées définies avec "-ORBEndpoint

    " aux différents appels ORB_init utilisés pour initialiser chaque ORB. De cette façon, chaque ORB écoutera leurs propres paramètres et leurs POA ne produira des références d’objets contenant les paramètres associés à l’ORB. Le compromis est que chaque ORB doit exécuter sa propre boucle d’événements, et chaque ORB doit créer son propre POA racine ainsi que d’autres ressources.

    L’approche politique des terminaux vous permet d’avoir un processus avec un seul ORB, et donc une seule boucle d’événement et une hiérarchie de POA unique, et être encore capable d’avoir des POA créer des références d’objets contenant un sous-ensemble des terminaux appartenant à l’ORB. Pour voir un exemple de la politique de point final dans l’action, regardez TAO / tests / POA / EndpointPolicy.

    La mise en œuvre de la politique de point final est stocké dans libTAO_EndpointPolicy. Si vous utilisez MPC pour gérer votre environnement de compilation, vous avez votre projet de serveur hérite de la "endpointpolicy" projet de base. Quelque part dans votre code d’application, vous devez #include "tao / EndpointPolicy / EndpointPolicy.h". La politique de point de terminaison est initialisé en utilisant des conteneurs valuetype spécifiques au protocole. Pour chaque protocole que vous utilisez dans votre application, vous devez également inclure la définition de la valeur de point de terminaison. Par exemple, utiliser #include "tao / EndpointPolicy / IIOPEndpointValue_i.h" d’inclure la définition endpoint valuetype spécifiques IIOP.

    La valeur de la politique de la politique de point de terminaison est une liste de points d’extrémité. De cette façon, vous pouvez fournir plus d’une valeur de point final, même pour différents protocoles, à la même politique de point de terminaison. Le constructeur de valeurs finaux IIOP spécifiques prend un nom d’hôte et un numéro de port.

    instances politiques Endpoint sont créés comme toute autre stratégie personnalisée pourrait être, en utilisant create_policy () le fonctionnement de l’ORB.

    Contrairement à d’autres politiques POA liées, cette politique est appliquée à un gestionnaire de POA. Cela se fait via l’interface POAManagerFactory.

    Vous utilisez ensuite ce POAManager lorsque vous créez des instances de POA. Ce gestionnaire de POA est aussi celui sur lequel vous appelez activer pour régler tous les POA liés à l’état actif.

    À ce stade, toutes les références d’objets créés par le "goodPOA" ne contiendra que les points d’extrémité spécifiés sur la liste donnée à la "goodPOAManager".

    Note importante: La politique de point de terminaison fonctionne à sélectionner les paramètres qui ont été précédemment passés à l’ORB avec les options -ORBEndpoint ou -ORBListenPoints ORB_init. Si vous fournissez des valeurs des paramètres de la politique qui ne correspond à aucun des critères d’évaluation de l’ORB, ce par lui-même ne provoque pas un échec, mais ce critère sera inclus dans toutes les références d’objet. Si aucune des valeurs d’extrémité donné à la politique correspondent aux paramètres connus de l’ORB, le POA lancera une exception lors d’une tentative de créer une référence d’objet.

    Q:

    Oui. Toutefois, il ne participera pas à Codeset négocier avec d’autres ORB. Si vous êtes dans un environnement mixte où vous mélangez, disons, Unicode, UTF-8, ou divers jeux de codes asiatiques, vous aurez des problèmes de caractère d’échange.

    UNE:

    TAO comprend un "enfichables" cadre du protocole de transport qui permet à l’ORB d’être configuré pour fonctionner sur des transports autres que TCP / IP. En fait, la norme Inter-ORB Protocol Internet (IIOP) est implémenté dans TAO comme un protocole de transport enfichables qui est basé sur TCP / IP. Outre IIOP, TAO est livré avec plusieurs implémentations de protocole de transport alternatifs, y compris:

    • Unix Inter-ORB Protocol (uiop), qui est basé sur Unix Domain Sockets (ou IPC local)
    • Mémoire partagée Protocole Inter-ORB (SHMIOP), qui utilise la mémoire partagée comme un transport.
    • Datagram Protocole Inter-ORB (DIOP), qui utilise le protocole UDP pour le transfert de messages efficace dans des circonstances limitées.
    • Secure Sockets Layer Protocole Inter-ORB (SSLIOP), qui est basé sur SSL.
    • Multicast Protocole Inter-ORB (MIOP), mis en place au sommet de Unreliable IP Multicast (UIPMC).
    • Hypertext Inter-ORB Protocol (HTIOP), qui utilise le tunneling HTTP.
    • Stream Control Transmission Protocol Protocole Inter-ORB (SCIOP), qui est basé sur SCTP (IETF RFC 2960).
    • L’utilisation du protocole de transport sous-jacent est complètement transparent pour l’application. En fait, l’ORB peut effectivement être configuré de manière à utiliser plus d’un protocole de transport en même temps.

      Si l’un des protocoles de transport intégrés ci-dessus ne répond pas à vos besoins, vous pouvez avoir besoin de mettre en œuvre un vous-même. Si cela est fait correctement, il devrait exiger aucun changement dans le noyau TAO. Utilisez l’une des implémentations de protocole de transport enfichables existants comme orientation.

      L’utilisation et le développement de protocoles enfichables est documenté en détail dans le Guide du développeur TAO.

      Q:

      UNE:

      La réponse dépend d’un certain nombre de conditions:

      • Si le client est colocalisé avec le serviteur et colocalisation est activé, la demande est desservie sur le thread du client. Collocation peut être désactivé via l’option: -ORBCollocation pas
      • Si le client se trouve pas dans le même processus que le serviteur (ou collocation est désactivé), la stratégie de la simultanéité des ORB de la servante détermine le fil de l’entretien. Par défaut, c’est le même fil où orbe-gt; run () ou orb-gt; perform_work () est appelée. Vous pouvez également spécifier un modèle de fil par connexion via l’option -ORBConcurrency et un modèle de threadpool en utilisant le réacteur de pool de threads.

      schmidt / PDF / C ++ – rapport-col18.pdf pour une discussion sur les optimisations de colocalisation de TAO.

      Q:

      UNE:

      (Paraphrase de l’e-mail par Carlos O’Ryan coryan@uci.edu)

      Vous ne pouvez pas détecter directement lorsque cela se produit. Vous pouvez écrire un protocole enfichables qui informe votre application lorsqu’une connexion meurt, mais qui est à ce sujet.

      En règle générale derrière cette question est la question: comment puis-je détecter si mon client est mort. Utilisation de connexions pour c’est une très mauvaise idée: le client ou serveur ORB peut fermer la connexion juste parce qu’il est inactif pendant trop longtemps ou il peut ne pas être une connexion physique entre deux ORB (ils peuvent être colocalisés ou en utilisant la mémoire partagée pour communiquer) . Il peut aussi y avoir plusieurs connexions entre une paire client-serveur donné. Dans CORBA, les connexions sont cachées, et peuvent aller et venir au besoin. Essayer de compter sur eux pour établir si le client est toujours là ne fonctionne pas.

      En général, vous êtes mieux d’utiliser un objet de session de niveau application qui obtient détruit par le client quand il se termine avec grâce, et que est détruit par un Evictor si elle a été inactif ou incapable de communiquer avec le client depuis trop longtemps.

      Q:

      UNE:

      Le CORBA :: paramètres Environnement font partie de la cartographie d’exception alternative définie par l’IDL de l’OMG à la spécification de mappage de langage C ++. Normalement, les exceptions CORBA sont mappés à des exceptions C. La cartographie permet également CORBA à utiliser lorsque les exceptions C ne sont pas disponibles ou indésirable en passant les informations d’exception via un paramètre supplémentaire du type de CORBA :: Environnement. versions TAO jusqu’à 1.5.1 support les mappings et vous pouvez construire ACE / TAO pour soutenir soit la cartographie par exceptions passant = 0 ou exceptions = 1 à GNU faire ou en définissant les ACE_HAS_EXCEPTIONS macro.

      Si vous construisez TAO à utiliser C ++ exceptions natives, le compilateur IDL, par défaut, ne comprend pas le CORBA :: paramètres Environnement. Si vous construisez avec le mappage de remplacement, le compilateur IDL inclut le CORBA :: Environnement paramètre par défaut. Vous pouvez explicitement dire au compilateur IDL quoi faire avec l’option -Ge (-Ge 1 comprend le paramètre supplémentaire, -Ge 0 omet). Vous devez générer les classes de squelette d’une manière qui est compatible avec vos classes serviteur ou vous recevrez des erreurs de compilation sur les classes abstraites ou des fonctions virtuelles pures.

      Pour plus d’informations sur les exceptions et TAO, voir le chapitre du Guide du développeur TAO de gestion des erreurs.

      Q:

      UNE:

      Il y a plusieurs directives conditionnelles qui sont pertinentes:

      • ACE_HAS_STANDARD_CPP_LIBRARY – Causes ACE à #include les bibliothèques standard le cas échéant à la place des bibliothèques plus anciennes d’exécution de style, ou de définir son propre équivalent. (c’est à dire lt; cstdiogt; à la place de lt; stdio.hgt; ou lt; memorygt; au lieu de créer son propre auto_ptr)
      • ACE_USES_STD_NAMESPACE_FOR_STDCPP_LIB – Cela provoque l’ACE pour définir "en utilisant std :: xxx" pour toutes les classes std qu’il utilise. Je ne l’ai jamais foiré avec celui-ci, donc je ne suis pas sûr de toutes les ramifications. Je remarque qu’il est défini par défaut pour la plupart (tous?) Des compilateurs de fenêtres.
      • ACE_HAS_STDCPP_STL_INCLUDES – Cela semble être utilisé que dans As / iostream.h. Il provoque ACE à utiliser lt; stringgt; à la place de lt; String.hgt ;. Il est pas défini pour VC ++, mais pour d’autres compilateurs win32. Je ne l’ai jamais utilisé celui-ci soit.

      Dans la pratique, je définis généralement ACE_HAS_STANDARD_CPP_LIBRARY, et utiliser stl et d’autres objets std dans mon code. Vous pouvez toujours utiliser les fonctions et les objets de la bibliothèque std sans définir ACE_HAS_STANDARD_CPP_LIBRARY, mais il peut être un problème en raison des définitions en double. (Par exemple std :: cout & Cout sont différents, vous devez donc utiliser explicitement std. la plupart des endroits, et vous ne pouvez pas les utiliser de manière interchangeable)
      En pratique, il est assez courant d’utiliser ACE_HAS_STANDARD_CPP_LIBRARY. Je l’utilise toujours, et préfère la bibliothèque standard à ACE où il y a chevauchement. (Ie std :: carte ou hash_map sur ACE_Hash_Map_Manager_Ex) Bien sûr, cela peut être une question de la portabilité.

      Q:

      UNE:

      CORBA :: ORB_init () est censé enlever tous "-ORBE" les options qu’il reconnaît. Une façon de faire cela de façon logique et efficace est de mettre tous les arguments comptabilisés à la fin du vecteur d’argument et d’ajuster le nombre d’arguments (argc) en conséquence.

      Vous êtes seulement censés utiliser la première "argc" nombre d’arguments après appel CORBA :: ORB_init (). Dans votre cas, vous avez eu: Après avoir appelé CORBA :: ORB_init () vous avez: Cela signifie que vous ne devez utiliser le premier argument du vecteur d’argument.

      Si vous avez besoin de maintenir l’ordre du vecteur d’argument original pour une utilisation ultérieure, alors vous devez faire une copie avant d’appeler CORBA :: ORB_init ().

      Q:

      UNE:

      Signaux et le réacteur ORB:

      Par ACE par défaut utilise le réacteur ACE_Select, qui fonctionne avec des signaux. par défaut TAO à utiliser le réacteur pool de threads (TP), qui ne fonctionne pas actuellement avec des signaux. Voir DOC Bug 1031:

      L’appel ACE_Reactor :: instance () retourne un ACE_Select_Reactor. Le TAO_ORB_Core_instance d’appel () – gt; réacteur () retourne un ACE_TP_Reactor.

      Une autre approche possible pour le traitement des signaux dans une application TAO qui utilise le réacteur de TP par défaut serait de lancer un thread séparé et utiliser ACE_OS :: sigwait () pour gérer les signaux.

      Q:

      UNE:

      Il fournit une implémentation d’une interface (Transport :: actuel) pour obtenir des informations de transport commun et une implémentation de l’interface spécifique IIOP (Transport :: IIOP :: actuel) pour obtenir des informations IIOP de transport spécifique. D’autre part, il est également un cadre pour la mise en œuvre des plug-ins spécifiques de transport (pour l’interrogation transport spécifique, autre que IIOP).

      S’il vous plaît voir $ TAO_ROOT / docs / transport_current / index.html pour la description de la fonction Transport actuelle.

      Q:

      UNE:

      Le TransportCurrent (voir Qu’est-ce que la bibliothèque TransportCurrent utilisé?) Bibliothèque fournit l’interface spécifique IIOP (Transport :: IIOP :: actuel TAO) et la mise en œuvre. Le TAO :: Transport :: IIOP :: Interface de courant permet d’accéder à l’information des paramètres locaux et distants.

      Voici un exemple pour obtenir des informations via extrémité TAO de la Transport :: IIOP :: interface actuelle.

      Notez les informations de transport est disponible uniquement sur côté serveur à des points d’interception ou à l’intérieur d’un serviteur jusqu’à appel. Plus précisément, le code ci-dessus doit être appelé dans les crochets d’interception (par exemple. Receive_request_service_contexts (), receive_request (), send_reply () et etc.) ou à l’intérieur d’une méthode de mise en œuvre du serviteur.

      Pour utiliser les fonctionnalités de transport actuelles, la bibliothèque de TransportCurrent doit être chargé via le service Configurator, ou être lié statiquement. Voici un exemple du fichier de configuration du service.

      (Notez que cela a été divisé à travers les lignes en vue de l’affichage sur cette page Web. Le fichier de configuration réel de service doit avoir le contenu ci-dessus sur une seule ligne.)

      On pourrait obtenir le même, en utilisant -ORBSvcConfDirective avec ce qui précède en tant que paramètre.

      Q:

      UNE:

      Le TAO :: Transport :: IIOP :: interface actuelle peut être utilisée pour obtenir des informations sur les paramètres locaux et distants. S’il vous plaît voir l’exemple de code dans Comment ma demande TAO peut obtenir des informations critère (par exemple IP. Code similaire peut être utilisé par le client pour obtenir des informations sur le critère utilisé pour envoyer une demande. Remarque puisque les informations de transport est disponible uniquement sur le côté client à l’intercepteur des points (dans les send_request, send_poll (), receive_reply (), receive_exception () et receive_other ()), TAO doit être compilé avec le support pour les intercepteurs si le côté client a besoin la fonctionnalité actuelle de Transport.

      Q:

      UNE:

      En supposant que les clients et les serveurs sont locaux à une machine, il est possible en utilisant "localhost". Par exemple, vous pourriez avoir un nom de service en cours d’exécution qui est à l’écoute de l’adaptateur Ethernet et localhost: Si le réseau "hostname" va vers le bas, ce nom de service pourrait encore être accessible par un serveur exécutant localement en utilisant ce qui suit: Indépendamment de l’état du réseau sur lequel "hostname" est enregistré, le serveur sera en mesure de communiquer avec le Service Nom en raison du critère de localhost.

      Q:

      UNE:

      Uiop utilise des jetons de système de fichiers pour identifier les points d’extrémité. Par défaut, ils sont nommés / Tmp / TAOquelque chose . mais ils peuvent aussi être tout ce que vous spécifiez. Lorsque votre ORB de serveur est arrêté, il va nettoyer le jeton associé à tout uiop ou le transport SHMIOP. Toutefois, sur un accident, le jeton point final reste dans le système de fichiers, et provoquera une répétition du serveur à l’échec. SHMIOP utilise une entrée de système de fichiers par connexion qui sert de l’identificateur de mémoire partagée.

      Si vous utilisez un point de terminaison uiop bien connu, comme / Tmp / my_uiop_endpoint. vous pouvez simplement supprimer le fichier nommé dans votre démarrage du serveur, avant de CORBA invoquer :: ORB_init (). Cela se fait facilement en utilisant ACE_OS :: unlink ("/ Tmp / my_uiop_endpoint"). Lorsque vous utilisez paramètres générés, les fichiers à nettoyer sont anmed / tmp / TAO *. Tant que vous avez pas d’autres serveurs exécutant avec uiop, puis juste supprimer toutes les instances de / Tmp / TAO *. Sinon, vous pouvez utiliser le catior (ou tao_catior si catior est introuvable) pour déterminer lequel des / Tmp / TAO * les points Rendesvous sont toujours actifs.

      Identifier les restes d’une session de SHMIOP écrasé est un peu plus difficile. Le nom par défaut de l’identifiant est / Tmp / MEM_Acceptor_Port _identifiant unique où port est le numéro de port utilisé pour l’établissement de la connexion et l’uniqueid est quelque chose qui distingue futher une instance spécifique de la connexion. Par exemple / Tmp / MEM_Acceptor_55957_0x65754014330. Le SHMIOP usine prend un "-MMAPFilePrefix =. " option pour remplacer l’utilisation de / Tmp / MEM_Acceptor_. Comme avec les points de terminaison uiop, vous pouvez simplement supprimer ces fichiers de votre système de fichiers après un crash. En outre, comme uiop, ces fichiers temporaires sont nettoyés lorsque la connexion est fermée avec succès.


      Erreurs et solutions possibles

      Q:

      UNE:

      Vous pouvez avoir une version plus ancienne de l’un des ACE, des bibliothèques TAO, ou CIAO quelque part dans votre bibliothèque chemin de recherche (par exemple PATH sous Windows, LD_LIBRARY_PATH sous Linux) que vous ne connaissez pas, même si vous avez seulement un arbre de construction de ACE + TAO + CIAO. Par exemple, les Cosmique chaîne d’outils navires d’installation avec les bibliothèques de l’ECA et les installe sur votre système. La même chose est vraie des CD de distribution TAO du BEC.

      Si vous avez une version obsolète de l’un des ACE, des bibliothèques TAO, ou CIAO (par exemple ACE.dll), et son chemin apparaît dans le chemin de recherche de bibliothèque avant $ ACE_ROOT / lib de votre arbre de construction, vous avez exécuté -time erreurs de liaison. L’éditeur de liens d’exécution essaie de lier votre programme contre la première occurrence de la bibliothèque qu’il trouve dans le chemin de recherche de la bibliothèque.

      Grâce à Stoyan Paunov de contribuer à cette question et la réponse.

      Q:

      UNE:

      Lors de la détermination du point d’extrémité pour un serveur, TAO choisit une interface à partir des interfaces disponibles pour le système et code pour son adresse au sein de l’IOR. Si TAO choisit 127.0.0.1 (l’arrière de la boucle locale) comme adresse de point de terminaison, il n’a pas pu trouver d’autres interfaces appropriées. Étant donné que cette adresse est visible à la machine locale, aucune autre machine sera capable de se connecter à la machine locale par le biais de cette adresse.
      S’il existe des interfaces dynamiques qui sont à la disposition du système, vous devrez peut-être spécifier explicitement que TAO devrait utiliser cette interface avec l’option -ORBListenEndpoints de ligne de commande:

      Q:

      UNE:

      La réponse courte est que vous avez probablement besoin d’appeler ACE :: init () avant d’initialiser ou d’utiliser des objets ACE / TAO. Vous devez également être sûr d’appeler ACE :: fini () à la fin de l’utilisation de l’ACE de votre application.

      Lorsque vous incluez ACE / TAO en-têtes du fichier contenant la fonction main (), la fonction ACE :: init () est appelée automatiquement pour vous au début de main (). ACE :: init () initialise l’objet Gestionnaire d’ACE, et doit être appelé avant d’initialiser ou d’utiliser tout ACE / TAO objets. Lorsque vous utilisez uniquement ACE / TAO de bibliothèques qui sont liées dynamiquement, vous pouvez avoir besoin d’appeler explicitement ACE :: init () au préalable. En outre, vous aurez besoin d’appeler ACE :: fini () pour fermer le Gestionnaire d’objets ACE à la fin de l’utilisation de l’ACE / TAO de votre application (par exemple, à un point de sortie du code dans votre bibliothèque).

      Q:

      UNE:

      Il est probable que vos objets utilisent le comptage de référence pour gérer leur cycle de vie. La classe CORBA :: LocalObject fournit une implémentation vide de la _add_ref () et _remove_ref (méthodes). Cependant, le TAO_Local_RefCounted_Object met en œuvre réelle comptage de référence par ces méthodes.

      La solution à votre fuite de mémoire peut être aussi simple que héritant de TAO_Local_RefCounted_Object au lieu de CORBA :: LocalObject.

      Q:

      UNE:

      Lorsqu’une application fonctionne avec le client et le serveur sur le même hôte, mais échoue quand ils sont sur différents hôtes, le coupable habituel est une sorte de nommage problème entre les hôtes. Une façon simple de tester est d’utiliser la commande ping pour tenter de faire un ping chaque hôte de l’autre (en utilisant le nom d’hôte). Vous avez besoin de faire un ping dans les deux directions comme TAO exigera des chemins.

      Une autre façon de tester cette (et même le faire fonctionner) est de dire TAO d’utiliser des adresses décimales (à savoir 128.252.120.1) au lieu de noms d’hôte. Vous pouvez le faire en passant -ORBDottedDecimalAddresses 1 via argv [] pour CORBA :: ORB_init () dans chaque processus de votre application. Notez que vous devez faire pour chaque serveur CORBA dans votre système. Parce que de nombreuses applications clientes sont également des serveurs CORBA. il est préférable d’utiliser cette option pour tous les processus. En supposant que votre code passe des options de ligne de commande pour CORBA :: ORB_init (). vous pouvez le faire à partir de la ligne de commande:

      Remarque: Dans les versions récentes de TAO, sur Windows, la valeur par défaut est d’utiliser des adresses décimales en pointillés plutôt que hostnames.

      Vous pouvez également exécuter dans le problème décrit dans cette question si votre serveur arrive à être à l’écoute sur l’adresse associée au dispositif de bouclage. L’adresse IP de cette "hôte" est 127.0.0.1 et souvent (en particulier sur les hôtes basés sur Linux), le nom d’hôte est réglé sur localhost.localdomain. Ainsi, lorsque votre client essaie de résoudre le nom d’hôte, il résout correctement, mais se connecte à lui-même plutôt que l’hôte sur lequel le serveur est en fait en cours d’exécution.

      Utilisez catior (en $ TAO_ROOT / utils / catior) à "regarder à l’intérieur" vos IOR TAO-générés; si vous voyez localhost.localdomain (ou quelque chose de similaire) dans la sortie, alors vous pourriez avoir ce problème! Utilisez l’option -ORBListenEndpoints (également appelé l’option -ORBEndpoint) pour spécifier le nom d’hôte sur lequel le serveur doit écouter les demandes (et, par conséquent, le nom d’hôte qu’il code dans les IOR qu’il génère).

      L’option -ORBListenEndpoints prend beaucoup d’arguments et modificateurs. Voir https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/ORBEndpoint.html?view=co et Guide du développeur TAO pour plus de détails sur l’option les -ORBListenEndpoints.

      Merci à Tim Fry lt; tfry à iMoney dot comgt; pour l’affichage des tao-liste de diffusion de la matière première à partir de laquelle cette entrée a été créée.

      Q:

      UNE:

      (Question élargi): Je cours un serveur avec quelques fils dans un pool de threads. J’ai aussi enregistré un gestionnaire d’événements avec le réacteur de l’ORB à partir de laquelle je fais des invocations distantes. Mon serveur est interblocage. Note: Je suis en utilisant la configuration par défaut (à savoir la stratégie de concurrence par défaut, attendez la stratégie, rinçage stratégie, etc.)

      (Réponse): Par défaut, l’ORB utilise un leader Follower (LF) pour recevoir les demandes et les réponses de traitement de cibles à distance. Il utilise un protocole simple qui permet de suivre les fils de serveur qui sont prêts à traiter les invocations et les fils des clients qui sont en attente de traiter les réponses.

      Lorsque vous enregistrez vos propres gestionnaires d’événements avec le réacteur, le réacteur fait un upcall directement dans votre code d’application. Si votre code de gestionnaire d’événement fait alors un appel distant et attend une réponse, le protocole de LF se décompose depuis un fil marqué comme un fil de serveur devient un thread client à l’insu de la LF. La signature du problème est un serveur bloqué avec des traces de pile montrant aucun des threads dans le select () appel système.

      Pour résoudre ce problème, vous devez respecter le protocole de LF. Effectuez les opérations suivantes dans votre code de gestionnaire d’événements (par exemple dans handle_timeout () ou l’autre handle_ * méthodes):

      Vous pourriez avoir à inclure les fichiers d’en-tête "tao / ORB_Core.h" et "tao / LF_Strategy.h" dans votre code pour obtenir le code ci-dessus pour compiler proprement. Aussi, lorsque vous faites des appels ci-dessus, pensez à utiliser l’ORB au sein duquel réacteur vous avez enregistré votre gestionnaire d’événements.

      Merci à Milan Cvetkovic lt; mcvetkovic@mpathix.comgt; pour signaler le problème et Balachandran Natarajan lt; bala@dre.vanderbilt.edugt; pour fournir la réponse.

      Remarque: Vous pouvez également résoudre le problème en configurant le ORB d’utiliser une stratégie d’attente différente autre que le Suiveur Leader par défaut.
      Voir Pourquoi mon "client" enfilez l’envoi des demandes? pour plus d’informations.

      Ou, vous pouvez utiliser un ORB différent (autre que l’ORB du serveur) dans votre gestionnaire d’événements pour faire l’invocation sortant.

      Q:

      UNE:

      Si vous voyez des erreurs de liaison suivantes (ou similaires). et le fichier foo.idl IDL contient un typedef d’une séquence de types de base comme tel. (Types de base sont les types définis par la spécification OMG IDL comme chaîne, long, etc.). le problème est que les deux votre bibliothèque ou exe (de fooC.obj) et TAO.dll exportent la même classe (instantated à partir du modèle de séquence). Tant que ce problème est résolu pour le bien dans le compilateur IDL (voir DOC groupe entrée bugzilla 2703), utiliser un des contournements suivants:

      • Au lieu de typedef’ing votre propre MyULongList, utilisez CORBA :: ULongSeq ou similaire.
      • Ajouter #include lt; tao / orb.idlgt; (Qui comprend tao / ULongSeq.pidl) vers le haut de votre fichier IDL, ou tout simplement l’instruction include pour le type de séquence (s) que vous utilisez (comme tao / ULongSeq.pidl).

      Chacune de ces contournements forcera le compilateur, lors de la construction fooC.obj de fooC.cpp, pour voir la classe exportée dans les en-têtes de la bibliothèque TAO et éviter la ré-exporter.

      Q:

      UNE:

      file d’attente globale de la chaîne a été comblé par le mauvais consommateur.


      Problèmes d’interopérabilité

      UNE:

      Il existe plusieurs façons de minimiser les dimensions de l’ACE et les bibliothèques TAO, au moins dans UNIX. Ils sont décrits brièvement ici. Plus de détails peuvent être trouvés dans le Guide du développeur TAO.

      Notez que toutes ces solutions sont appliquées au moment de la compilation, donc si vous avez obtenu la distribution de l’OCI de TAO sous forme de binaires pré-compilés sur CD, vous aurez besoin de re-compilation.

      1. Désactivez le débogage.

      Pour désactiver la génération d’informations de débogage supplémentaires dans les bibliothèques, utilisez le debug = 0 make drapeau lors de la construction de l’ACE, TAO, et les bibliothèques de orbsvcs. Vous pouvez le faire dans votre $ ACE_ROOT / include / makeinclude fichier / platform_macros.GNU en mettant debug = 0 dans le fichier ou lorsque vous appelez la commande make (par exemple faire debug = 0).

    • Construire uniquement les composants de l’ECA nécessaires pour TAO.

      Par défaut, tous les composants de l’ECA sont compilés et inclus dans la bibliothèque ACE. Mais, TAO dépend seulement un sous-ensemble de l’ACE. Pour construire uniquement les composants nécessaires à la TAO, définissez ACE_COMPONENTS = FOR_TAO soit comme une variable d’environnement ou dans votre fichier platform_macros.GNU.

    • Construire uniquement le "CORBA minimum" fonctionnalités.

      La bibliothèque TAO peut être construit selon le "CORBA minimum" cahier des charges en excluant le support pour certaines fonctionnalités telles que DII, DSI, DynAny, et les gestionnaires de Servant. Pour sélectionner le sous-ensemble CORBA minimum de TAO, définir le préprocesseur macro TAO_HAS_MINIMUM_CORBA en $ ACE_ROOT / As / config.h. ou définir minimum_corba = 1 dans votre fichier platform_macros.GNU, ou passer minimum_corba = 1 sur la GNU make ligne de commande.

    • Utilisez le "soreduce" outil pour construire un ensemble minimal de bibliothèques partagées pour votre application.

      "soreduce" vous permet de réduire la taille de l’ACE et les bibliothèques TAO en incluant uniquement les fichiers d’objets qui contiennent des symboles utilisés par les exécutables pertinents. "soreduce" génère des fichiers MPC qui peuvent être utilisés pour construire des versions subsetted des ACE / TAO bibliothèques.

      Pour plus d’informations sur soreduce, voir $ ACE_ROOT / apps / soreduce / README.

    • Vous devez utiliser la commande de taille au lieu de mesurer la taille de chaque fichier de bibliothèque sur le disque (par exemple avec ls -l) pour obtenir une mesure plus précise de la taille réelle du code dans la bibliothèque. Les ls de commande des rapports de la taille du fichier de bibliothèque sur le disque (qui peut être très grande), tandis que la commande de la taille ("déc" la colonne, qui est le total de la "texte", "données", et "bss" colonnes, en décimal) indique la taille d’exécution, ce qui sera beaucoup plus petite. (Le "bss" section est pas initialisée données, en fonction de la taille de Solaris (1) page de manuel.)

      Vous pouvez également utiliser la commande de taille pour mesurer la taille d’un exécutable.

      La taille du fichier de chaque bibliothèque sur le disque, tel que rapporté par ls -l. est en réalité un peu rien à voir avec la taille d’exécution de votre exécutable, pour les raisons suivantes:

      • Si vous liez statiquement, la plupart des linkers relieront dans le fichier exécutable uniquement les parties de la bibliothèque (les .o’S) que vous utilisez réellement dans votre application.
      • Si vous liez dynamiquement, l’ensemble de la bibliothèque partagée sera chargé en mémoire, mais il sera partagé entre tous les processus en cours d’exécution sur cet hôte qui utilisent la bibliothèque. Donc, vous ne prenez la mémoire frappé pour la bibliothèque une fois.
      • En outre, même dans une situation de bibliothèque partagée, vous n’êtes pas susceptible d’avoir la bibliothèque entière réside à la fois. La plupart des systèmes d’exploitation modernes seront la page des parties du fichier de bibliothèque dans et hors de la mémoire selon les besoins par les processus.

      En fonction de votre linker et système d’exploitation, votre kilométrage peut varier.

      Q:

      UNE:

      L’astuce consiste à configurer TAO d’utiliser le réacteur de pool de threads, puis d’appeler orbe-gt; run () à partir d’un nombre de threads, permettant ainsi à chaque thread pour traiter les demandes entrantes.

      Sélection du réacteur est effectuée par l’utilisation de l’usine de ressource, un objet de service de configuration. Si vous utilisez un fichier de configuration de service, tels que svc.conf, ajoutez une ligne:

      Si vous ne pouvez pas utiliser un fichier de configuration, ajouter ce qui suit à votre ligne de commande:

      Notez que si vous êtes déjà configurez l’usine de ressource pour tout autre comportement, ne pas ajouter une nouvelle ligne directive, il suffit d’ajouter "-ORBReactor TP" les arguments déjà passé à l’usine de ressource.

      Maintenant que vous avez le réacteur correct sélectionné, vous devez appeler ORB :: run () dans les fils qui sont membres du pool de threads. La meilleure façon d’y parvenir est de tirer de ACE_Task, remplacer la méthode svc () pour exécuter l’orbe, puis utiliser la méthode d’activation pour démarrer le nombre de threads.
      Par exemple:

      Q:

      UNE:

      TAO soutient la politique Roundtrip Timeout relative telle que définie dans la spécification CORBA Messaging (OMG document officiel / 04-03-12, chapitre 22). Cette stratégie vous permet de spécifier la durée maximale autorisée (en unités de 100 nanosecondes) pour une demande à envoyer à et traitées par un serveur et la réponse reçue par le client. La politique peut être appliquée à l’un des trois niveaux: le ORB client, le fil requérant, ou de la référence de l’objet sur lequel la demande est invoquée.

      temporisations relatifs aller-retour peuvent être appliquées lorsque le client demande faible demande / réponse latences.

      L’exemple suivant montre comment définir la politique Roundtrip Timeout relative à une valeur de 1 milliseconde (soit 1.0e-3 * 1.0e7 en unités de 100 nanosecondes) et l’appliquer au niveau ORB:

      Toutes les demandes faites via ce ORB désormais délai d’attente si une réponse est pas reçu dans 1 milliseconde. Quand un timeout se produit, l’ORB soulèvera un système exception CORBA :: TIMEOUT. Le client peut alors prendre toutes les mesures nécessaires pour gérer l’échec. Si une réponse arrive finalement après le délai d’attente a expiré, il sera rejeté par l’ORB du client.

      La politique Roundtrip Timeout relative, et d’autres la qualité des politiques de service définies dans le cadre de la spécification CORBA Messaging, sont décrits plus en détail dans le Guide du développeur OCI TAO. CORBA chapitre Messaging, disponible à partir de http://www.theaceorb.com/. Voir aussi http://www.cs.wustl.edu/

      Q:

      UNE:

      Réduction de l’empreinte dans le code généré

      IDL compilateur Options de ligne de commande

      Élimine génération Tous les opérateurs d’insertion / extraction, et génère certaines opérations d’interception portable qui utilisent Anys comme mannequins

      Supprime le type de génération de code. Depuis Anys dépendent des codes de type, cette option fait aussi ce -Sa fait.

      Générer typecodes optimisés. Tous les noms de chaîne dans un code de type, sauf l’identifiant du référentiel sera nul avec cette option. Cette optimisation est autorisée par la, CORBA spec, mais il peut causer des problèmes en essayant de déterminer le type de code équivalence.

      Supprime la génération de classe de cravate.

      Supprime la génération de code stub thru-POA colocalisés.

      Supprime la génération de code stub colocalisé direct. colocalisation Direct génération de code de stub est désactivée par défaut, mais l’option est incluse par souci d’exhaustivité.

      Supprime la génération de code pour les types de valeurs. La génération de code pour les types de valeurs est désactivée par défaut, mais l’option est incluse par souci d’exhaustivité.

      C ++ Compiler Options

      Si les deux TAO et l’application sont compilées avec TAO_HAS_INTERCEPTORS définies à 0 (soit en faisant passer au compilateur C ++ ou en redéfinissant la macro dans ACE_ROOT / TAO / tao / orbconf.h) non seulement la bibliothèque TAO être plus petite, mais aussi la l’application du code objet, depuis le préprocesseur du C va sauter les classes d’interception générés et des parties du code généré pour chaque opération IDL.

      Q:

      UNE:

      Lors du développement d’un logiciel qui utilise ACE + TAO vous pouvez réduire le temps qu’il faut pour compiler votre logiciel en ne vous permettant les drapeaux de l’optimiseur de compilateur. Ceux-ci prennent souvent la forme -O.

      Lorsque l’optimisation du compilateur est désactivé, il est souvent le cas où aucune inline sera effectuée. Dans ce cas, le inline ACE ajoutera à votre temps de compilation sans aucun avantage appréciable. Vous pouvez donc diminuer les temps de compilation plus loin en construction construire votre application avec le drapeau -DACE_NO_INLINE C ++.

      Pour le code construit avec -DACE_NO_INLINE pour lier, vous devez être en utilisant une version d’ACE + TAO construit avec le "inline = 0" faire drapeau.

      Afin de répondre à la fois en ligne et non en ligne construit de votre application, il sera nécessaire de construire deux copies de votre ACE + TAO bibliothèques, l’une avec et l’autre sans inline. Vous pouvez ensuite utiliser vos ACE_ROOT et TAO_ROOT variables à point à l’installation appropriée.


      Divers enjeux spécifiques à la plateforme

      Q:

      UNE:

      Une façon courante de construire ACE et TAO (une fois que vous avez votre configuration mis en place) est de fonctionner simplement "faire" dans le répertoire $ ACE_ROOT, puis exécutez "faire" à nouveau dans le répertoire $ TAO_ROOT. Toutefois, en cours d’exécution "faire" à partir de $ ACE_ROOT non seulement construit la bibliothèque ACE, il construit également tous les exemples, les tests, et d’autres choses que vous ne pouvez pas avoir besoin. De même, en cours d’exécution "faire" à partir de $ TAO_ROOT construit non seulement les bibliothèques TAO et orbsvcs, il construit aussi tous les tests et les exemples TAO et orbsvcs.

      Pour construire seulement ce dont vous avez besoin pour développer des applications avec ACE et TAO (et d’économiser beaucoup d’espace disque lors de la construction), vous pouvez exécuter faire uniquement dans les répertoires suivants:

      Cela va construire seulement la bibliothèque de l’ECA, gperf exécutable (nécessaire par le compilateur IDL), exécutable tao_idl, bibliothèque ACEXML, les bibliothèques de protocoles (extensions du cadre de l’ECA), les bibliothèques TAO, et les bibliothèques de orbsvcs.

      Si vous voulez construire aussi l’un des orbsvcs executables (par exemple $ TAO_ROOT / orbsvcs / Naming_Service), ajouter leurs répertoires à l’ensemble des répertoires que vous créez. Par exemple:

      Vous pouvez également trouver le "NSList" et "catior" utilitaires très utile, de sorte que vous devriez probablement aussi ajouter ces répertoires à la liste des répertoires dans laquelle construire:

      Bien sûr, vous pouvez toujours revenir en arrière et de construire des tests et des exemples individuels si vous voulez.

      Q:

      UNE:

      Si vous liez versions de débogage d’un exécutable ou DLL et ont des symboles non résolus, il y a plusieurs raisons possibles:

      1. Est votre chemin de la bibliothèque correcte?
        (Cochez Outils | Options | Répertoires | bibliothèques ou paramètres de votre projet.)
      2. Est-ce que vous liez dans le ACE, TAO, et peut-être orbsvcs bibliothèques?
        (Cochez la case Construire | Paramètres | Lien)
      3. Est-ce que vous liez avec les noms de bibliothèque à droite?
        Si vous construisez votre application contre une configuration Debug d’ACE + TAO, les noms des bibliothèques auront la lettre "ré" en eux (par exemple aced.lib, TAOd.lib, CosNamingd.lib). Si vous utilisez une configuration de sortie d’ACE + TAO, la "ré" ne sera pas présent dans les noms de bibliothèques.
      4. Avez-vous installé ou construit la configuration de débogage d’ACE + TAO?
        Si vous avez seulement installé la version non-Debug de TAO, vous ne serez pas en mesure de construire des exécutables de débogage. Pour vérifier cela, effectuez l’une des opérations suivantes:
      1. Construire la configuration de sortie de l’exécutable; ou
      2. Retirer _DEBUG de la liste des définitions de préprocesseur.

      Si la construction réussit, alors vous avez probablement une version non-Debug de TAO.

      Q:

      UNE:

      Selon le Guide du développeur TAO. chapitre TAO IDL Compiler, section "Retour Options Fin"Le moyen d’exporter des classes générées comme suit:

      1. Créer un fichier d’en-tête à l’exportation en utilisant le script perl% ACE_ROOT% \ bin \ generate_export_file.pl.
      2. Utilisez le -WB, export_macro et -WB, les options export_include au compilateur IDL TAO pour inclure les macros dans les déclarations de classe générées:
      3. Dans les paramètres du projet, l’onglet C / C, les options de préprocesseur, inclure FOO_BUILD_DLL dans la liste des définitions.
        (Si vous utilisez MPC pour générer vos paramètres du projet, la dernière étape se fait automatiquement pour vous.)

      Voir le Guide du développeur TAO pour plus d’informations et des exemples.

      Q:

      UNE:

      Au moins sur certaines versions de Windows, il y a un bug dans lequel le champ TTL (Time-to-Live) dans des paquets IP multicast est mis à zéro. Ainsi, personne ne prête attention à ces paquets. Ce problème particulier bit OCI dans leur environnement de laboratoire de formation, et pour cette raison, nous utilisons maintenant le service de nommage sans multidiffusion comme indiqué dans le Guide du développeur TAO (voir Comment puis-je trouver Naming Service sans avoir recours à la découverte multicast?).

      Le problème est documenté dans http://support.microsoft.com/support/kb/articles/Q234/9/80.ASP. Bien que les notes disent pour obtenir le dernier Service Pack, notre expérience montre que cela ne suffit pas que du Service Pack 6.

      Q:

      UNE:

      Changer la configuration active.
      Du "Construire" menu déroulant choisissez "Set Active Configuration. ". Dans la configuration contextuelle choisir le approprié (Debug ou Release) configuration MFC.

      Batch build.
      Allez à la construction déroulant dans MSC ++ et sélectionnez l’option Batch Build. Lorsque la fenêtre batch de compilation apparaît sélectionner l’option de compilation ACE MFC et désélectionner toutes les autres options. Cela va construire le acemfc.lib pour vous. En utilisant l’option batch build vous pouvez construire toutes les saveurs des différents ACE et les bibliothèques TAO dont vous avez besoin.

      Q:

      UNE:

      Singletons dans les DLL sous Windows
      Si vous voulez instancier un singleton dans une DLL sous Windows, procédez comme suit:

      1. Utilisez generate_export_file.pl (trouvé dans ACE_wrappers / bin) pour générer les directives d’exportation appropriées Win32 pour votre dll. Par exemple, "perl generate_export_file.pl MyLib gt; MyLib_Export.h" génère la sortie suivante dans le fichier "MyLib_Export.h":
      2. Lors de la déclaration de votre singleton, assurez-vous et utilisez la directive droit à l’exportation que vous avez généré pour votre dll. Par exemple, si vous créez une classe qui est censé être un singleton dans MYLIB.DLL, vous souhaitez généralement faites ceci:

      Q:

      UNE:

      Sous Windows, si l’on engendre un fil, par exemple _beginthreadex. et fait des appels de ce thread CORBA, TAO sera une fuite de mémoire. TAO utilise TSS (stockage spécifique de fil) pour le traitement des demandes le long des chemins de données de sortie. Avec threads Win32, le système de type sous-jacent n’invoque Déstructeur sur TSS et l’application des fuites mémoire. Pour contourner ce problème, s’il vous plaît utiliser les threads ACE chaque fois que possible. Grâce à lt; alexander.jasper@gmx.netgt; pour fournir cette FAQ!


      VxWorks

      Q:

      Je viens construit les bibliothèques et ils sont ÉNORME. comment puis-je les faire plus petit?

      UNE:

      Tout cela dépend de votre définition de "énorme" et comment vous avez construit les bibliothèques. Si vous considérez quelques mégaoctets d’être énorme et vous avez construit optimisé, nodebug et CORBA minimum, c’est la façon la vie est actuellement.

      Si, d’autre part, vous êtes à la recherche à la taille des fichiers et vous construit les valeurs par défaut, alors la première chose que vous devez faire est de comprendre que la taille du fichier est pas la même que la taille du code. Lors de la compilation des informations de débogage, le compilateur ajoute des informations de symbole pour les bibliothèques, et que les informations de symbole est massive. Ce que vous devez faire est de regarder la taille du code. Utilisation de la toolchain WindRiver GNU, vous pouvez utiliser sizeppc pour ce faire, par exemple,

      Donc, vous pouvez voir que la taille du fichier est 30Mb, mais la taille du code est 692k. Un nombre assez différent. le "Taille" les résultats peuvent être comparés à la mémoire disponible sur le système cible. Utilisez à la fois le "memShow" et "adrSpaceShow" commandes du shell VxWorks cible résident pour voir combien de mémoire est disponible.

      Il existe différentes stratégies pour rendre les bibliothèques plus petits, et impliquent toutes la reconstruction. Plus précisément, vous pouvez construire:

      • nodebug (Debug = 0), qui permettra d’éliminer les symboles et les messages de débogage
      • minimumCORBA. qui ne fera que compiler fonctionnalité spécifiée par la spécification CORBA minimum
      • ACE seulement pour TAO. qui ne fera que compiler les parties de ACE requises par TAO

      Une technique souvent utilisée pour garder la bibliothèque de tailles petite et encore débogable est de construire la bibliothèque entière nondebug, puis seulement de construire les pièces dont vous avez besoin pour déboguer avec débogage sur. Cela vous permet de déboguer ces morceaux, mais pas souffrir à travers les problèmes que les grandes tailles de fichiers dans les bibliothèques provoquent (par exemple fois plus télécharger / boot).
      Voici un raccourci vers la reconstruction d’un lib avec debug = 0. Mais:

      1. Elle ne supprime pas des instructions de débogage.
      2. Vous devez faire attention de ne pas supprimer les symboles de réinstallation sur VxWorks, de sorte que vous pouvez charger le lib. Par exemple, utiliser quelque chose comme stripppc –strip-inutiles, ou strip386 ​​–strip-debug
      3. stripppc est cassé sur Tornado 2, Windows hôte. Il ne sera pas vous permettre de créer le fichier de sortie, il est donc d’aucune utilité.

      Q:

      UNE:

      Les bibliothèques partagées sur VxWorks ne sont pas vraiment des bibliothèques partagées. Si vous déjà travaillé sur Unix dans les jours avant les bibliothèques partagées, vous souvenez peut-être "fichiers objet déplaçables", À savoir des fichiers objets créés par l’éditeur de liens avec un grand nombre de leurs symboles résolus, mais aussi permis d’avoir des symboles non résolus.

      Quand tu vois libACE.so sur VxWorks, ils sont tout simplement des fichiers objet déplaçables. Une fois que vous vous rendez compte que, et tout ce qu’elle entraîne, votre vie sera plus facile 🙂

      Quelques implications sont:

      • Vous devriez ne pas utilisation "-dentelle" lors de la liaison libTAO.so, puis essayez de charger à la fois libACE.so et libTAO.so. Cela conduira à dupliquer des symboles parce que la création de libTAO.so résoudra tous les symboles de l’ECA. Ainsi, lorsque vous chargez libTAO.so après avoir chargé libACE.so, vous, effectivement, charger tous les symboles de libACE.so à nouveau (ils sont en libTAO.so, aussi).
      • Comme pour le point précédent, vous ne devriez pas lier libACE.so ou libTAO.so dans votre application.

      Une ligne de commande pour créer une bibliothèque partagée sur VxWorks pourrait ressembler: Le ACE_SHLIBS faire macro contient généralement les noms des bibliothèques partagées pour relier à, tels que "-lTAO -lACE", Etc. En faisant le vide, ceux-ci ne sera pas lié.

      Q:

      UNE:

      Ce message indique que le configurateur de service n’a pas pu lire le fichier de configuration pour une raison quelconque. Sur VxWorks 6.2, nous avons vu ce message en raison d’un bogue dans le pilote NFS V2 dans laquelle le pilote renvoie un descripteur de fichier corrompu lors de l’ouverture d’un fichier non-existant. Si un fichier de configuration n’a pas été spécifiée, le configurateur de service tente d’ouvrir le fichier de configuration par défaut ‘svc.conf’. Essayer ensuite de lire dans des résultats de la poignée de fichiers corrompus retournés dans le message ci-dessus.

      Cette question est documentée dans défaut # 55808. Un correctif est documenté ce whcih nécessite une reconstruction du noyau. Un travail rapide autour est de créer un fichier fictif de svc.conf. Une autre solution consiste Comment puis-je configurer TAO à ignorer le fichier de configuration par défaut ‘svc.conf’ ?.

      Q:

      UNE:

      Dans le passé, cela a été fait par la mise en ‘fakesvcconf = 1’ dans la platform_macros.GNU. Cependant cela a été désapprouvée dans 1.5a. La recommandation actuelle est de définir TAO_PLATFORM_SVC_CONF_FILE_NOTSUP en $ ACE_ROOT / As / config.h. Ceci est également rétrocompatible avec 1.4a et 1.3a.


      TAO et Java

      UNE:

      Lorsque j’utilise le service de nom TAO, JavaORB retourne un org.omg.CORBA.INV_OBJREF en resolve_initial_references ("NameService").

      Il y a un fichier appelé NS_Resolve.java dans

      qui contient le code qui découvre le Naming Service de TAO via le mécanisme de découverte de multidiffusion. Accrocher que dans le tableau des références initiale est spécifique ORB, cependant.

      Alternativement, vous pouvez contourner le mécanisme de multidiffusion du service de nommage TAO et connectez votre application Java directement. Pour un exemple qui utilise TAO et JacORB, voir Comment puis-je utiliser JacORB avec Naming Service de TAO?

      Q:

      UNE:

      Java utilise un fichier de propriétés appelé "orb.properties" pour déterminer quel ORB à utiliser. Si le moteur d’exécution Java ne trouve pas un fichier orb.properties, il utilise l’ORB du JDK.

      orb.properties dossier de JacORB est situé dans le répertoire de JacORB haut niveau. Les orb.properties Copier JacORB fichier dans $ / lib du JDK Java pour activer JacORB. Si vous n’êtes pas sûr de ce répertoire est, compiler et exécuter le programme Java suivant:

      Un signe certain que le runtime Java n’utilise JacORB est qu’une exception est levée, et la trace de la pile contient des méthodes avec le préfixe "com.sun.corba".

      Une autre manière de spécifier les ORB à utiliser est de spécifier directement à l’exécution Java.

      Au lieu de déposer les orb.properties dans le répertoire lib, vous pouvez simplement passer le suivant à la machine virtuelle:

      JacORB 1.3.11 ou plus tôt:

      JacORB 1.3.21 ou plus tard:

      Une seconde alternative pour spécifier les ORB à utiliser est de spécifier directement dans votre code lors de l’initialisation de l’ORB.

      Au lieu de copier le fichier orb.properties dans le répertoire $ / lib, mettez ce qui suit dans votre programme principal:

      JacORB 1.3.11 ou plus tôt:

      JacORB 1.3.21 ou plus tard:

      Q:

      UNE:

      Vérifiez que l’interface Repository Ids générée par TAO et JacORB pour chaque interface sont les mêmes.
      Par exemple, supposons que vous avez un fichier IDL appelé "Bank.idl", Avec une interface IDL appelé "Banque".
      TAO génère un fichier appelé BankC.cpp; dans ce fichier, dans la classe de la Banque, il y a une "_interface_repository_id" fonction. Cette fonction doit retourner une chaîne qui ressemble à quelque chose comme ceci:
      JacORB génère un fichier Java appelé BankHelper.java. Dans ce fichier, dans la classe BankHelper est un "ça" fonction. Il renvoie également une chaîne, et que la chaîne doit correspondre à la chaîne de _interface_repository_id TAO exactement:
      Soit dit en passant, à la fois TAO et le compilateur IDL JacORB soutiennent la directive préfixe #pragma dans les fichiers IDL.

      Q:

      UNE:

      Non, JacORB (ainsi que des versions de TAO 1.1.10 et versions ultérieures) utilise le "corbaloc" format de référence d’objet. Voir Comment puis-je utiliser un "corbaloc" Référence de l’objet avec un serveur TAO? pour plus d’informations sur l’utilisation "corbaloc" les références d’objets entre JacORB (ou tout client) et les serveurs TAO.

      Q:

      UNE:

      applications JacORB peuvent utiliser le service de nommage de TAO. Applications mises en œuvre avec Java JDK 1.2 ou plus besoin d’une solution de contournement pour éviter d’utiliser les talons org.omg.CosNaming de Sun, qui sont buggy. Nous allons utiliser l’option -Xbootclasspath / p d’exécution pour éliminer ce problème, comme décrit ci-dessous.

      Les étapes pour utiliser le service de nommage de TAO des clients JacORB sont les suivantes:

      1. Démarrer TAO de Naming Service, en spécifiant un point de terminaison d’écoute bien connu
      2. Écrivez vos clients JacORB Naming Service comme vous le feriez normalement, en utilisant orb.resolve_initial_references ("NameService") Pour trouver le Naming Service.
      3. Exécutez votre application Java en utilisant l’option -ORBInitRef de ligne de commande pour dire JacORB où trouver le service de nommage. Si l’application Java est implémentée en utilisant Java JDK 1.2 ou ultérieure, l’option -Xbootclasspath / p sera nécessaire pour utiliser les moignons CosNaming de JacORB au lieu de celle du Soleil.

      Pour le bien de notre exemple, supposons JacORB est installé dans / usr / don / JacORB-1_2_3.

      Notez que l’hôte et le port – "myhost" et "2809" – Dans ces références d’objets correspondre à l’hôte et le port passé dans le TAO Naming Service de "-ORBListenEndpoints" argument.

      Vous pouvez également utiliser jacorb.properties dossier de JacORB pour définir le service de nommage IOR:

      Et puis exécutez le client et le serveur sans le -DORBInitRef:

      Q:

      UNE:

      Dans JacORB 1.3.21, le préfixe pour tous les paquets JacORB a été changé "jacorb" à "org.jacorb".

      La solution consiste à modifier vos orb.properties fichier pour changer ceci:

      En outre, vous devez modifier un fichier de script ou build.xml qui se réfère à une classe de JacORB directement.

      UNE:

      Vous pouvez informer JacORB qui Ethernet adaptateur à utiliser en spécifiant dans le fichier jacorb.properties (il pourrait également être transmis dans la ligne de commande). Il suffit de définir la propriété OAIAddr à l’adresse IP que vous souhaitez JacORB à utiliser. Par exemple, sur ma machine Windows98 qui a un modem DSL, JacORB utilisait le 5.0.0.4 de l’adresse Ethernet de l’adaptateur au lieu de l’adresse IP publique vrai. Je l’ai modifié la propriété OAIAddr et tout a bien fonctionné. BTW, vous pouvez voir ce que JacORB adresse tente de se connecter en positionnant jacorb.verbosity à 2.
      Par exemple:

      Q:

      UNE:

      Il suffit de vous inscrire une référence d’objet direct avec le IORTable au lieu de l’indirect. Pour obtenir la référence d’objet direct, vous devez appeler une version spéciale de POA :: id_to_reference (): TAO_Root_POA * TPOA = dynamic_cast (poa.in ()); bool use_indirect = false; Object_var obj = TPOA-gt; id_to_reference_i (oid.in (), use_indirect); String_var direct_ior = orb-gt; object_to_string (obj.in ()); ior_table-gt; bind ("POAName / ObjectName", Direct_ior.in ());

      Q:

      UNE:

      Bien que nous ne disposons pas d’exemple pour mettre en valeur ce problème, il devrait être possible d’enregistrer une référence d’objet direct avec le IORTable, comme discuté ci-dessus, pour contourner ce problème.

      Q:

      UNE:

      Ceci est une question piège, parce que le TMI ne sait rien au sujet de vos références d’objet. Tous les objets activés dans un POA persistant utilisent automatiquement les références d’objets indirects (en supposant -orbuseimr 1). Toutefois, si vous souhaitez prendre en charge les URL de corbaloc tels que ceux générés en utilisant "tao_imr ior" alors vous devez vous inscrire en outre vos IOR dans un IORTable dans le serveur. Ceci est en fait complètement orthogonal si vos références d’objets sont indirects. Cependant, vous pouvez * * éviter inutiles frais généraux de performance supplémentaire en vous inscrivant * IOR directs * dans votre IORTable. Voici un court exemple qui enregistre deux objets avec un POA. const char * poa_name = "MessengerService"; POA_var poa = createPersistentPOA (root_poa.in (), poa_name); servant1 Messenger_i, servant2; ObjectId_var id1 = string_to_ObjectId ("Object1"); poa-gt; activate_object_with_id (id1.in (), &servant1); ObjectId_var id2 = string_to_ObjectId ("Object2"); poa-gt; activate_object_with_id (id2.in (), &servant2); obj = poa-gt; id_to_reference (id1.in ()); String_var ior1 = orb-gt; object_to_string (obj.in ()); obj = poa-gt; id_to_reference (id2.in ()); String_var ior2 = orb-gt; object_to_string (obj.in ()); obj = orb-gt; resolve_initial_references ("IORTable"); IORTable :: Table_var ior_table = IORTable :: Table :: _ étroite (obj.in ()); ior_table-gt; bind ("MessengerService / Object1", Ior1.in ()); ior_table-gt; bind ("MessengerService / Object2", Ior2.in ()); Le problème avec le code ci-dessus est que l’IMR va rediriger les clients vers le bon serveur, mais parce que vous utilisez une URL de corbaloc, le serveur va rediriger les clients vers l’IOR enregistrés dans le IORTable. Étant donné que ces références l’utilisation d’objets de INDIRECTS, vous finirez par être redirigé * retour * à l’IMR à nouveau, qui sera finalement en avant vous sur le serveur où votre invocation pouvez continuer. La solution consiste à modifier le programme d’enregistrement * directs * références d’objets avec le IORTable. TAO_Root_POA * TPOA = dynamic_cast (poa.in ()); bool use_indirect = false; obj = TPOA-gt; id_to_reference_i (id1.in (), use_indirect); String_var ior1 = orb-gt; object_to_string (obj.in ()); obj = TPOA-gt; id_to_reference_i (id2.in (), use_indirect); String_var ior2 = orb-gt; object_to_string (obj.in ()); Maintenant, le TMI va rediriger les clients vers le bon serveur, puis le serveur rediriger les clients vers lui-même sans passer à travers le TMI.

      Q:

      UNE:

      Lors de l’utilisation des URL de corbaloc, le TMI redirige simplement les clients vers le bon serveur, mais la référence d’objet basée sur l’URL ne contient pas suffisamment d’informations pour réellement faire quoi que ce soit. Par conséquent, le serveur doit inclure une entrée IORTable qui sera utilisé pour rediriger le client vers le serveur lui-même à nouveau avec la pleine référence d’objet à base d’IOR correct. Ce voyage aller-retour supplémentaire peut être évité simplement * pas * en utilisant des URL pour invoquer les opérations en premier lieu. Cela signifie généralement que vous devrez exécuter le serveur et l’ont soit sortie l’IOR ou l’enregistrer avec un NameService. Tant que vous démarrez le serveur sur un critère (s) consistant alors l’IOR restera valable.

      Envoyer les mises à jour, des ajouts et des corrections à faq@ociweb.com

      Source: www.theaceorb.com

      Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

      15 − 7 =