LOAD MONITORING SYSTEM...

Dear, 
Please kindly send your comments on the following suggestion
for implementing a ROBUST load monitoring system for www4mail.

CASE 1 -- NEW MAIL
	If www4mail is started when the system load is 
	(a) higher than 5 - it sleeps for 200 seconds
		and tests again
	(b) higher than 7 - Exit immediately asking 
		sendmail to requeue the mail.
	(c) Number of www4mail processes > 20 -
		Exit immediately asking sendmail to requeue the mail.

CASE 2 - PROCESSING A MAIL/REQUEST
	While processing a mail or request, if the system load
	(a) higher than 5 - it sleeps for 200 seconds
		and tests again
	(b) higher than 7 - 
		Check if we have send a reply to the user already
		if so inform the user that his mail is being
		aborted and then exit.
		OR ELSE 
		Exit immediately asking sendmail to requeue the mail.
	(c) Number of www4mail processes > 20 -
                Check if we have send a reply to the user already
                if so continue processing this mail
                OR ELSE
                Exit immediately asking sendmail to requeue the mail.
 

CASE 3 - PROCESSING A SPLIT MAIL

	(a) higher than 5 - it sleeps for 200 seconds and then
		test the load average again.
	(b) higher than 7 ignore and don't exit
		Except for a time out error...
		(once processing of the split message is complete,
		the regular case 2b handling is restored).

	(c) Number of www4mail processes > 20 -
                Check if we have send a part to the user already
                if so continue processing this mail
                OR ELSE
                Exit immediately asking sendmail to requeue the mail.
  

**NOTE - 
- Cases 2 & 3 will still time out (based on TimeOutPeriod
configuration file directive) even if the processes spent the
better part of the allocated time sleeping..

 - It will be possible to change all limits discussed above (5, 7 & 200
seconds) from configuration file directives

The OTHER major ALTERNATIVE would involve www4mail trying to save the
state of processing for case 2b as opposed to sending the user a
a Server Busy error message.

Thanks
Clement Onime

Received on Wednesday, 21 April 1999 06:01:12 UTC