Perforce Public Knowledge Base - P4Broker Redirection
Reset Search
 

 

Article

P4Broker Redirection

« Go Back

Information

 
Problem

Why does the "selective" mode in P4Broker appear to miss commands?

Why does P4V sometimes not refresh correctly in a replicated environment?

Solution
The Perforce broker application (P4Broker) in a replicated server environment can be set to redirect read-only commands to a read-only server, and send read-write commands to the master.  This configuration will offload work on the master server by processing the read-only commands on the replica server.

However, users using graphical clients like P4V may be confused by this command redirection behavior. If there is a time delay while the replica server updates, a refresh operation in P4V might not update the GUI as expected, because of the delay in obtaining updated data from the replica. For example, a file may be submitted in P4V, but the replica won't see the submission for a few seconds.
 
As such, delays in updates to a replica and command redirection by a broker can sometimes lead to delayed results in P4V client display updates.
 
Better understanding of the twp broker redirection modes helps to clarify the issue.

Pedantic Redirection 

This mode redirects all commands as explicitly instructed in the p4broker configuration file without exceptions.

Selective Redirection 

In selective redirection mode, the P4Broker will redirect commands normally until a command that is not redirected is encountered.  Then all commands within that session will continue to skip redirection.  Once that session completes, the P4Broker will redirect commands again.  With selective redirection, GUI users will see updates from the master immediately because redirection will be temporarily ignored.

A typical use of selective redirection is where P4Broker connects to the read-write master server and redirects read-only commands to a read-only replica as seen in Using P4Broker to redirect read-only commands.  With selective redirection set, most read-only commands will be sent to the read-only server.  But when a read-write command is encountered, the P4Broker will send read-only commands to the master and not the replica until the session completes.  Once the TCP session completes, read-only commands will be sent to the replica.

P4Broker "missing" Commands

For the most part selective redirection works with read-only replicas, but there are cases where P4V performs one command, then immediately starts a new TCP session.  The new TCP session redirects to the not yet updated replica server, leaving users wondering why they are not seeing the update immediately.

For example, suppose a P4Broker is connected to the master server but read-only commands are redirected to a read-only replica. The user has two pending changelists, and one of the pending changelists is deleted. In this example, machine gabriel:1666 is the master Perforce server, and machine 10.0.100.122:1666 is the replica read-only Perforce server.

The P4V log will look similar to the example below.  Redirection information, taken from the p4broker.log below, is added in italics:
01617720 16:37:14.319 [0x256b048] change -d 23406 master
01617720 16:37:14.382 [0x256b048][110018cd] Change 23406 deleted. master
01617720 16:37:14.382 [0x1727a08] changes -s pending -l master
01617720 16:37:14.398 [0x256b048] changes -s pending -l -u bruno -c client1 master
01617720 16:37:14.398 [0x1729df0] changes -s pending -l -u bruno -c client1 repl
01617720 16:37:14.460 [0x25682a8] fstat -m1 -Olhp -Rcu -e 23406 //client1/... repl
01617720 16:37:14.460 [0x2eb2810] fstat -m1 -Olhp -Rcu -e 23407 //client1/... master

01617720 16:37:14.460 [0x25682a8][21111977] //client1/... - no such file(s).  master 
01617720 16:37:14.460 [0x2ef7c80] fstat -m1 -Olhp -Rcu -e default //client1/... repl
01617720 16:37:14.460 [0x2eb2810][21111977] //client1/... - no such file(s). repl
01617720 16:37:14.476 [0x256b048] change -o master
01617720 16:37:14.476 [0x1727a08] change -o 23407 master
01617720 16:37:14.476 [0x2ef7c80][21111977] //client1/... - no such file(s). master
01617720 16:37:14.476 [0x2ef7c80] fstat -Olhp -Rco -e 23407 //client1/... master
The corresponding P4Broker log looks similar to:
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -d 23406' Config: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -d 23406' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l -u bruno -c client1' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l -u bruno -c client1' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l -u bruno -c client1' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-changes -s pending -l -u bruno -c client1' Action: [REDIRECT] [10.0.100.122:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e 23406 //client1/...' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e 23406 //client1/...' Action: [REDIRECT] [10.0.100.122:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e 23407 //client1/...' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e 23407 //client1/...' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e default //client1/...' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3384 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -m1 -Olhp -Rcu -e default //client1/...' Action: [REDIRECT] [10.0.100.122:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -o' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -o' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:

	2012/09/25 16:37:14 pid 3384 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -o 23407' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-change -o 23407' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -Olhp -Rco -e 23407 //client1/...' Config: [REDIRECT] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 bruno@client1 10.0.10.51 [P4V/NTX86/2012.1/442152/v71] 'user-fstat -Olhp -Rco -e 23407 //client1/...' Action: [PASS] [gabriel:1666] 
Perforce Broker info:
	2012/09/25 16:37:14 pid 3824 completed.

At first glance, the redirection from P4V in the log above appears random and incorrect.  After "p4 change -d 23406" is run on the master, P4V immediately runs "p4 fstat -m1 -Olhp -Rcu -e 23406 //client1/..." on the replica.  Ideally, the fstat command should connect to the master and not the replica to provide a better user experience.

The explanation can be seen in the P4Broker log.  The Perforce broker has two pids, pid 3824 and pid 3384. If you look at the ACTION and the PASS lines, you'll see that every pid 3824 line, including the line with "p4 change -d 23406", all connect to the master server gabriel:1666. All the pid 3384 lines including "p4 fstat -m1 -Olhp -Rcu -e 23406 //client1/..." all connect to the replica server, 10.0.100.122.  So the "p4 change -d 23406" was one process started in the P4Broker, and using selective redirection, the P4Broker continued to point all further pid 3824 commands to the Perforce master. Then P4V started a new session under pid 3384 to run "p4 fstat", so the broker pointed all further pid 3384 commands to the replica. So while P4Broker appears to be misbehaving to the user, the P4Broker is actually following its programmed rules.

Forwarding Replica as an Alternative to Selective Redirection

To avoid issues with refreshing GUI clients such as P4V, use the Perforce forwarding replica.
 
The Perforce forwarding replica will not use the P4Broker at all. The forwarding replica sends read/write commands to the master, but it waits for the replica to be updated first, then responds to the user. This makes P4V display accurate, up-to-date information. Users may believe the forwarding replica is slower due to the wait, but what really happens is the forwarding replica is waiting for the replication to finish updating prior to providing an accurate result.

Since you can set up more than one forwarding replica, forwarding replicas allow you to better load balance server usage. For example, one group of users in a network subnet would connect to one forwarding replica. Another group of users in another network subnet would connect to a different forwarding replica. This will significantly offload work from the master server.
Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255