| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2228.1 | duplicate write is still a write | TUXEDO::CHUBB | | Fri Apr 25 1997 14:28 | 10 |
| Your register_named_object call comes down to a rpc_ns_binding_export()
in the end. It will rewrite the entry even if its duplicate. It's
inefficient for CDS to check against what's already in the namespace
every time it wants to do a write.
Can you tell me what documenation you saw that led you to believe the
entry wouldn't be rewritten? We need to fix the doc. if its
misleading.
-- brandon
|
| 2228.2 | no documentation error | BHAJEE::KONRAD | pour des nouvelles aventures | Mon Apr 28 1997 09:44 | 40 |
| > Can you tell me what documenation you saw that led you to believe the
> entry wouldn't be rewritten? We need to fix the doc. if its
> misleading.
Perhaps I should have read the documentation more thoroughly. The
product guide DCE for Digital Unix on page 7-29 explains the operations
performed by register_named_object. I referred to 1. - but it only says "a name
service entry is *created* if one is not already there... " So no documentation
error, no need for a fix.
> Your register_named_object call comes down to a rpc_ns_binding_export()
> in the end. It will rewrite the entry even if its duplicate. It's
> inefficient for CDS to check against what's already in the namespace
> every time it wants to do a write.
O.k. now I understand the behavior. Some additional questions:
Question 1: does this mean that the directory containing the "modified" entry
gets skulked ??
Question 2: this also means that a server *restart* with an identical server
configuration will not be possible when the CDS master replica (the one that
contains the server's entries) is not available. That's what I also found out in
my tests. So here the second question:
Is there any workaround or strategy to avoid this single point of failure ??
Moving the master replica to another clearinghous takes quite some time. It
probably works fine when you plan to switch off the master replica e.g. for
maintenance etc. However, it seems not to be a good solution in
failover-situations.
Any other ideas??
- hermann
|
| 2228.3 | just ignore the error on export and run | FOUNDR::WOODRUFF | | Mon Apr 28 1997 10:47 | 25 |
|
> Question 1: does this mean that the directory containing the "modified" entry
> gets skulked ??
yes, the skulk time depends on the convergence factor. That is, the skulk
may not happen immediately.
> Question 2: this also means that a server *restart* with an identical server
> configuration will not be possible when the CDS master replica (the one that
> contains the server's entries) is not available. That's what I also found out in
> my tests. So here the second question:
> Is there any workaround or strategy to avoid this single point of failure ??
If you know that the server has been run before and registered properly, you
can ignore the error code from the export call and let the server run.
Or you can read the entry information from CDS and check it with the current
server's binding list to see if it is the same, if so then there is no need
to export the name service. (of course, you're note exporting endpoints,
right?)
garry
|
| 2228.4 | | BHAJEE::KONRAD | pour des nouvelles aventures | Tue Apr 29 1997 12:25 | 20 |
|
>> If you know that the server has been run before and registered properly, you
>> can ignore the error code from the export call and let the server run.
this works with the standard RPC API. We are using the XIDL C++ extension - the
registration is done within the RPC base class function register_named_object.
Since the routine also does some work to setup process-local data stuctures,
ignoring the failure probably won't help in this case :-(
>> Or you can read the entry information from CDS and check it with the current
>> server's binding list to see if it is the same, if so then there is no need
>> to export the name service. (of course, you're note exporting endpoints,
>> right?)
Same story as above since register_named_object does the whole job.
-hermann
|