On Nov 3, 2008, at 11:17 AM, John Collins wrote:

>

J-

Those pages you linked were way over my head I dabble, mostly by
trial and error

What I'm trying to get at is, it's all completely over my head I
don't expect you to understand it, but I hope everyone understands I'm
just a hack at this myself

If you want to play with all of this, looking into the Config pm
file for the DBI paramaters passed:

$DBI_PARAMS ||= {

InactiveDestroy => 1, pg_server_prepare => 0, mysql_auto_reconnect => 1, };

Is found in the Config pm file within the DADA folder However, I
am using an external config file and that snippet does not appear in
it Does that matter?

You may have noticed that the great majority of the variables in the
Config pm aren't in the outside dada_config file Yes, you can add
other variables

If you don't know what you're doing I wouldn't play with this exact
variable - I don't know what you should do to stop MySQL connections
from not dying, or if you can, I'm just trying to point out some
interesting bits to play with I worked on your problem all day
Sunday - still, no clue To solve this problem, I'm going to need
someone who can run the test suite, can look at the process table, can
tell me some interesting bits of information on how the webserver is
configured

Or, I need someone to hire me to do all that It's a problem I'm not
seeing on my limited amount of hardware setups I can only guess what
it may do, in hopes that someone may be able to pick up the thread,
which I'm continually understanding that no one will

Further, I've found in the Config pm file the reference to the DB
being mysql and all the settings These same settings also appear
in the external config file Does that create excess traffic in
connecting to the DB?

no The variables set in the outside config file override anything
in the Config pm file That's the concept of the outside config file

On Nov 3, 2008, at 11:17 AM, John Collins wrote:

>

J-

Those pages you linked were way over my head I dabble, mostly by
trial and error

Quick question for you, tho This snippet:

At 7:45 PM -0500 11/2/08, Justin J wrote:

If you want to play with all of this, looking into the Config pm
file for the DBI paramaters passed:

$DBI_PARAMS ||= {

InactiveDestroy => 1, pg_server_prepare => 0, mysql_auto_reconnect => 1, };

Is found in the Config pm file within the DADA folder However, I
am using an external config file and that snippet does not appear in
it Does that matter?

Further, I've found in the Config pm file the reference to the DB
being mysql and all the settings These same settings also appear
in the external config file Does that create excess traffic in
connecting to the DB?

Note, too, that I had the same stalling problems with 2 10 16,
sometimes it would quit sending for a couple of minutes, but it
would not kick out with a server 500 error It would eventually
start sending again

Westhost tells me that even at full speed with bounces coming back
to the return path address, bounces, that I am lightly loading the
mail server

Wish I could test it again today, but I cannot hit my list again so
soon

Sorry for the inconvenience

John

At 7:45 PM -0500 11/2/08, Justin J wrote: >

>

The below solution was suggested to me from Westhost Tech Support

Dear John,

I've been looking into the issue further and I am seeing that
what is happening is that Dada Mail is not properly closing MySQL
connections Your MySQL server allows a maximum of 100 concurrent connections
[ ] Dada Mail for some reason is never closing its database
connections The lingering idle connections eventually cause the
server to reach the maximum number of connections, which in turn
causes the 500 error when Dada Mail tries to refresh the page and
make a new connection

I've changed the MySQL server to automatically kill idle
connections after 2 minutes This should prevent the 500 error
from occurring

I'm interested in the prognosis, but I don't know about the solution

What this - auto-killing the MySQL connections, might do is also
kill your mailings after 2 minutes I'm pretty sure I've made my
absolute best shot at making sure that once a mailing is off the
ground, you won't need to query the MySQL server, so this advice
may infact, work really well - I don't know, for example, THIS is
why we still have the temporary copy of the mailing list in that
bizarre arcane format

If it works, great, but why do we have 100 - one hundred
concurrent connections going on?

One possibility is that Dada Mail is making WAY too many MySQL
connections when it runs I try to attempt to share the database
handle with the entire program, so only one connection is used per
instance of a running Dada Mail Either this isn't working
correctly, or, we have some sort of garbage collection problem,
where these handles are never dereferenced Here's more of an
explanation:

http://perldoc perl org/perlobj html#Two-Phased-Garbage-Collection

The other problem may be something to do with this issue:

http://www issociate de/board/post/250580/forking_and_InactiveDestroy html

http://www perlmonks org/?node_id=265024

There's an issue with the Perl DBI and forking a process that has a
database handle - which Dada Mail has, when it starts out a mass
mailing There's a solution to the problem - but it's not something
Dada Mail does, it does a workaround:

http://search cpan org/~timb/DBI-1 607/DBI pm#InactiveDestroy_(boolean)

The part you want to pay attention is:

"This attribute is specifically designed for use in Unix
applications that "fork" child processes Either the parent or the
child process, but not both, should set InactiveDestroy true on all
their shared handles "

Dada Mail doesn't do this - it only calls this, "once" I don't
quite now how, yet, how to do the magic that's needed

If all this is geeky-sounding - it is And starts to fall off my
own knowledge, honestly, on how this all works

If you want to play with all of this, looking into the Config pm
file for the DBI paramaters passed:

$DBI_PARAMS ||= {

InactiveDestroy => 1, pg_server_prepare => 0, mysql_auto_reconnect => 1,

};

Cheers,

-- Justin J

Dada Mail - Write Once: Distribute Everywhere Software url: http://dadamailproject com

Demo: http://demo dadamailproject com

Seen Dada Mail 3? http://dadamailproject com/features/3_0/

On Nov 2, 2008, at 4:52 PM, John Collins wrote:

>

The below solution was suggested to me from Westhost Tech Support

Dear John,

I've been looking into the issue further and I am seeing that what
is happening is that Dada Mail is not properly closing MySQL
connections Your MySQL server allows a maximum of 100 concurrent connections
A typical MySQL connection lasts for a few milliseconds -- a
connection is established, the program runs a query to get some
information from the database, then the connection is closed Dada
Mail for some reason is never closing its database connections
The lingering idle connections eventually cause the server to
reach the maximum number of connections, which in turn causes the
500 error when Dada Mail tries to refresh the page and make a new
connection

I've changed the MySQL server to automatically kill idle
connections after 2 minutes This should prevent the 500 error
from occurring You may wish to contact Dada Mail and see if they
have any information about why the Dada Mail program is not
properly closing connections to the MySQL server Thank you for choosing WestHost Best regards, Technical Support Representative WestHost Inc

At 2:12 PM -0800 11/2/08, John Collins wrote:

It just quit again To be more specific, when it kicks out of the
Monitor screen after having stalled the error reads thus:

Program Error (Server Error 500)

can't connect to db: at /DADA/App/Guts pm line 625

Same as prior message below=================

Mine is doing the same thing as described by Carl K , below It
finally quits, sending with a 500 server error on mail cgi and I
have to restart the vps to get it going again (I'm on a semi- dedicated hosting account with Westhost) This has only started
happening with my upgrade to 3 0, including a mysql backend

I spoke to Westhost support and they tell me that there are no
problems with sendmail or the server It is not backed up, no
messages are queued The bandwidth is not choked It only
appears that Dadamail stops sending or times out

I went back to 2 10 16 and flat file databases and it made it all
the way through But I watched the progress page carefully as it
was sending and sometimes none would be sent for as much as two
minutes It would try to reload--or restart as it is called--but
no messages were sent Then, inexplicably it would start again
2 x would not kick out with the aforementioned server error as
3 0 does

Perhaps (?) there is a shorter timeout period with 3 that would
cause the app to quit

I have a large list: 19000+, so I don't want to waste time
sending with large delays between batches In 3 0, I slowed it
down by trying to send in batches of 30 with five sec in between
and also tried not batch sending In 2 x I always sent in
batches of 4000 with a minute in between without it quitting

Here's a piece of the error log:

[Sun Nov 2 13:24:14 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:16 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:16 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:18 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:18 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:19 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:24 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:25 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:25 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:25 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:27 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:27 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:24:27 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:25:12 2008] mail cgi: Reloading message at / DADA/Mail/MailOut pm line 1399 [Sun Nov 2 13:25:13 2008] mail cgi: Attempt to reload a message
which does not have a stalled process - check before attempting!
at /var/www/cgi-bin/dada/mail cgi line 1183

At 4:55 PM -0400 10/24/08, Justin J wrote: >

The screens all refer to "restarting", but the entries in the
errors txt file refer to "reloading" From your definitions,
I would say it is reloading because the emails do eventually
send sequentially

Ah That discrepancy is incredibly confusing I'll pop open a
bug and get that fixed up

It appears to send one email, then I get a message saying
"Mailing automatically restarting in 49 seconds " and that
counts down to 0 and then the next email is sent This keeps
repeating for each email Occasionally I get a completely
blank screen that just says "restarting mailing "

Hmm Unless you're using a Windows platform (and even then),
this shouldn't happen - it means either something is mucking up
with the fork()ing process or the sleep()ing process This
happens on really really cheap accounts Are you on a dedicated
server, or something more like shared host? If it's a shared
host, which one?

The other scenario when this happens is when you check the option:

 [ ] Restart Mailings After Each Batch

In the list control panel, under, Manage List -> Sending Options

Don't ever ever use this option, unless you really need to It
basically does exactly what you're experiencing, which is less
than what you really want

Sometimes after counting down to 0, the message doesn't send
and it needs to count down to 0 again This can cycle like
this quite a few times before the next email is actually sent

OK;

I am attaching a document with all the screenshots I see while
trying to send a 3-recipient list, and the errors txt log

If you're interested in doing some further debugging, I can give
you directions on how to REALLY get some interesting debugging
information For something like 3 subscribers, it may actually
be easy enough to slog through Interested?

-- Justin J \

On Oct 24, 2008, at 2:23 PM, Carl G Kuczun wrote:

Hi Justin,

The screens all refer to "restarting", but the entries in the
errors txt file refer to "reloading" From your definitions,
I would say it is reloading because the emails do eventually
send sequentially

It appears to send one email, then I get a message saying
"Mailing automatically restarting in 49 seconds " and that
counts down to 0 and then the next email is sent This keeps
repeating for each email Occasionally I get a completely
blank screen that just says "restarting mailing "

Sometimes after counting down to 0, the message doesn't send
and it needs to count down to 0 again This can cycle like
this quite a few times before the next email is actually sent

The emails are being sent and received

I am attaching a document with all the screenshots I see while
trying to send a 3-recipient list, and the errors txt log

Carl K

----- Original Message ----- From: "Justin J" To: "Dada Mail Developers Subscriber" ckuczun@PROTECTED Sent: Thursday, October 23, 2008 4:51 PM Subject: Re: List Restarting >

On Oct 23, 2008, at 2:34 PM, Carl G Kuczun wrote: >

I have been trying for the last week to figure out why my
lists keep restarting but have run out of ideas The
errors txt file contains the following lines:

What do you mean by, "restaring" - do you mean, restarting
from the absolute very beginning, or, restarting from where
it seems to have stopped? If it's the latter, user the word,
"reload" :)

If it is the former, perhaps you want to know why the mailout is actually stopping: usually it's just because you've hit some
sort of limit on how long a process can run on your hosting
account Are you having the problem where the mailing just seems to try
to restart, forever and never actually restarts

--

John Collins Meetings and Mixers PO Box 80461 Rancho Santa Margarita, CA 92688-0461 949-689-7070 info@meetingsandmixers com http://www meetingsandmixers com See our new Business Directories at: http://www meetingsandmixers com/directories/index php Post: mailto:dadadev@dadamailproject com

Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/u/dadadev/

List Information: http://dadamailproject com/cgi-bin/dada/mail cgi/list/dadadev

Archive: http://dadamailproject com/cgi-bin/dada/mail cgi/archive/dadadev

--

John Collins Meetings and Mixers PO Box 80461 Rancho Santa Margarita, CA 92688-0461 949-689-7070 info@meetingsandmixers com http://www meetingsandmixers com See our new Business Directories at: http://www meetingsandmixers com/directories/index php

--

Post: dadadev@PROTECTED

Unsubscribe: http://dadamailproject com/cgi-bin/dada/mail cgi/u/dadadev/

List Information:

Archive: