Warnings, notes, and limitations

The following warnings, notes, and limitations apply to all configurations unless otherwise noted.

  • On target servers The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'., do not reconfigure these replica settings while the replica is running:

    • P4TARGET
    • dm.domain.accessupdate
    • dm.user.accessupdate
  • Be careful not to inadvertently write to the replica’s database. This might happen by using an -r option without specifying the full path (and mistakingly specifying the current path), by removing db files in P4ROOT, and so on. For example, when using the p4d -r . -jc command, make sure you are not currently in the root directory of the replica or standby in which p4 journalcopy is writing journal files.

  • Large numbers of Perforce password (P4PASSWD) invalid or unset errors in the replica log indicate that the service user has not been logged in or that the P4TICKETS file is not writable.

    In the case of a read-only directory or P4TICKETS file, p4 login appears to succeed, but p4 login -s generates the "invalid or unset" error. Ensure that the P4TICKETS file exists and is writable by the replica server.

  • Client workspaces on the target server and replica servers cannot overlap. Users must be certain that their P4PORT, P4CLIENT, and other settings are configured to ensure that:
    • Files from the replica server are not synced to client workspaces used with the target server.
    • Files from the target server are not synced to client workspaces used with the replica server.

  • Replica servers maintain a separate table of users for each replica; by default, the p4 users command shows only users who have used that particular replica server. (To see the target server’s list of users, use p4 users -c).

    The advantage of having a separate user table (stored on the replica in db.user.rp) is that after having logged in for the first time, users can continue to use the replica without having to repeatedly contact the target server.

  • All server IDs must be unique. Manually-assigned names might be easy to remember, but in very large environments, there might be more servers than is practical to administer or remember. Use the command p4 server -g to create a new server specification with a numeric Server ID. Such a Server ID is guaranteed to be unique.

    Whether manually-named or automatically-generated, it is the responsibility of the system administrator to ensure that the server ID associated with a server’s p4 server form corresponds exactly with the server.id file created (and/or read) by the p4 serverid command.

  • Although replicas can be chained together as of Release 2013.1, (that is, a replica’s P4TARGET can be another replica, as well as from a central server), it is the administrator’s responsibility to ensure that no loops are inadvertently created in this process. Certain multi-level replication scenarios are permissible, but pointless; for example, a forwarding replica of a read-only replica offers no advantage because the read-only replica will merely reject all writes forwarded to it. If you are considering a multi-level replica installation, contact Perforce Support for guidance.

  • The rpl.compress configurable controls whether compression is used on the target-replica connection(s). This configurable defaults to 0. Enabling compression can provide notable performance improvements, particularly when the target server and replica servers are separated by significant geographic distances.

    Enable compression with: p4 configure set fwd-replica#rpl.compress=1