Bug 2522 - Enhancement to Redundant and Flat-file implementation of the Naming Service
Summary: Enhancement to Redundant and Flat-file implementation of the Naming Service
Status: NEW
Alias: None
Product: TAO
Classification: Unclassified
Component: Name Service (show other bugs)
Version: 1.5
Hardware: All All
: P3 normal
Assignee: DOC Center Support List (internal)
URL:
Depends on:
Blocks:
 
Reported: 2006-04-27 15:57 CDT by Rich Seibel
Modified: 2006-04-27 15:57 CDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Seibel 2006-04-27 15:57:58 CDT
Not a bug, but a "hole" in the implementation.

When using the TAO Naming Service in either flat-file or redundant mode 
TAO_Storable_Naming_Context::list() throws a CORBA::NO_IMPLEMENT 
exception in case the number of child entries exceeds the chunk size 
requested (how_many). In other words, list() never returns a binding 
list iterator.

A bit of history.  The flat-file implementation (-u) is a subset of the
redundant naming service implementation (-r).  The difference is that the
flat-file implementation does not need the locking the redundant
implementation needs.  The phenomon in flat-file is a side effect left
over from the redundant implementation.

The naming service is an idempotent server, that is, it is a server that
retains no state information for its client interactions, every client
request stands alone and any request (that doesn't change the data
stored) can be repeated, that is, there is no "conversation" between
client and server.

The redundant server implementation depends on this property, since
there is no way to know which particular redundant server will service
each request.  The common implementation is to round-robin the requests.

The implementation of the iterator though is not idempotent, and does
depend on the client reaching the same server on each subsequent call.
That is, there is a conversation.  Thus, the iterator was disallowed
in the redundant implementation and it carried over into the flat-file
as well.

The best way to handle this is to be willing to accept a very large
return and pass a very large number as the how_many argument to list.
In which case, no iterator is needed.

However, it would be possible to implement the iterator for the 
flat-file case using the existing kind of iterator, but a better 
choice would be a different kind of list method that could retain 
the idempotency of the the naming service.

This new iterator would be manifested in a new method to the Naming
Service, for example, call it list_from

  void list_from ( in  unsigned long starting_pos,
                   in  unsigned long how_many_allowed,
                   out BindingList bl,
                   out unsigned long how_many_left );

   // Returns at most the requested number of bindings <how_many_allowed>
   // in <bl>.  <how_many_returned is the actual number of binding 
   // returned. <how_many_left> is the number of bindings remaining.
   // If the naming context contains additional bindings,
   // they are returned on subsequent calls.
   // 
   // This can be used to iterate through a complete list of bindings:
   // CosNaming::BindingList_var bl;
   // for ( CORBA::ULong sp=0;
   //       ctx->list_from(sp, 100, bl.out(), xx);
   //       sp += bl->length()
   //     )
   // {
   //   for(i=0; i<bl->length(); i++)
   //     do with bl
   // 

list_from would be a TAO-specific extension.