I am trying to connect to my mate. My mate on another machine has the same named POA and interface name. The object key is the same. However, the ior that I'm using to connect to my mate has a different host and port than I do. When I invoke _non_existent, everything looks ok: ----------------------------------------------------------------- 11/28 13:44:42:ERR:[TnhsGateway]:[jacorb] DEBUG : ClientConnectionManager: found conn to target 132.197.138.45:9026 11/28 13:44:42:ERR:[TnhsGateway]:[jacorb] DEBUG : ServantDelegate: non_existent: return false ----------------------------------------------------------------- The IP address is correct. It's the address of my mate. However, when I try to talk to my mate, this is what the stack trace shows: ------------------------------------------------------------------------------ 11/28 13:44:42:ERR:[TnhsGateway]: at com.gte.idl.TNHSGateway._TNHSGatewayInterfaceStub.syncNarUpdate(Unknown Source) 11/28 13:44:42:ERR:[TnhsGateway]: at com.gte.nemow.server.TnhsGateway.NarUpdateSyncOperation.performMateOperation (NarUpdateSyncOperation.java:76) ------------------------------------------------------------------------------ As you can see, even though I've connected to my mate, when I try to use the object that I just connected to on my mate, I end up connecting to MYSELF! Here is a sample of the IOR in question: ------IOR components----- TypeId : IDL:TNHSGateway/TNHSGatewayInterface:1.0 TAG_INTERNET_IOP Profiles: Profile Id: IIOP Version : 1.2 Host : 132.197.138.45 Port : 9026 Object key (URL): StandardImplName/TnhsGatewayInterfaceImplPOA/TNHSGatewayInterface Object key (hex): 0x53 74 61 6E 64 61 72 64 49 6D 70 6C 4E 61 6D 65 2F 54 6E 68 73 47 61 74 65 77 61 79 49 6E 74 65 72 66 61 63 65 49 6D 70 6C 50 4F 41 2F 54 4E 48 53 47 61 74 65 77 61 79 49 6E 74 65 72 66 61 63 65 -- Found 2 Tagged Components-- #0: TAG_ORB_TYPE Type: 1245790976 (JacORB) #1: TAG_CODE_SETS ForChar native code set Id: ISO 8859-1 Char Conversion Code Sets: UTF-8 ForWChar native code set Id: UTF-16 WChar Conversion Code Sets: UTF-8 Components in MULTIPLE_COMPONENTS profile: 1 #0: TAG_CODE_SETS ForChar native code set Id: ISO 8859-1 Char Conversion Code Sets: UTF-8 ForWChar native code set Id: UTF-16 WChar Conversion Code Sets: UTF-8 ------------------------------------------------------------- This is a show stopper because it means that none of our fault tolerant servers can talk to each other. Instead, they just talk to themselves.
on 2/10/2003, in bug 313, the following was proposed: -------------------------------------------------------------------- "The problems you are getting are clearly realted to how JacORB determines whether an object is local or not. Essentially it assumes an object is local if both the server name and poa name match. Reading the POA specifications it is really up to an application designer to ensure that all POA names are unique (i.e. you shouldn't really be using the same POA name in different server). Can you try giving each server a different server name (set the "jacorb.implname" property). I think if you do this then JacORB should be able to handle duplicate POA names." -------------------------------------------------------------------- I've tried this. Although it sort of works, it completely negates the persistency of this object. If I make jacorb.implname be, for instance, the name of the server, then the ior created for this object will have that implname in it's ior. If I then move this service to another machine, I CANNOT connect to this object again with the old ior, even though everything else about the ior remains the same. I'd have to make remote clients get updated with the new ior whenever the service gets moved to another machine. A completely impractical idea. The above statement says that: "Essentially it assumes an object is local if both the server name and poa name match." I claim that it can only be local if the host and port also match(at the least).
This behaviour is by design and as per the spec. John - If you migrated a persistent server to another machine you would not be able to connect using the old IOR even if the object keys remained the same because the addressing info in the old IOR (host and port etc.) would point to the old machine, not the new one. The use case you are describing is best addressed by the use of an Implementation Repository. See chapter 6 in http://www.jacorb.org/releases/2.0beta1/ProgrammingGuide.pdf. *** This bug has been marked as a duplicate of 313 ***