1 Status of MultiSite Software Change Requests
This
file contains descriptions of noteworthy problems in Version 2002.05.00 of
Rational ClearCase MultiSite.
Note: The ClearCase Product Family development
group has switched to a new change request system since ClearCase 4.0 was
released. ID numbers differ between these two systems. This document lists
both numbers. The new number appears first and includes a CMBU prefix. The
former five-digit number appears in parentheses.
Known Problems in This Release
-- #CMBU00021382 (#24093)
when importing packets in a specific storage class, packets in the default
bay are imported also
-- #CMBU00057422 incorrect
error message printed when instance denial prevents a request for mastership
of a branch type
#CMBU00013462 (#15179) no explanation for non-applicable packet by syncreplica
If syncreplica –import determines
that a packet is not applicable, it does not print the reason. Also, syncreplica –import uses
different criteria than the lspacket command does to determine whether
a packet is applicable. Therefore, lspacket may show that a packet is applicable
even if syncreplica will
not import it.
#CMBU00015700 (#17689) –maxsize option for syncreplica works incorrectly
If
a single version’s cleartext is larger than the value specified for –maxsize, syncreplica creates
the packet and prints a warning message. The –maxsize value is ignored for the packet creation;
the packet is at least as large as the file and also includes header information.
#CMBU00018640 (#20977) import failure during mkhlink operation
This
problem occurs when one update packet includes an operation that attempts
to create a hyperlink and another packet includes an operation that removes
an object at either end of the hyperlink.
Workaround: Retry the import. To prevent multiple simultaneous
imports, use the sync_receive script.
#CMBU00018695 (#21039) import failure during branch/version creation
When
two or more imports occur simultaneously at a replica, the following error
message may be displayed:
Workaround: Retry the import. To prevent multiple
simultaneous imports, use the sync_receive script.
#CMBU00020860 (#23505) restorereplica oplog entry can be deleted prematurely
When
a replica is restored using optimization (that is, it does not exchange packets
with all other replicas in the VOB family), the special restorereplica oplog entry can be deleted prematurely
at the replicas that exchanged updates with the restored replica. In order
for all replicas in the VOB family to reflect the correct state of the restored
replica, they all must receive the restorereplica oplog entry in an update packet.
For
example, assume that replica evanston synchronizes daily with replica paris, paris synchronizes weekly with replica osaka, and osaka synchronizes monthly with evanston:
The administrator at evanston restores
the replica from backup and enters the restorereplica command. Because evanston and paris exchange updates so frequently, the evanston administrator decides to optimize the restoration;
after the update packet from paris is received and processed at evanston, the administrator enters the restorereplica –override command to complete restoration at evanston. At this point, the special restorereplica oplog entry is deleted at evanston, and the next time paris receives and processes an update packet,
the oplog entry is deleted there. However, if paris does not send an update packet to osaka before deleting the oplog entry, osaka will have an inconsistent view of evanston’s state.
The symptom of this problem is that
the restored replica cannot import update packets sent from replicas that
did not receive the restorereplica oplog entry. Imports fail with messages like the
following:
multitool: Error: Replica incarnation for “evanston” is old: 12/31/69 19:00:00, should be 09/08/97 15:15:41 multitool: Error: Cannot apply sync. packet
#CMBU00021382 (#24093) when importing packets in a specific storage class, packets in the default bay are imported also
When you use syncreplica –import –receive –sclass to import only packets associated
with a specific storage class, syncreplica also processes packets in the default
storage bay.
#CMBU00021487 (#24209) replica-creation packet not removed if mkreplica interrupted
If
the export phase of a mkreplica command is interrupted and the replica-creation
packet is not transferred to the new site, the packet is not deleted.
#CMBU00022378 (#25197) renaming of replica during removal is not recorded in oplog
When
you remove a replica, the rmreplica command renames the replica object.
However, the rename operation is not recorded in the operation log, so migration-mode
replicas do not rename the replica object automatically. Replicas not in migration
mode rename the replica when they replay the rmreplica oplog entry.
Workaround: Explicitly rename the removed replica.
For example, if a replica named natick was removed:
Note: This
is not an issue when removing the second-to-last replica in a VOB family,
which disables replication in the VOB and deletes all replica objects except
for the current replica object.
#CMBU00024116 (#27117) import can fail with message: read from input stream failed
If
a syncreplica –import command fails with a message like multitool: Error: Read from input
stream failed: No such file or directory,
the packet is corrupted.
Workaround: Delete the packet, ask the administrator at the
sending site to re-create the packet and send it again, and then import it.
#CMBU00026057 (#29223) chepoch does not set new replica’s column correctly
Using lsepoch and chepoch to
recover a lost packet does not work if that packet included both a mkreplica operation
and oplogs from that new replica. The reason is that the lsepoch output (at the replica that did not
receive the packet) will not contain any information about the new replica,
and the chepoch command
at the sending replica modifies the epoch table according to the information
in the lsepoch output.
2 At
Replica A, the administrator enters a mkreplica –export command to create Replica C and sends
the packet to the new site, where the administrator imports the replica-creation
packet. Development starts at Replica C.
4 Replica
A sends its weekly synchronization packet to Replica B. This packet contains
the mkreplica operation
that created Replica C, along with work done at Replica C. The packet is lost
before it gets to Replica B.
5 The
administrator at Replica B enters an lsepoch command and sends the output to the
administrator at Replica A. However, because Replica B does not know about
Replica C, Replica B’s epoch table does not have information about Replica
C, and neither does the lsepoch output:
The chepoch command
does not reset the column for Replica C to zero. Therefore, Replica A’s
epoch table incorrectly shows that Replica B received the mkreplica operation for Replica C and all the
work Replica C has done.
#CMBU00028738 (#32208) syncreplica —import ignores VOB lock if exception list exists
If a VOB is locked and there is an
exception list (that is, the –nusers option was used), syncreplica– import ignores the lock.
#CMBU00043999 syncreplica does not propagate all directory comments
An
automatically generated comment for a directory checkout is not replicated
in the following situation:
When
you enter a lscheckout –areplicas command at the sibling replica, the
comment generated in Step 1 is listed, but the comment
generated in Step 4 is not.
#CMBU00056555 misleading information in syncreplica error message
When syncreplica –import reports that a packet cannot be imported
because it depends on changes not yet received, the message may include one
or more lines like the following:
This
information may not be correct; the VOB may have more than 0 operations from
the specified replica.
#CMBU00057422 incorrect error message printed when instance denial prevents a request for mastership of a branch type
When a request for mastership of
a branch type fails because requests are denied for one of more instances
of the type, the error message says:
Requests for mastership are denied for one or more instances of the branch type, which prevents requests for mastership of the branch type itself.
Problems Fixed in MultiSite Version 2002.05.00
Table 1 lists significant problems in previous MultiSite
releases that are fixed in this release.