Sometimes networks are unreliable. Additionally, sometimes the TCP/IP stack may behave undesirably. For example, given sufficient turmoil in the network, the TCP/IP stack may sometimes take a long time to recover from network problems. During this time, the connection appears to be hung.
In the Perforce 2012.2 release, the net.maxwait
configurable became fully-supported and can be found in the output of the p4 help configurables
Note: net.maxwait generally should not be set on a server, proxy, or broker as it can cause a command to end prematurely. A possible exception might be to set it on the server to a very high value (for example, 24 hours) to terminate connections such as a user opening client spec for edit and never closing the spec.
configurable should be set on the client side, as an option passed to the p4
command line client. The documented usage pattern is:
p4 -vnet.maxwait=N sync //depot/main/...
is a value in seconds. Setting it to 0
turns the feature off. Reasonable values are in the range of 60-600
When the net.maxwait setting takes affect, user commands will be interrupted and a "Partner exited unexpectedly" error will be issued. For example:
$ p4 client perfclient
Partner exited unexpectedly.
Perforce client error:
Partner exited unexpectedly.
is set on the master server, a user might run a command such as p4 client
or p4 resolve
, make edits to the related form or files, then go to a meeting, and return and lose the form edits due to the client disconnecting after the maxwait time. Therefore, it is generally not recommended to set net.maxwait
on the server. However, in some circumstances, it might be useful to set this on the server, bearing the above caveat in mind.
Enabling Command Restart
In the Perforce 2012.2 release, a new global '-r
' flag was added that allows a user to specify, when invoking the command-line client, that the particular command being run should be restarted up to a fixed number of times, if the command should encounter any sort of RPC error, such as the RPC error that occurs when a net.maxwait
So, a user who so desires can run:
p4 -vnet.maxwait=60 -r4 sync //depot/main/...
which specifies that the p4 sync
operation should never wait longer than 60 seconds for any single network read or write call to complete; and if an RPC error occurs, that the p4 sync
operation should be re-tried up to 4 total times.
flag specifies the number of times the command should be executed, should a network-related error occur. Setting it to 0
, or 1
, or omitting it entirely, means that the command will only be executed once. Setting it to 2
or higher means the command will be retried N-1
times if a network-related error occurs. Reasonable values are in the range of 2-10
It is possible to specify '-rN
' on any command, not just p4 sync
. However, for most commands it is not useful because for most commands when you retry them, they start all over from the beginning.
Other commands where 'p4 -rN
' may be of some value. For example:
p4 integrate //depot/main/... //depot/r1.0/...
p4 -vnet.maxwait=60 -r4 resolve -am
This will tell the p4 resolve
command that it can be retried, should an RPC error occur while transferring the merged files to the client.