At 01:46 PM 3/8/02 -0800, John W Baxter wrote:
>Aside: how far we've come from the old mainframe LISTSERV, the network of
>which carefully sent one copy along with a list to addresses to various
>neighbors "near" the addressees for further distribution. So quite likely,
>only one copy crossed th
> "Jay" == Jay R Ashworth <[EMAIL PROTECTED]> writes re HTML email:
Jay> which is inherent, I think, in the (lack of) design thereof.
What lack of design? It's a near-perfect implementation of "form over
substance."
--
Institute of Policy and Planning Sciences http://turnbull.sk.t
On Fri, Mar 08, 2002 at 03:01:10PM -0800, James J. Besemer wrote:
> "Jay R. Ashworth" wrote:
> > On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote:
> > > While, OTOH I agree these more robust formats are the future, it's
> > > insane to force them on users and not allow them to turn
At 08:52 PM 04/03/02 -0800, James J. Besemer wrote:
>4. It would be nice to reuse the existing list security as an umbrealla to
>cover
>other arbitrary, list-members-only web pages. E.g., some listers hate large
>graphics attachments (and they are problematic generally). I'd like to
>remove th
> "GT" == Graham TerMarsch <[EMAIL PROTECTED]> writes:
GT> The actual size of the "config.db" file was close to 12MB when
GT> we started having major problems with it, never mind that when
GT> slurped in QRunner generally ate up 50-70MB of RAM while
GT> processing the queue.
On Friday 08 March 2002 15:07, you wrote:
> No: I said "it's going out fast", but I was confused: messages from
> other lists were going out fast. Those messages were already very slow,
> one every 20 seconds... must be the time needed to lock + read the
> list.db + unlock.
I'd expect that this i
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> What I'm witnessing now is also interesting: these personalized
F> messages go out one after the other, almost 20 seconds between
F> them. The IncomingRunner is taking up about 100% of one of the
F> CPU. The BounceRunner taking 30%
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> I've tried and installed 50,000 subscribers in one list, to
F> send them VERP messages
The good news: thanks for stressing this part of Mailman. I /think/
cvs now should perform much better. Please try it out. Mailman now
defers the fi
Heh, you're gonna hate me then, because I'm doing some significant
surgery on SMTPDirect.py. I'm probably going to throw out the
threading stuff because I can't keep it all straight in my head, but
I'm up for resurrecting it in an SMTPThreaded.py module if there's
sufficient interest.
I haven't
> > "NM" == Nigel Metheringham
> > <[EMAIL PROTECTED]> writes:
>
> NM> Ideally you would make a copy in memory, ship it down the
> NM> delivery pipeline, then work on the next copy... really only
> NM> need a few copies actually in python memory at once (pretty
> NM> much
At 15:01 -0800 3/8/2002, James J. Besemer wrote:
>However you characterize them, don't you agree they "are the future"
>(which was
>the main point of my sentence)? For better or worse, I detect an inexorable
>trend.
Trend, yes. Perhaps it's wishful thinking, but I don't think "inexorable."
Cou
@ John W Baxter <[EMAIL PROTECTED]> :
> Indeed, and that part of the thing you did was excellent. (I find it
> interesting that a second try worked somewhat well, at least initially.)
No: I said "it's going out fast", but I was confused: messages from other
lists were going out fast. Those messa
At 23:31 +0100 3/8/2002, Fil wrote:
>Sometimes you want to try and stress things, just to give beta feedback to
>Barry. I've shown a problem with computing all VERPed messages before
>sending (as opposed to *while sending*), I'm quite happy with that being in
>a beta (or alpha) moment before the m
"Jay R. Ashworth" wrote:
> On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote:
> > While, OTOH I agree these more robust formats are the future, it's
> > insane to force them on users and not allow them to turn them off.
>
> As someone who reads half of my mail in Mutt in a vt scre
@ John W Baxter <[EMAIL PROTECTED]> :
> As to VERPing a big list with the *current* tool: don't (if it hurts,
> don't do it, and I doubt whether throwing enough more hardware at the
> 50,000 address list is feasible).
Sometimes you want to try and stress things, just to give beta feedback to
Bar
At 12:15 -0500 3/8/2002, Barry A. Warsaw wrote:
>It would be really cool if we could get a bunch of MTA authors
>together (I only care about the open source ones ) to define a
>protocol for letting the MTA doing the stitching. I think Postfix,
>and probably Exim support a way to do this for the e
On Fri, Mar 08, 2002 at 11:49:39AM -0500, Barry A. Warsaw wrote:
> When you turn on VERPing Mailman makes a unique copy of each message
> for each recipient, so do the math. :)
>
> There might be a way to defer this until SMTP delivery time, in which
> case we'd only create the copies in memory w
On Wed, Mar 06, 2002 at 05:18:49PM -0800, James J. Besemer wrote:
> Chuq Von Rospach wrote:
>
> > First step is -- "I run this list, this is how I plan on running it, and if
> > you insist on yelling about this stuff on the list, I'll kick YOU off
> > first."
>
> I don't agree, certainly not wit
On Wed, Mar 06, 2002 at 11:40:11AM -0800, James J. Besemer wrote:
> Les Niles wrote:
> > (It was the release of AOL 6.0, which doesn't allow
> > turning off HTML, that prompted me.)
>
> Exactly.
>
> While, OTOH I agree these more robust formats are the future, it's
> insane to force them on user
@ Barry A. Warsaw <[EMAIL PROTECTED]> :
> Not surprising. Stop Mailman, wax those files, and I'll work out
> something better.
If it can be of interest : I had to 'kill -9' the qrunner that was running
in circles, then just restarted the whole thing, and my personalized
messages are going out at
On Wed, Mar 06, 2002 at 10:33:40AM -0500, [EMAIL PROTECTED] wrote:
> Not hard to do in MM2.1, but I doubt I'll accept much extension in
> this area. The whole backend user database will be rewritten in a
> future version and IMO, such extra information ought to be kept in an
> external database l
Would it make sense to simply cache a static copy of the page (instead of
generating live CGI on each reference)? Have a chron job update it daily
or whatever.
People would not have access to the very latest posts, but usually that's
not the point in looking up an archive.
Just thinking out l
The exim list has been running since 1996, migrated to mailman in 99,
and has all the arhives online at
http://www.exim.org/pipermail/exim-users/
I've had comments from people that this page is now too slow to load -
since I roll the archives weekly (high traffic list) there are around
30
> "NM" == Nigel Metheringham
> <[EMAIL PROTECTED]> writes:
NM> Ideally you would make a copy in memory, ship it down the
NM> delivery pipeline, then work on the next copy... really only
NM> need a few copies actually in python memory at once (pretty
NM> much just the numb
@ Nigel Metheringham <[EMAIL PROTECTED]> :
> Of course as the MTA catches these its going to make a queue file on
> disk for each one unless you can do this funky passing the VERP stuff
> down the pipeline stuff thats been mentioned on the list before.
Yes, but: my MTA's spool disk is rather larg
Not surprising. Stop Mailman, wax those files, and I'll work out
something better.
-Barry
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-developers
On Fri, 2002-03-08 at 16:49, Barry A. Warsaw wrote:
> When you turn on VERPing Mailman makes a unique copy of each message
> for each recipient, so do the math. :)
Ugh...
> There might be a way to defer this until SMTP delivery time, in which
> case we'd only create the copies in memory when tal
@ Barry A. Warsaw <[EMAIL PROTECTED]> :
> >> Do you see anything in qfiles/in?
I have freed some disk space, 'stopped' Mailman with mailmanctl, and
swapping has receded. Now I have:
$ ls qfiles/in/ -1 | wc
100199 100199 5861674
And the only Mailman process doing alot of work is
--On Friday, March 08, 2002 11:49 AM -0500 "Barry A. Warsaw"
<[EMAIL PROTECTED]> wrote:
> There might be a way to defer this until SMTP delivery time, in which
> case we'd only create the copies in memory when talking to the smtpd.
Please! Exploding onto slow disk is bad...
Also, why create
@ Barry A. Warsaw <[EMAIL PROTECTED]> :
> F> thousands... will I also run out of disk space ?
Now I have run out of disk space (wrong partition!)
-- Fil
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinf
> "F" == Fil <[EMAIL PROTECTED]> writes:
>> Do you see anything in qfiles/in?
F> Indeed:
| 1015601891.96+b81bcd9e6a652f432f5fe592826e5b04161c9675.pck
| 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.db
| 1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.pc
@ Fil <[EMAIL PROTECTED]> :
> Well! Now it has eaten up all my memory (1 Gb), and it's swapping like crazy :
OK, out of disk space now:
/dev/sda6 1.8G 1.8G 0 100% /home
-- Fil
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
h
@ Barry A. Warsaw <[EMAIL PROTECTED]> :
> Do you see anything in qfiles/in?
Indeed:
1015601891.96+b81bcd9e6a652f432f5fe592826e5b04161c9675.pck
1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.db
1015601891.96+b81f4b00e4d37f128f37df4521180e3fa9f29401.pck
1015601891.96+b821bcd0fd18a1a290e592
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> Well! Now it has eaten up all my memory (1 Gb), and it's
F> swapping like crazy :
This is just a guess (and I'll try to look at it in more detail later
today), that the act of turning a message into 50k VERP-able copies
is the problem. I
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> That's 41 minutes and not one message has gone out yet.
F> Is that normal ? (almost current cvs)
Probably not .
-Barry
___
Mailman-Developers mailing list
[EMAIL PROTECTED]
http://mail.pytho
> It seems to take forever to send a message : 'top' gives me
>
> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
> 617 mailman 18 0 49860 44M 2576 R85.5 4.3 41:05 qrunner
> /home/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s
>
> That's 41 minutes and not
In 2.1a4, and AFAICT the current cvs tree, the digest volume number
gets incremented daily regardless of the configured rate. This is
because the test for the frequency of update is combined with the
test for whether to actually update, causing the default branch --
update daily -- to be executed
I've tried and installed 50,000 subscribers in one list, to send them
VERP messages (this is weird, but they are boucners from some other mailing
list, managed with sympa).
It seems to take forever to send a message : 'top' gives me
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME
On Fri, 8 Mar 2002, Barry A. Warsaw wrote:
>
> > "HR" == Heiko Rommel <[EMAIL PROTECTED]> writes:
>
> HR> just in case somebody finds it usefull I'm including a perl
> HR> script that will largely easy the migration from Majordomo to
> HR> Mailman 2.0 - especially if you have more
> "HR" == Heiko Rommel <[EMAIL PROTECTED]> writes:
HR> just in case somebody finds it usefull I'm including a perl
HR> script that will largely easy the migration from Majordomo to
HR> Mailman 2.0 - especially if you have more than a few lists.
Cool. Have you tried it with MM2.
Hello,
two bugs :
1) when I send a Macintosh file for "mass subscription" via the web, Mailman
does not understand the Mac's linefeeds as separators for addresses, and
sees just one (wrong) address.
2) When users reply to a confirmation cookie, they usually send their cookie
followed by severa
Hi,
just in case somebody finds it usefull I'm including a perl script
that will largely easy the migration from Majordomo to Mailman 2.0 -
especially if you have more than a few lists.
The process of migration is only half-automatic since there are a
bunch of params in Majordomo which have no
42 matches
Mail list logo
