> "JS" == Joseph Scott <[EMAIL PROTECTED]> writes:
JS> How does postfix determine that a message has been delivered
JS> though? From reading Dan's first message, my though was the problem was
JS> doing the processing of the commit, all the db stuff, which would happen
JS> after the perl
On 18 Dec 2000, at 11:11, Gary Kline wrote:
> elm used to have a program /usr/local/bin/filter that did
> what you want to do, I think. There were concise examples
> in the elm documentation and it worked well if the load wasn't
> extremely heavy. I used the filter binar
On Tue, Dec 19, 2000 at 07:23:11AM +1300, Dan Langille wrote:
> On 18 Dec 2000, at 12:58, Vivek Khera wrote:
>
> > > "JSF" == Joseph Scott <[EMAIL PROTECTED]> writes:
> >
> > JSF>If you don't want to process a message the instant it comes in
> > JSF> (via feeding it to a perl script
On Mon, Dec 18, 2000 at 11:22:58AM -0800, Joseph Scott wrote:
>
> If the problem is load then another approach would be to heavily
> nice(1) the perl script the is launched when a commit mail comes in.
I could be wrong, but I think there's a potential problem with this
strategy -- namely
On 18 Dec 2000, at 12:11, Joseph Scott wrote:
>
> On Tue, 19 Dec 2000, Dan Langille wrote:
>
> # On 18 Dec 2000, at 12:03, Joseph Scott wrote:
> #
> # > Let's say, at a minimum you want the queue to run every 30
> # > minutes. However, if there are a large number of commits in the queue,
>
On Tue, 19 Dec 2000, Dan Langille wrote:
# On 18 Dec 2000, at 12:03, Joseph Scott wrote:
#
# > Let's say, at a minimum you want the queue to run every 30
# > minutes. However, if there are a large number of commits in the queue,
# > you may want to be able ramp up to queue processing as qu
On 18 Dec 2000, at 12:03, Joseph Scott wrote:
> Let's say, at a minimum you want the queue to run every 30
> minutes. However, if there are a large number of commits in the queue,
> you may want to be able ramp up to queue processing as quickly as every 5
> minutes. If there's only two it
On Tue, 19 Dec 2000, Dan Langille wrote:
# > If you don't want to process a message the instant it comes in
# > (via feeding it to a perl script or what ever) you'll need to setup some
# > sort of queue, then have a cron job come through and process the queue.
#
# Thanks. Since posting my orig
On Mon, 18 Dec 2000, Vivek Khera wrote:
# > "JSF" == Joseph Scott <[EMAIL PROTECTED]> writes:
#
# JSF> If you don't want to process a message the instant it comes in
# JSF> (via feeding it to a perl script or what ever) you'll need to setup some
# JSF> sort of queue, then have a cron job c
On 18 Dec 2000, at 12:58, Vivek Khera wrote:
> > "JSF" == Joseph Scott <[EMAIL PROTECTED]> writes:
>
> JSF> If you don't want to process a message the instant it comes in
> JSF> (via feeding it to a perl script or what ever) you'll need to setup some
> JSF> sort of queue, then have a cron j
On 18 Dec 2000, at 11:22, Joseph Scott wrote:
>
> On Sun, 17 Dec 2000, Dan Langille wrote:
>
> # Which list would be more appropriate for asking advice on designing a
> # mail processing strategy for FreshPorts 2 (i.e. processing all of
> # cvs-all, not just the ports)?
> #
> # I'm looking for
> "JSF" == Joseph Scott <[EMAIL PROTECTED]> writes:
JSF>If you don't want to process a message the instant it comes in
JSF> (via feeding it to a perl script or what ever) you'll need to setup some
JSF> sort of queue, then have a cron job come through and process the
JSF> queue.
Or, you c
On Sun, 17 Dec 2000, Dan Langille wrote:
# Which list would be more appropriate for asking advice on designing a
# mail processing strategy for FreshPorts 2 (i.e. processing all of cvs-all,
# not just the ports)?
#
# I'm looking for recommendations and guidance on how to capture the
# incomi
13 matches
Mail list logo
