gnats-prs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnats/665: Re: gnats/665: queue-pr -r doesn't process the incoming messa


From: bug-gnats
Subject: gnats/665: Re: gnats/665: queue-pr -r doesn't process the incoming messages in the right order
Date: Wed, 9 Aug 2006 10:15:01 -0500 (CDT)

The following reply was made to PR gnats/665; it has been noted by GNATS.

From: Stephane Chazelas <address@hidden>
To: address@hidden
Cc: 
Subject: Re: gnats/665: queue-pr -r doesn't process the incoming messages in 
the right order
Date: Wed, 9 Aug 2006 16:06:49 +0100

 On Wed, Aug 09, 2006 at 09:47:57AM -0500, Chad Walstrom wrote:
 > Interesting approach to guarantee sequential ordering.  On the
 > surface, it appears you've added some arbitrary constraints that
 > should probably be avoided.  You've introduced some magic numbers, and
 > removed the flexibility in handling large numbers of files in the
 > queue (which should only be limited by the OS constraint on directory
 > entries).
 > 
 > I'll take a closer look at it later today.  
 [...]
 
 Hi Chad,
 
 
 thanks for looking at this.
 
 I guess you refer to the arbitrary "2000" limit on the size of
 the incoming queue. Is there any other "magic number" you're
 thinking of?
 
 That's one I was not very confortable with. That limit can be
 removed. The idea was to prevent problems like: an admin not
 being aware that the "queue-pr -r" is no longer scheduled (or
 that there are some files (like core file) littering the
 "processing" directory (though he will be sent emails for every
 queue-pr -r)), but that's true that the scheduling may be
 temporarily disabled (because for instance the machine
 processing the queue is being serviced) and in that case you
 would want to be able to queue every message until the
 processing machine recovers).
 
 or like some vicious circles where the processing
 of one msg generates 2 new files which in turn generate 4, 8...
 
 The idea was to make sure those kind of problems were not left
 unnoticed, but you're right that they will get noticed when the
 file system or the directory is full or when it takes so much
 time to add an entry to a directory that several instances of
 queue-pr -q run at the same time.
 
 Have you noticed the one I submitted yesterday about mkcat?
 
 Cheers,
 Stephane
 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]