Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues

Bug 418

Summary:	Orb returns reference to myself when trying to connect to mate
Product:	JacORB	Reporter:	john.seltzer
Component:	ORB	Assignee:	Gerald Brose <gerald.brose>
Status:	RESOLVED DUPLICATE
Severity:	blocker
Priority:	P1
Version:	2.0 beta3
Hardware:	Other
OS:	AIX

Description john.seltzer 2003-11-28 21:26:51 UTC

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.

Comment 1 john.seltzer 2003-11-28 23:04:22 UTC

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).

Comment 2 Simon McQueen 2003-12-01 11:58:37 UTC

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 ***