|Title||P4DTI Windows Service stalls after a few days|
|Assigned user||Nick Barnes|
|Description||A customer running P4DTI 1.3.3 for TeamTrack as a Windows Service is reporting that the replicator is "stalling" after a few days .|
They are running P4DTI 1.3.3 for TeamTrack on Windows 2000 Server[4,5,6,7].
The P4DTI is running on their TeamTrack server, which is in their DMZ. Their Perforce server is inside their internal firewall. Their internal firewall is configured to give the P4DTI access to the Perforce server.
The P4DTI is running as a Windows service (because they can't get long-term CLI access to that machine). This is why they are running P4DTI 1.3.3 and not a supported release (e.g. 1.2.1).
They have the P4DTI configured so that it can send e-mail messages (e.g. to the administrator).
The replicator runs normally for periods of a few days, replicating activity in both directions between TeamTrack and Perforce.
Every few days, the replicator stops replicating. It doesn't send any e-mail message or event log message indicating a problem; it just stops performing any useful replication activity.
When they notice that replication has stopped, they "restart" it. It then sends many replication conflict messages.
[NB 2002-03-27] In fact, the customer's replicator is not stalled. It's just backed-off exponentially so far that it looks stalled. See job000486. The fact that all their polls are failing (due to deleted TeamTrack issues[14,15,16], job000076) means that polls are also taking longer and longer and may end up in some sort of resource exhaustion [8,9,10,11,13]
|Analysis||Analysis of the log fragments in [12,14] clearly shows the exponential back-off (due to deleted TeamTrack issues, job000076).|
|Created by||Nick Barnes|
|Created on||2002-03-21 15:51:57|
|Last modified by||Nick Barnes|
|Last modified on||2002-03-27 15:48:01|
|History||2002-03-21 NB Created.|