[p4] Why run Reviews as Daemons?

[Todd Short (tshort)]

Solution to restarting the script: CRONJOB

--
-Todd Short
// tshort at cisco.com
// "One if by land, two if by sea, three if by the Internet."
 

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Wright, Richard
> Sent: Monday, May 22, 2006 6:45 PM
> To: 'Bryan Kuhn'; Wright, Richard
> Cc: perforce-user at perforce.com; 'Mullis,Keri-Lyn'; 'Robert 
> Cowham'; 'David Birkhead'
> Subject: Re: [p4] Why run Reviews as Daemons?
> 
> I don't think that the review daemon taxes the server either. 
>  I just can't
> imagine how a script that takes about a half second to run 
> and runs only
> 50-100 times a day could tax it more.
>  
> Anyway, errors with the server or the script are one of the 
> reasons that we
> switched, since I got tired of restarting the script every 
> couple days.  The
> script I use logs the changelist number for any failures, 
> followed by the
> error.  One of these days I'll write a script that will go 
> through that log
> daily and try to resend, but in the last 3 months only one email not
> addressed to me has failed, so it hasn't been a high priority (I have
> reviews on almost everything, mainly to make sure that the 
> script is working
> correctly).
>  
> -Rick
> 
>   _____  
> 
> From: Bryan Kuhn [mailto:bryan at infinityward.com] 
> Sent: Monday, May 22, 2006 2:49 PM
> To: Wright, Richard
> Cc: 'Robert Cowham'; 'David Birkhead'; 'Weintraub, David'; 'Mullis,
> Keri-Lyn'; perforce-user at perforce.com
> Subject: Re: [p4] Why run Reviews as Daemons?
> 
> 
> 
> I can't image that a p4 review command every minute would tax 
> the server at
> all.
> 
> 
> 
> 
> I've found that by running as a daemon you limit the 
> possibility of missing
> a change in the case of a smtp server being down or some 
> error with the
> script. The daemon can update the counter only if the email 
> was successful.
> 
> 
> 
> 
> Bryan
> 
> 
> 
> 
> Monday, May 22, 2006, 10:43:19 AM, Wright, Richard wrote:
> 
> > I rewrote our review script as a commit trigger about a 
> year ago. We were
> 
> > having a problem with the review daemon hanging when the 
> SMTP server was
> 
> > having problems.  I haven't seen any issues with an 
> additional version of
> a
> 
> > script kicking off before another finished.  In fact, even 
> after I wrote
> the
> 
> > script, we were still having issues with the script hanging 
> due to the
> SMTP
> 
> > server.  (The server would connect, but wouldn't respond 
> and the Python
> 
> > smtplib would just wait instead of throwing an exception)  
> In these cases,
> I
> 
> > had commit triggers wait for hours at times.  In the 
> meantime, Perforce
> 
> > would chug along happily running additional copies of the 
> script.  I have
> 
> > since added a timeout to the script to keep this from happening.
> 
> 
> 
> 
> > As far as performance goes, it seemed to me that having 
> this script fire
> off
> 
> > 50-100 times a day would actually cause less activity than 
> a review daemon
> 
> > asking Perforce for status every minute.  We submit about 
> 1500 changelists
> a
> 
> > month on our server, so YMMV.
> 
> 
> 
> 
> > -Rick 
> 
> >  
> 
> 
> 
> 
> > -----Original Message-----
> 
> > From: perforce-user-bounces at perforce.com
> <mailto:perforce-user-bounces at perforce.com> 
> 
> > [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Robert Cowham
> 
> > Sent: Monday, May 22, 2006 9:31 AM
> 
> > To: 'David Birkhead'; 'Weintraub, David'
> 
> > Cc: 'Mullis, Keri-Lyn'; perforce-user at perforce.com
> <mailto:perforce-user at perforce.com> 
> 
> > Subject: Re: [p4] Why run Reviews as Daemons?
> 
> 
> 
> 
> > Actually I think it is largely historical that Perforce talks about
> daemons
> 
> > since until relatively recently (2004.2 server) 
> change-commit triggers did
> 
> > not exist.
> 
> 
> 
> 
> >> The main advantage is performance. Doing anything other 
> than a quick 
> 
> >> query can me expensive and drastically slow down the 
> performance of 
> 
> >> your Perforce server.  A review daemon on the other hand 
> is a separate 
> 
> >> process. It can even be run on a separate computer. Because it is 
> 
> >> completely separate from Perforce is won't slow it down.
> 
> 
> 
> 
> > A change-commit is also a forked as a separate process, but 
> it that runs
> on
> 
> > the Perforce server machine, thus potentially impacting the Perforce
> server
> 
> > itself (of course you can fire off a remote process but that starts
> getting
> 
> > a bit messy).
> 
> 
> 
> 
> > My understanding is that no database locks are held while the commit
> trigger
> 
> > runs so you are fairly safe there.
> 
> 
> 
> 
> > I haven't investigated potential race conditions with a 
> second version of
> 
> > the same trigger being fired off before the first one has completed.
> Anyone
> 
> > investigated this?
> 
> 
> 
> 
> > Robert
> 
> > _______________________________________________
> 
> > perforce-user mailing list  -  perforce-user at perforce.com
> <mailto:perforce-user at perforce.com> 
> 
>  <http://maillist.perforce.com/mailman/listinfo/perforce-user> >
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> > _______________________________________________
> 
> > perforce-user mailing list  -  perforce-user at perforce.com
> <mailto:perforce-user at perforce.com> 
> 
>  <http://maillist.perforce.com/mailman/listinfo/perforce-user> >
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>