Anything's possible...but how could I tell if it's timing out?  I
turned on performance logging, and all I see in the log during this
transaction are:

2010-10-12 15:28:06,043 - DEBUG - DiffParser.parse: Beginning parse of
diff, size = 4108
2010-10-12 15:28:06,044 - DEBUG - DiffParser.parse: Finished parsing
diff.

So it got the diff, and parsed it...but what happened then?  That's
what I need to track down--I was hoping to get suggestions as to how.
As you can see from above, the diff file was only 4K in size, so it
wasn't large.

As mentioned above, all that appears in the access log is the POST
transaction of /r/new

Going through the log, I've got 78 fetches from SVN. Times varied
between 0 and 29 seconds(!), with the average coming out around 6.  I
extended the fcgi timeout to 60 seconds, but as I mentioned earlier,
that didn't seem to matter.

So any ideas what I should measure/activate/change to find out what
it's doing/waiting on while it's timing out?

Thanks,

m@

On Oct 12, 4:00 pm, Christian Hammond <chip...@chipx86.com> wrote:
> Another possibility is that it's your repository. If that's being slow to
> reach, things will time out in Review Board. During the creation of a new
> review request, it tries to access files from there, and can time out if it
> can't access it.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.reviewboard.org
> VMware, Inc. -http://www.vmware.com
>
> On Tue, Oct 12, 2010 at 11:14 AM, mxbraun <matthew.br...@intel.com> wrote:
> > As recommended by the installation guide, yes.  I could torpedo that
> > next time the problem pops up, and see what happens...
>
> > m@
>
> > On Oct 12, 12:50 pm, Jon Stevens <latch...@gmail.com> wrote:
> > > Are you using memcached? Maybe something with that?
>
> > > On Tue, Oct 12, 2010 at 10:41 AM, mxbraun <matthew.br...@intel.com>
> > wrote:
> > > > I was able to wipe the reviews_review database--at least I think I
> > > > did--and it seemed to be fairly happy for a while.
>
> > > > However, shortly thereafter, review creation would time out, even for
> > > > a single-line diff.  I turned on logging and enabled code profiling,
> > > > but the log showed no new entries when I'd try to create the review.
> > > > The only thing that the access log showed was a POST operation to /r/
> > > > new, which returned with a timeout error code.
>
> > > > After receiving the timeout message, I would go to my "Outgoing
> > > > reviews" section, and a new review had been created, and was available
> > > > to me.  (FWIW, I've seen this behaviour on the 0.8 beta as well.)
>
> > > > Today, the problem has gone away, and I can't reproduce the timeout.
> > > > I suspected that maybe the database was being backed up, or was
> > > > otherwise unavailable, but that seems unlikely, as the only thing in
> > > > it is one or two reviews. If there was a problem, it should have gone
> > > > away quickly because the backup should have finished quickly.
>
> > > > I extended fastcgi's timeout to 60 seconds, but that only increased
> > > > the amount of time I had to wait for the failure report.
>
> > > > Any suggestions for how to proceed in debugging this?  While the
> > > > problem has gone away for the moment, I suspect it shall return.
>
> > > > Thanks,
>
> > > > m@
>
> > > > On Oct 11, 10:48 pm, Christian Hammond <chip...@chipx86.com> wrote:
> > > > > Yes, you absolutely want the reviews_reviewrequest table.
>
> > > > > I assume it's too late to wipe the database for reviews_review? :)
> > Not
> > > > that
> > > > > that one matters much (it's not often exposed).
>
> > > > > Christian
>
> > > > > --
> > > > > Christian Hammond - chip...@chipx86.com
> > > > > Review Board -http://www.reviewboard.org
> > > > > VMware, Inc. -http://www.vmware.com
>
> > > > > On Mon, Oct 11, 2010 at 8:42 PM, mxbraun <matthew.br...@intel.com>
> > > > wrote:
> > > > > > Jon,
>
> > > > > > Did this really do what you wanted?  I find myself in much the same
> > > > > > situation, of having an ancient RB implementation in use, setting
> > up a
> > > > > > more modern one, and the prospect of either keeping the old one
> > around
> > > > > > for some indeterminite amount of time.
>
> > > > > > The question I have is: isn't reviews_review a table of completed
> > > > > > reviews?   The 'id' field in reviews_review seems to have the
> > > > > > auto_increment attribute.
>
> > > > > > Isn't the thing you want to adjust reviews_reviewrequest table, so
> > > > > > that the review *request* numbers don't collide with the old ones,
> > > > > > rather than the completed review records? .
>
> > > > > > Once I executed ALTER TABLE reviews_reviewrequest 20000; I got
> > review
> > > > > > requests numbered up that high.
>
> > > > > > (Of course, I changed reviews_reviewrequest *after* changing
> > > > > > reviews_review.  So now my IDs in the reviews_review table are
> > > > > > starting at around 20000.  Gulp!)
>
> > > > > > Thanks,
>
> > > > > > m@
>
> > > > > > On Aug 21, 6:48 pm, Jon Stevens <latch...@gmail.com> wrote:
> > > > > > > Lol. That confirms my suspicions. No worries, we are fine just
> > > > > > mothballing the old release and I'll set the review number to be
> > n+1.
> > > > Thanks
> > > > > > for the help!
>
> > > > > > > Jon
>
> > > > > > > On Aug 21, 2010, at 11:40 AM, Christian Hammond <
> > chip...@chipx86.com
>
> > > > > > wrote:
>
> > > > > > > > In that case, an upgrade could potentially be tricky... Yeah,
> > might
> > > > > > want to just start off with a new install.
>
> > > > > > > > Christian
>
> > > > > > > > --
> > > > > > > > Christian Hammond - chip...@chipx86.com
> > > > > > > > Review Board -http://www.reviewboard.org
> > > > > > > > VMware, Inc. -http://www.vmware.com
>
> > > > > > > > On Sat, Aug 21, 2010 at 7:22 AM, Jon Stevens <
> > latch...@gmail.com>
> > > > > > wrote:
> > > > > > > > I'm inheriting this installation so I'm not entirely sure of
> > it's
> > > > > > history. I believe that it was essentially a checkout of the source
> > > > code at
> > > > > > some point at least a couple years ago and has never been upgraded.
>
> > > > > > > > jon
>
> > > > > > > > On Sat, Aug 21, 2010 at 12:11 AM, Christian Hammond <
> > > > > > chip...@chipx86.com> wrote:
> > > > > > > > Hi Jon,
>
> > > > > > > > It really depends on how old the version is. Unfortunately, at
> > that
> > > > > > time, we didn't really have version numbers that meant anything.
> > Can
> > > > you
> > > > > > tell me how you performed database upgrades on the old install? Was
> > it
> > > > using
> > > > > > the old load-db.py and dump-db.py scripts, or was it using
> > ./manage.py
> > > > > > evolve?
>
> > > > > > > > Also, were you using rb-site?
>
> > > > > > > > Christian
>
> > > > > > > > --
> > > > > > > > Christian Hammond - chip...@chipx86.com
> > > > > > > > Review Board -http://www.reviewboard.org
> > > > > > > > VMware, Inc. -http://www.vmware.com
>
> > > > > > > > On Fri, Aug 20, 2010 at 9:05 PM, Jon Stevens <
> > latch...@gmail.com>
> > > > > > wrote:
> > > > > > > > Hi Christian,
>
> > > > > > > > Thanks for the fast response. I haven't tried upgrading things.
> > I
> > > > guess
> > > > > > I could try that, but I got the impression from somewhere that it
> > would
> > > > be
> > > > > > difficult to do so from the early version that we are currently
> > > > running. If
> > > > > > you think it is worth trying, then that is probably the ideal
> > route.
>
> > > > > > > > cheers,
>
> > > > > > > > jon
>
> > > > > > > > On Fri, Aug 20, 2010 at 8:16 PM, Christian Hammond <
> > > > > > chip...@chipx86.com> wrote:
> > > > > > > > Hi Jon,
>
> > > > > > > > Your plan to use ALTER TABLE should work. review_request_id
> > just
> > > > holds
> > > > > > the current ID. That's what should be auto_increment. I think so
> > long
> > > > as you
> > > > > > do that, you'll see the review request ID number you expect.
>
> > > > > > > > By the way, what problems did you hit with upgrading?
>
> > > > > > > > Christian
>
> > > > > > > > --
> > > > > > > > Christian Hammond - chip...@chipx86.com
> > > > > > > > Review Board -http://www.reviewboard.org
> > > > > > > > VMware, Inc. -http://www.vmware.com
>
> > > > > > > > On Fri, Aug 20, 2010 at 5:47 PM, jon <latch...@gmail.com>
> > wrote:
> > > > > > > > Apologies if this has been covered before, google didn't seem
> > to
> > > > have
> > > > > > > > an obvious answer. Is it possible to set a starting review #
> > for a
> > > > > > > > clean install?
>
> > > > > > > > The issue is that we have a pre-1.0 installation that has been
> > in
> > > > use
> > > > > > > > for awhile now. Instead of trying to figure out how to upgrade
> > the
> > > > > > > > database, I've just created a fresh new installation (of
> > 1.5rc1) on
> > > > a
> > > > > > > > fresh new server and we are just going to consider the previous
> > > > > > > > version effectively read-only.
>
> > > > > > > > But, on the new server, I'd like to start the review number +1
> > > > higher
> > > > > > > > than the old server so that we don't have conflicting numbers
> > in
> > > > svn
> > > > > > > > commit messages.
>
> > > > > > > > I see that reviews_review.id is auto_increment. I know that I
> > can
> > > > do:
> > > > > > > > "ALTER TABLE reviews_review AUTO_INCREMENT = 100;", but I also
> > see
> > > > a
> > > > > > > > 'review_request_id' column. What is that used for? Do you see
> > any
> > > > > > > > other issues with this approach?
>
> > > > > > > > thanks,
>
> > > > > > > > jon
>
> > > > > > > > --
> > > > > > > > Want to help the Review Board project? Donate today athttp://
> > > > > >www.reviewboard.org/donate/
> > > > > > > > Happy user? Let us know athttp://www.reviewboard.org/users/
> > > > > > > > -~----------~----~----~----~------~----~------~--~---
> > > > > > > > To unsubscribe from this group, send email to
> > > > > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> > <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com>
>
> > > > <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com>
> > <reviewboard%252bunsubscr...@googlegroups.com<reviewboard%25252bunsubscr...@googlegroups.com>
>
> > > > > > > > For more options, visit this group athttp://
> > > > > > groups.google.com/group/reviewboard?hl=en
>
> > > > > > > > --
> > > > > > > > Want to help the Review Board project? Donate today athttp://
> > > > > >www.reviewboard.org/donate/
> > > > > > > > Happy user? Let us know athttp://www.reviewboard.org/users/
> > > > > > > > -~----------~----~----~----~------~----~------~--~---
> > > > > > > > To unsubscribe from this group, send email to
> > > > > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> > <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com>
>
> > > > <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com>
> > <reviewboard%252bunsubscr...@googlegroups.com<reviewboard%25252bunsubscr...@googlegroups.com>
>
> > > > > > > > For more options, visit this group athttp://
> > > > > > groups.google.com/group/reviewboard?hl=en
>
> > > > > > > > --
> > > > > > > > Want to help the Review Board project? Donate today athttp://
>
> ...
>
> read more »

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to