Bug 133 - When handling a forward request we may get forwarded to a collocated object
Summary: When handling a forward request we may get forwarded to a collocated object
Status: RESOLVED FIXED
Alias: None
Product: TAO
Classification: Unclassified
Component: ORB (show other bugs)
Version: 1.0
Hardware: All All
: P2 normal
Assignee: Johnny Willemsen
URL:
Depends on: 1495 1496
Blocks: 1919
  Show dependency tree
 
Reported: 1999-07-26 17:27 CDT by Ossama Othman
Modified: 2006-06-07 07:44 CDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ossama Othman 1999-07-26 17:27:30 CDT 
When handling a forward request we may get forwarded to a collocated object. The
typical scenario is a server that register with the Implementation Repository:
if it creates an object reference to a local object the object reference will be
pointing to the ImplRepo and potentially none of its profiles will match the
local ones. Trying to contact the ImplRepo will result in a LOCATION_FORWARD
exceptions (and/or a LocateReply) pointing to the local endpoints, but now we
should use collocation.
Comment 1 Ossama Othman 1999-07-26 18:51:59 CDT 
Forgot to add a summary.
Comment 2 Carlos O'Ryan 1999-08-04 11:33:59 CDT 
Nanbor is the collocation expert in the group, he is better prepared to give an
answer to this problem.
Comment 3 Nanbor Wang 1999-08-12 09:37:59 CDT 
I accept.  This is an interesting question.
Comment 4 Carlos O'Ryan 2003-04-21 11:50:22 CDT 
Bugs 1495 and 1496 split the work for this bug in two parts:

Bug 1496 describes how to make sure that a call in-progress changes from the
remote path to the collocated path.  It is a more involved problem that requires
major changes to the ORB.

Bug 1495 describes how to make subsequent calls work.  It is truly a separate
problem, and can be fixed independently.  It is also a much more important fix
for me.
Comment 5 Johnny Willemsen 2004-05-10 11:10:40 CDT 
This is mine, fixes are in the repo, need to do just a last retest and then we 
could close this.
Comment 6 Johnny Willemsen 2004-05-10 11:15:27 CDT 
accept
Comment 7 Johnny Willemsen 2004-06-18 05:46:34 CDT 
The bugs on which this one depends are fixed. I must still retest this with the 
implementation repository as the original report describes
Comment 8 klyk 2004-09-21 06:42:38 CDT 
Bug 1919 proves that the problem still exists (when we are dealing with the
IMR). This bug should therefore be addressed before 133 can be finally closed.
Comment 9 Johnny Willemsen 2006-06-07 07:44:29 CDT 
Bug 1919 has been validated as fixed meaning we can close this one now