IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

CORBA Discussion :

Problèmes de port entre omniORB et Java


Sujet :

CORBA

  1. #1
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    Avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 366
    Points : 437
    Points
    437
    Par défaut Problèmes de port entre omniORB et Java
    Bonjour,

    je suis très loin de maitriser CORBA, et j'ai un petit problème.

    J'ai 2 programmes : C et JAVA, le programme C initialise un ORB sur le port 1234 avec omniORB sans passer par omninames.

    Le programme JAVA se connecte à C en connaissait son ip (ou nom de machine) et son port, 1234, à partir de là, on appelle une méthode 'abo', qui dans C stocke la référence du client JAVA.

    A partir de là le programme C appelle régulièrement une méthode 'notification' du client JAVA. Dans les traces de omniORB, on voit qu'il utilise un port alloué dynamiquement, et dans mon exemple il utilise le port 3448 (de C vers JAVA donc).

    Tout se passe assez bien.

    omniORB: (0) 2010-08-31 08:37:56.608540: Invoke 'notification' on remote: key<............................RootPOA..............>
    omniORB: (0) 2010-08-31 08:37:56.608631: sendChunk: to giop:tcp:192.9.10.218:3448 573 bytes
    omniORB: (0) 2010-08-31 08:37:56.608706: Return 'notification' on remote: key<............................RootPOA..............>
    Jusqu'à ce que le programme JAVA appelle une méthode 'ping' (qui ne transporte rien, et qui ne fait rien du tout) sur le port 3453 dont voici la trace omniORB :

    omniORB: (5) 2010-08-31 08:39:14.808765: Dispatching remote call 'ping' to: key<ciorAdmin> (active)
    omniORB: (5) 2010-08-31 08:39:14.808839: sendChunk: to giop:tcp:[::ffff:192.9.10.218]:3453 24 bytes
    omniORB: (5) 2010-08-31 08:39:14.808857:
    4749 4f50 0100 0001 0000 000c 0000 0000 GIOP............
    0000 0005 0000 0000 ........
    omniORB: (5) 2010-08-31 08:39:14.808910: Return from remote call 'ping' to: key<ciorAdmin> (active)
    omniORB: (1) 2010-08-31 08:39:15.120103: SocketCollection idle. Sleeping.
    omniORB: (5) 2010-08-31 08:39:15.298103: Error in network receive (start of message): giop:tcp:[::ffff:192.9.10.218]:3453
    omniORB: (5) 2010-08-31 08:39:15.298148: throw giopStream::CommFailure from giopStream.cc:878(0,NO,COMM_FAILURE_UnMarshalArguments)
    omniORB: (5) 2010-08-31 08:39:15.298258: Server connection refcount = 1
    omniORB: (5) 2010-08-31 08:39:15.298378: Server connection refcount = 0
    omniORB: (5) 2010-08-31 08:39:15.298395: Server close connection from giop:tcp:[::ffff:192.9.10.218]:3453
    D'après ce que je comprend, l'appel à 'ping' fonctionne vu que j'ai le return ... (et que dans le programme JAVA tout semble bien se passer, mais je ne comprend pas d'où vient le problème qui est juste après.

    De plus il semble que ce port (3453) soit utilisée juste après par omniORB pour faire les appels à 'notification' qui echouent, puis repasse sur le port 3448 et là les appels refonctionnent.

    Je comprend pas très bien d'où peut venir ce problème.

    Enfin, mon programme C casse tout, en effet il n'arrive plus à communiquer avec le client, et me retourne ce message d'erreur :

    omniORB: (0) 2010-08-31 09:06:19.521184: Error in network send: giop:tcp:192.9.10.218:3448
    omniORB: (0) 2010-08-31 09:06:19.521200: throw giopStream::CommFailure from giopStream.cc:1186(1,NO,COMM_FAILURE_MarshalArguments)
    omniORB: (0) 2010-08-31 09:06:19.521366: Client connection refcount = 0
    omniORB: (0) 2010-08-31 09:06:19.521386: Client close connection to giop:tcp:192.9.10.218:3448
    omniORB: (0) 2010-08-31 09:06:19.521463: Invoke 'notification' on remote: key<............................RootPOA..............>
    omniORB: (0) 2010-08-31 09:06:19.521496: Send codeset service context: (ISO-8859-1,UTF-16)
    omniORB: (0) 2010-08-31 09:06:19.521563: Client attempt to connect to giop:tcp:192.9.10.218:3448
    omniORB: (0) 2010-08-31 09:06:19.521757: Failed to connect (no peer name): 192.9.10.218
    omniORB: (0) 2010-08-31 09:06:19.521801: Switch rope to use address giop:tcp:192.9.10.218:3448
    omniORB: (0) 2010-08-31 09:06:19.521818: Unable to open new connection: giop:tcp:192.9.10.218:3448
    omniORB: (0) 2010-08-31 09:06:19.521833: throw giopStream::CommFailure from giopStream.cc:1152(0,NO,TRANSIENT_ConnectFailed)
    omniORB: (0) 2010-08-31 09:06:19.521935: throw TRANSIENT from omniObjRef.cc:813 (NO,TRANSIENT_ConnectFailed)
    omniORB: (0) 2010-08-31 09:06:19.523954: omniRemoteIdentity deleted.
    omniORB: (0) 2010-08-31 09:06:19.523989: ObjRef(IDL:CLA/Client:1.0) -- deleted.

    A partir de là, ORB sur le port 1234 n'existe plus, il n'est plus possible de se connecter au programme C.


    Avez vous un début de petite idée qui me permettrait de trouver d'où vient ce (ces ?) problème ??


    Merci d'avance.

  2. #2
    Membre averti
    Homme Profil pro
    Architecte technique
    Inscrit en
    Septembre 2006
    Messages
    219
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2006
    Messages : 219
    Points : 302
    Points
    302
    Par défaut
    Bonjour,

    Jusqu'à ce que le programme JAVA appelle une méthode 'ping' (qui ne transporte rien, et qui ne fait rien du tout) sur le port 3453 dont voici la trace OmniORB...
    Cette trace OmniORB est l'envoi de la réponse à la requête 'ping'. Le port 3453 n'est donc pas un port d'écoute OmniORB, mais le port utilisé par le process Java pour envoyer la requête 'ping' et recevoir la réponse.
    OmniORB reçoit un COMM_FAILURE indiquant que la communication avec le client Java est interrompue. Est-ce une coupure normale après que le client Java ait bien reçu la réponse ? Ou est-ce que le client Java n'a pas reçu la réponse ? Difficile à dire côté OmniORB.

    De plus il semble que ce port (3453) soit utilisée juste après par omniORB pour faire les appels à 'notification' qui echouent...
    Qu'est ce qui te fait dire cela? As tu des traces OmniORB du style "Invoke 'notification'..." puis juste après "sendChunk: to giop:tcp:192.9.10.218:3453..." ?

    Enfin, mon programme C casse tout, en effet il n'arrive plus à communiquer avec le client, et me retourne ce message d'erreur...
    Pour moi ces messages indiquent que le client/serveur Java n'écoute plus sur le port 3448. A-t-il planté ?
    Quel ORB Java utilises-tu ? Peux-tu activer des traces dessus pour voir ce qui se passe de son côté ?

  3. #3
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    Avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 366
    Points : 437
    Points
    437
    Par défaut
    Bonjour,

    je reviens ici, car après un certain temps et plein de bidouilles le tout est tombé en marche.

    Mais maintenant çà passe plus, et j'arrive pas vraiment à comprendre pourquoi, il va essayer d'oublier mes questions précédentes.

    Par contre je répond à celle là : j'utilise l'orb standard de la JVM pour mon appli Java, et donc omniORB 4.1.4 côté c.


    L'appli en c est un vrai bazar, il faudrait la réécrire pour mieux coller aux règles de l'art Corba, mais c'est pas trop possible financièrement, et c'est pas moi qui ai la décision, cette appli date de l'époque de ORBACUS 3.0.

    Le tout à été codé en utilisant Corba comme un simple adaptateur réseau pour transformer les 2 applis en Serveur / Client bidirectionnel.

    En effet en premier lieu, on exécute le 'serveur' c, qui attend en démarrant un orb sur un port forcé (on utilise pas de namingservice).

    La dessus les 'clients' (java) se connectent au serveur en connaissant le nom de la machine et le port (1234 dans notre cas, mais nous avons aussi un deuxième serveur c sur le port 6789).

    Les clients utilisent ce code :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    orb	= org.omg.CORBA.ORB.init(args, props);
    
            try
            {
                rootPOA	= POAHelper.narrow(orb.resolve_initial_references("RootPOA")); 
                rootPOA.the_POAManager().activate();
    
                servCLAIRE = CLA.CIORAdminHelper.narrow(orb.string_to_object("corbaloc::" + host + ":" + port + "/ciorAdmin"));
    
                System.out.println("Coucou : " + servCLAIRE.coucou());
    
                clientCLAIRE = new corba.claire.Client_impl(orb, this, servCLAIRE);
    
                CLA.CR cr = clientCLAIRE.abonnement();
    Ce qui m'embête : la méthode abonnement() sert à faire en sorte que le serveur c puisse se connecter au client java car le client java démarre un orb aussi, mais comme le port est aléatoire, la méthode abonnement appelle ce code :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    public class Client_impl extends CLA.ClientPOA
    {
    	private CLA.CIORAdmin			admin_;
    
    	public CLA.CR abonnement()
    	{
    		CLA.CR	cr	= CLA.CR.OK;
    
    		try
    		{
    			CLA.CIORAdminPackage.ClientDesc	clientDesc	= new CLA.CIORAdminPackage.ClientDesc(_this(), id_, host_);
    			CLA.CIORHolder					ciorHolder	= new CLA.CIORHolder();
    
    			cr	= admin_.abonnement(clientDesc, ciorHolder);
    
    			if(cr == CLA.CR.OK)
    			{
    				....
    			}
    			else if(cr == CLA.CR.CLIENT_EXISTE_DEJA)
    			{
    				....
    			}
    			else
    			{
    				...
    			}
    		}
    		catch(org.omg.CORBA.COMM_FAILURE ex)
    		{
    			...
    		}
    		catch(org.omg.CORBA.TRANSIENT ex)
    		{
    			...
    		}
    
    		return cr;
    	}

    Donc on envois par Corba une référence sur l'implémentation (this()...) au serveur c, et je me demande si c'est pas là le problème.


    Que pensez-vous du code et de l'architecture générale ? faut-il recoder la partie communication en les clients/serveurs java et c ?

    Pourquoi le port utilisé par le serveur c est-il jamais le bon pour atteindre le serveur/client java ?


    Je suis vraiment désolé pour ce problème, mais je serais extrêmement reconnaissant pour toute aide apportée.

    Merci d'avance.

  4. #4
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    Avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 366
    Points : 437
    Points
    437
    Par défaut
    Bon, on oublie tout ce que j'ai écrit précédemment, j'ai réussi à faire en sorte de pouvoir recoder une partie des 2 applis.

    Maintenant, j'utilise un NameService (celui de java), mon programme C s'enregistre, niquel, mon programme Java s'enregistre, appel des méthodes du programme C, çà passe niquel.

    Maintenant mon programme Java appel une méthode abonnement(in string name) dont le paramêtre est le nom du programme Java dans le nameservice.

    Mon programme C récupère la référence, niquel.

    MAIS, lors d'un appel d'une méthode vers le programme Java, je retombe dans un programme que je comprend pas :

    omniORB: (4) 2010-10-20 10:44:36.756051:
    4749 4f50 0102 0000 0000 006d 0000 0007 GIOP.......m....
    0300 0000 0000 0002 0000 000e fe4c beab .............L..
    c642 5700 0000 0000 0000 0001 0000 000b .BW.............
    6162 6f6e 6e65 6d65 6e74 0078 0000 0003 abonnement.x....
    0000 0011 0000 0002 0002 0011 0000 0001 ................
    0000 000c 0000 0000 0001 0001 0001 0109 ................
    4e45 4f00 0000 0002 0014 4f00 0000 0002 NEO.......O.....
    0000 0005 706c 6f70 00 ....plop.
    omniORB: (4) 2010-10-20 10:44:36.756088: Receive codeset service context and set TCS to (ISO-8859-1,UTF-16)
    omniORB: (4) 2010-10-20 10:44:36.756106: Dispatching remote call 'abonnement' to: root<0> (active)
    omniORB: (4) 2010-10-20 10:44:36.756191: Initial reference `NameService' resolved from configuration file.
    omniORB: (4) 2010-10-20 10:44:36.756217: Invoke '_is_a' on remote: key<............................RootPOA.....NameService.....NC0.>
    omniORB: (4) 2010-10-20 10:44:36.756249: sendChunk: to giop:tcp:192.9.10.213:1049 148 bytes
    omniORB: (4) 2010-10-20 10:44:36.756267:
    4749 4f50 0102 0000 0000 0088 0000 0006 GIOP............
    0300 0000 0000 2034 0000 003c afab cb00 ...... 4...<....
    0000 0022 0000 03e8 0000 0001 0000 0000 ..."............
    0000 0002 0000 0008 526f 6f74 504f 4100 ........RootPOA.
    0000 000c 4e61 6d65 5365 7276 6963 6500 ....NameService.
    0000 0003 4e43 3014 0000 0006 5f69 735f ....NC0....._is_
    6100 0020 0000 0000 0000 0028 4944 4c3a a.. .......(IDL:
    6f6d 672e 6f72 672f 436f 734e 616d 696e omg.org/CosNamin
    672f 4e61 6d69 6e67 436f 6e74 6578 743a g/NamingContext:
    312e 3000 1.0.
    omniORB: (4) 2010-10-20 10:44:36.757341: inputMessage: from giop:tcp:192.9.10.213:1049 41 bytes
    omniORB: (4) 2010-10-20 10:44:36.757361:
    4749 4f50 0102 0001 0000 001d 0000 0006 GIOP............
    0000 0000 0000 0001 4e45 4f00 0000 0002 ........NEO.....
    0014 00cc 0000 0006 01 .........
    omniORB: (4) 2010-10-20 10:44:36.757393: Return '_is_a' on remote: key<............................RootPOA.....NameService.....NC0.>
    omniORB: (4) 2010-10-20 10:44:36.757420: Creating ref to remote: key<............................RootPOA.....NameService.....NC0.>
    target id : IDL:omg.org/CosNaming/NamingContext:1.0
    most derived id:
    omniORB: (4) 2010-10-20 10:44:36.757464: Invoke 'resolve' on remote: key<............................RootPOA.....NameService.....NC0.>
    omniORB: (4) 2010-10-20 10:44:36.757489: sendChunk: to giop:tcp:192.9.10.213:1049 125 bytes
    omniORB: (4) 2010-10-20 10:44:36.757505:
    4749 4f50 0102 0000 0000 0071 0000 0008 GIOP.......q....
    0300 0000 0000 2034 0000 003c afab cb00 ...... 4...<....
    0000 0022 0000 03e8 0000 0001 0000 0000 ..."............
    0000 0002 0000 0008 526f 6f74 504f 4100 ........RootPOA.
    0000 000c 4e61 6d65 5365 7276 6963 6500 ....NameService.
    0000 0003 4e43 3014 0000 0008 7265 736f ....NC0.....reso
    6c76 6500 0000 0000 0000 0001 0000 0005 lve.............
    706c 6f70 0072 672f 0000 0001 00 plop.rg/.....
    omniORB: (4) 2010-10-20 10:44:36.758805: inputMessage: from giop:tcp:192.9.10.213:1049 210 bytes
    omniORB: (4) 2010-10-20 10:44:36.758821:
    4749 4f50 0102 0001 0000 00c6 0000 0008 GIOP............
    0000 0000 0000 0001 4e45 4f00 0000 0002 ........NEO.....
    0014 00cc 0000 0006 0000 0013 4944 4c3a ............IDL:
    434c 412f 436c 6965 6e74 3a31 2e30 002e CLA/Client:1.0..
    0000 0001 0000 0000 0000 0086 0001 0200 ................
    0000 000d 3139 312e 302e 3234 382e 3533 ....191.0.248.53
    0000 130f 0000 0031 afab cb00 0000 0020 .......1.......
    c8d0 a394 0000 0001 0000 0000 0000 0001 ................
    0000 0008 526f 6f74 504f 4100 0000 0008 ....RootPOA.....
    0000 0001 0000 0000 1400 0000 0000 0002 ................
    0000 0001 0000 0020 0000 0000 0001 0001 ....... ........
    0000 0002 0501 0001 0001 0020 0001 0109 ........... ....
    0000 0001 0001 0100 0000 0026 0000 0002 ...........&....
    0002 ..
    omniORB: (4) 2010-10-20 10:44:36.758985: Creating ref to remote: key<............................RootPOA..............>
    target id : IDL:omg.org/CORBA/Object:1.0
    most derived id: IDL:CLA/Client:1.0
    omniORB: (4) 2010-10-20 10:44:36.759010: Return 'resolve' on remote: key<............................RootPOA.....NameService.....NC0.>
    omniORB: (4) 2010-10-20 10:44:36.759063: LocateRequest to remote: key<............................RootPOA..............>
    omniORB: (4) 2010-10-20 10:44:36.759172: Client attempt to connect to giop:tcp:191.0.248.53:4879
    omniORB: (4) 2010-10-20 10:44:36.759269: Failed to connect: 191.0.248.53
    omniORB: (4) 2010-10-20 10:44:36.759329: Switch rope to use address giop:tcp:191.0.248.53:4879
    omniORB: (4) 2010-10-20 10:44:36.759355: Unable to open new connection: giop:tcp:191.0.248.53:4879
    omniORB: (4) 2010-10-20 10:44:36.759371: throw giopStream::CommFailure from giopStream.cc:1152(0,NO,TRANSIENT_ConnectFailed)
    omniORB: (4) 2010-10-20 10:44:36.759612: throw TRANSIENT from omniObjRef.cc:1137 (NO,TRANSIENT_ConnectFailed)
    omniORB: (4) 2010-10-20 10:44:36.759812: omniRemoteIdentity deleted.
    omniORB: (4) 2010-10-20 10:44:36.759830: ObjRef(IDL:CLA/Client:1.0) -- deleted.
    omniORB: (4) 2010-10-20 10:44:36.759895: ObjRef() -- deleted.
    omniORB: (4) 2010-10-20 10:44:36.759938: sendChunk: to giop:tcp:191.0.248.53:4884 28 bytes
    J'ai essayé à partir de la machine qui fait tournier le programme C d'ouvrir un telnet sur le port dur programme Java, çà passe niquel.


    Pourquoi alors omniORB n'y arrive pas ? Es-ce que çà pourrais être liée au fait que j'appel du code corba alors que je suis moi même dans le corp d'une méthode corba ???


    Je suis complétement perdu, aidez moi s'il vous plait.

    Merci d'avance.

  5. #5
    Membre habitué
    Inscrit en
    Août 2005
    Messages
    161
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 161
    Points : 193
    Points
    193
    Par défaut
    Normallement rien ne t'empêche de rappeler ton client Java depuis ton client C, même dans une méthode invoquée depuis le client Java.

    Si le prog. Java refuse la connexion c'est peut être qu'il n'est pas à l'écoute.
    -> est-ce que la boucle d'attente a bien été lancée côté Java ?

Discussions similaires

  1. Réponses: 6
    Dernier message: 10/12/2014, 10h00
  2. Problème de connexion entre Java et Postgresql
    Par kallelomar dans le forum JDBC
    Réponses: 1
    Dernier message: 30/10/2013, 17h55
  3. Problème de portée entre deux classes
    Par Shikette dans le forum Débuter avec Java
    Réponses: 1
    Dernier message: 13/11/2009, 22h32
  4. Conflit de port entre Java EE, Tomcat et Liferay
    Par safowan dans le forum Tomcat et TomEE
    Réponses: 2
    Dernier message: 11/09/2009, 17h11
  5. [JAVA] problème de port
    Par Vitorlundberg dans le forum Apple
    Réponses: 2
    Dernier message: 02/05/2007, 12h35

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo