[p4dti-discussion] Re: P4DTI continues to repeat replication of entire bugzilla db

[Scott Taylor]

For those that might be curious...

After painfully debugging this issue, I found out that the initial
replication was not updating the counter in p4 logger.  The p4 counter
always contained the sequence number of the first entry in the log. 
So after 8000 bugs were properly replicated to p4, the counter
continued to contain that first sequence number.   Once p4dti polled
again to look for changes, it would get the entire 'p4 logger' of all
8000 bugs so it would start replication all over again.

To fix this problem I first ran poll.py and then manually updated the
counter with 'p4 logger -c sequence-number -t p4dti-rid'.  Everything
is working correctly now and the p4 counter is  now being updated
properly.

I was unable to find out why the counter was not being updated in
replicator.py self.mark_changes_done(p4_marker).  I stepped through
the code and the values seemed to be updating properly.  I found some
old p4dti bugs that seem to relate to this issue.  I don't know if
this bug has resurfaced in the latest p4dti release (2.3.0-1).  Since
I did not get any responses to this issue, it would seem to me that
this is a rare anomaly on my end.

If anyone thinks I might have missed something, please let me know.

thanks - Scott



On 2/6/06, Scott Taylor <staylor32 at gmail.com> wrote:
> using:
>    bugzilla-2.20
>    p4dti-2.3.0-1.i386
>    perforce 2005.2
>
> As my subject title describes, I am seeing an unfortunate issue where
> p4dti likes to replicate my entire bug db over and over again.  There
> are approximately 8K bugs which causes a significant performance hit
> to bugzilla every time p4dti wants to do this (of course now it has
> long been disabled).
>
> I had p4dti working correctly until recently when my company decided
> to update to perforce 2005.2 and modify bugzilla to add a couple more
> fields (which are not part of the jobspec nor do I need replicated).
> Since I could not locate the source of this issue, I was forced to do
> the trusty uninstall/reinstall method.  In my uninstall, I removed the
> patch, drop the p4dti tables, and remove all related jobs.  I then
> proceeded with what I believe is a 'clean' install.  Of course after
> all this I am still encountering the same issue.
>
> What I see is normal p4dti messages indicating they are replicating
> the bug and then the occasional p4dti messages that the job ## is
> being overwriting by issue ## because p4dti believes they have changed
> when in fact nothing did.  The replications are being tracked in the
> p4dti tables, however in p4dti_bugs table I am seeing something
> strange.  The p4dti_bugs field 'migrated' continues to remain NULL
> after it replicates to perforce jobs.  By looking at the field's
> details, a datetime should be inserted here.
>
> Finally some questions....
>
> Has anyone else experienced this issue?
>
> Is there a problem with the p4dti_bugs migrated field?  If so, any
> suggestions on how I can troubleshoot or fix it?
>
> Is this a compatibility issue with perforce 2005.2?
>
>
> I appreciate any help!
>
> Thanks - Scott
>