Bug 124344 (DEFECT000190601)

Summary: The server read attribute for a replica does not return where the informatiom was read from.
Product: [Novell Products] NDS SDK Reporter: Rajkumar V <vrajkumar>
Component: JNDIAssignee: Parameswaran S <sparamesh>
Status: RESOLVED FIXED QA Contact: Sundar Swamy <ssundar>
Severity: Critical    
Priority: P5 - None CC: aclark
Version: OCT 2006 NDKKeywords: English
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Rajkumar V 2005-10-10 22:54:35 UTC 


------- Bug moved to this database by vrajkumar@novell.com 2005-10-10 16:54 -------

This bug previously known as bug DEFECT000190601 at remedy/
remedy/show_bug.cgi?id=DEFECT000190601
Originally filed under the NDS SDK product and JNDI component.

---------
<remedy_version_found_in> Tao </remedy_version_found_in>
---------
<remedy_milestone> BETA 2 </remedy_milestone>
---------
<remedy_details> The server read attribute for a replica is always the
      server name where the replica resides and not always the server where
      the information was read from. For example, I issued a call to get the
      attribute NdsPartitionStrings.REPLICA_ATTRID_SERVER_NAME and I noticed
      that a connection was not added to client connection table information
      dialog. So I went out the server and downed the server and issued the
      call again. The call returned that the information about the replica
      was read from the downed server.

The test tree only had two servers in the tree. If I downed the server where
the master replica was stored, the call fails, it appears that the call is
always going to the master replica.

This brings up another point, we need the ability to do a directed read
in JNDI. </remedy_details>
---------
<remedy_notes> smerrill (  10/21/99 4:50:21 PM  Testing -  ) This has
      been fixed.
aclark (  9/14/99 5:49:04 PM  Closed - Will Not Fix ) This was reported against
the NWDS  service provider.  Verify that this is still an issue with the LDAP
service provider. We are not planning to fix this in the NDS service provider.
 </remedy_notes>
The original reporter of this bug does not have
   an account here. Reassigning to the person who moved
   it here, vrajkumar@novell.com.
   Previous reporter was skjohnson@novell.com.