Great Circle Associates Majordomo-Workers
(September 1994)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: locking in the face of multiple subscribe requests
From: Brent Chapman <brent @ mycroft . GreatCircle . COM>
Date: Tue, 13 Sep 1994 19:55:42 -0700
To: Arnold de Leon <arnold @ Synopsys . COM>
Cc: majordomo-workers @ greatcircle . com
In-reply-to: Your message of Tue, 13 Sep 1994 14:32:09 -0700

Arnold de Leon <arnold@Synopsys.COM> writes:

# 	I don't believe ordering of near simultaneous commands to
# majordomo is important.

I was actually thinking of ordering of postings via "resend", which
can be somewhat important to preserving the semantic thread of a
conversation.  I agree that ordering of commands isn't important.

In looking at it a little, it appears that "resend" doesn't use the
locking open anyway; nor can I think of any reason why it should.  So,
just ignore what I said yesterday; it don't make no sense...  Chalk it
up to staying up too late at Interop.

# 	I am planning to write a "abort, retry"
# routine for majordomo (basically cleanup and exit EX_TEMPFAIL).
# so I that several failures can be retried 
# Then I can have the lock failures optionally fail with
# "abort, retry".  This would prevent too many processes from
# waiting for locks and taking up swap space.
# 
# 	This has the advantage of using the queueing mechanism
# implemented by the mail system already.

Do mailers other than sendmail pay attention to EX_TEMPFAIL?

# Some observations and other data:
# 
# 	o it takes aprox 20 seconds to process an {un}subscribe
# 	  command on 3500+ address mailing list
# 
# 	o The time to process an {un}subscribe command
# 	  grows linearly with the size of the list.
# 
# 	o the machine I use is a Solbourne S4000DX (aprox. a
# 	  Sparcation 2 class machine)
# 
# 	o multiple majordomo processes using spin locks
# 	  causes enough trashing that a given subscribe
# 	  call would timeout if several subscribe
# 	  requests came in as separate messages.
# 
# 	o The backoff that I implemented stops backing 
# 	  off at 60 seconds.
# 
# 	o The first few retries will occur 1, 2 and 4 seconds
# 	  later.  This behaviour is similar to the spin locks 
# 	  in terms of responsives.
# 
# 	o I believe that if the lock was not available after
# 	  ~8 seconds then the resource is probably going to be 
# 	  unavailable for a while.
# 
# 	o I have been running with the backoff code for over
# 	  6 weeks.  It's definitely better than the old way.

Cool; it's clear that you've done a lot more work on this than I have,
and I was somewhat confused anyway, so never mind my earlier comments.

I _still_ want someone to implement (or point me to) a general queue
package in Perl, though...  :-)

-Brent
--
Brent Chapman         | Great Circle Associates  | Call or email for info about
Brent@GreatCircle.COM | 1057 West Dana Street    | upcoming Internet Security 
+1 415 962 0841       | Mountain View, CA  94041 | Firewalls Tutorial dates


Indexed By Date Previous: Re: X.400 address 'hostile'
From: David Kovar <kovar@NDA.COM>
Next: locking in the face of multiple subscribe requests
From: Jared_Rhine@hmc.edu
Indexed By Thread Previous: Re: locking in the face of multiple subscribe requests
From: "John P. Rouillard" <rouilj@cs.umb.edu>
Next: Re: X.400 address 'hostile'
From: David Barr <barr@pop.psu.edu>

Google
 
Search Internet Search www.greatcircle.com