Read only archive ; use https://github.com/JacORB/JacORB/issues for new issues
Bug 473 - reference is incorrectly treated as local when implname matches
Summary: reference is incorrectly treated as local when implname matches
Status: RESOLVED DUPLICATE of bug 378
Alias: None
Product: JacORB
Classification: Unclassified
Component: ORB (show other bugs)
Version: 2.1
Hardware: All All
: P3 major
Assignee: Gerald Brose
URL: http://nenya.ms.mff.cuni.cz/~mencl/d/...
Depends on:
Blocks:
 
Reported: 2004-04-21 16:59 CEST by Vladimir Mencl
Modified: 2006-05-09 16:36 CEST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Mencl 2004-04-21 16:59:43 CEST
JacORB considers a reference local solely based on the fact that the
implname stored in the reference matches the implname property in the
local environment.

Then, if POA with the same name exists in the process, ORB delivers a
request to the wrong POA. Consequently, either the request is delivered
to a wrong Servant (in the local process instead of remote).

Steps to reproduce:
1. Start a server that:
  a. creates a POA ("myPOA")
  b. myPOA.activate_object_with_id("ID".getBytes(),myImpl)
  c. println(orb.object_to_string(myPOA.servant_to_reference(myImpl))
2. Start a second copy of the server, that also creates POA "myPOA",
   registers the myImpl object and calls a method on the reference
   printed by the first object.
3. The method is invoked locally, in the second server.

Such a sample application (modified hello world demo) is available at
http://nenya.ms.mff.cuni.cz/~mencl/d/hello-poa.zip
Run jaco.demo.server
and jaco.demo.server <the IOR output by the first server>
The method is delivered locally.

Actual Results: invocation delivered locally (to server 2)

Expected Results: remote delivery of invocation (to server 1)

Reference:
  OMG IDL to Java Mapping (formal/02-08-05) specifies (pp. 1-132)

    Local Invocation APIs
      The _is_local() method returns true if the servant incarnating
      the object is located in the same process as the stub and they
      both share the same ORB instance.

However, in JacORB, _is_local() returns true even for a remote reference,
solely based on the fact that the implname value stored in the reference
and the local property jacorb.implname match and a POA with the name
stored in the reference can be resolved.

This clearly violates the IDL to Java Mapping.

While in JacORB, the property jacorb.implname may be set to a unique
value in each process, the default behavior (without touching the
jacorb.implname property) should not violate the CORBA standard.

The description of the jacorb.implname property in the JacORB
Programmers guide says: "Persistent servers should set this to a unique
name.". However, first, this is mentioned only inside the list of
properties and second, the requirement is restricted only to persistent
servers. But, the implementation of ORB and Delegate resolves locallity
based on implname regardless of the POA LifeSpan policy.

Suggested resolution:

   is_local should be changed to return true only if the previously
   checked conditions hold and at the same time, the IP Address and Port
   stored in the reference match the local IP address and Port used by
   the ORB.

   Possible side-effect analysis:
     This change will cause that persistent references with IP and Port
     pointing to IMR will be always treated as non-local references.

     This side-effect may be resolved by adding the following hook
     to the delegate: After a LOCATION_FORWARD message is received,
     if the new destination IP and Port matches the local IP and Port,
     the reference will be flagged as local.


Technical details:

  Generated stub methods call org.omg.CORBA.portable.ObjectImpl._is_local() 
    which calls the delegate's method is_local - i.e.,
       org.jacorb.orb.Delegate.is_local(this,self), 
     calling org.jacorb.orb.Delegate.is_really_local, 
     implemented as calling org.jacorb.orb.Delegate.resolvePOA
     calling org.jacorb.orb.ORB.findPOA
Comment 1 Alphonse Bendt 2006-05-09 16:36:43 CEST

*** This bug has been marked as a duplicate of 378 ***