On Nov 6, 2008, at 12:14 PM, Carl G Kuczun wrote:

>

The change I made to my dada config $DIR value seems to have
resolved my problem I always thought it was an environment issue and not
something to do with DadaMail Looks like I was right

Oh good - I was going to report that the changes I had made seem to
make a positive effect, but I couldn't recreate the exact problem you
had, "The, "Resource Temporarily Unavailable" problem

The new snapshot on Bluehost seems to work well - just do make that
tweak I outlined I have to say, that the 3 0 0 stable version I was
using as a control seemed to work just as well Hmm :) You were much
less likely to get into that weird, "Reloading Message " loop,
though, which was nice

One thing I did notice was that SMTP sending on Bluehost worked much
much better - just use "mail youhost com" as the SMTP server and fill
out the SASL Authentication with a username/password of a email
account you have on the Bluehost account - preferably either your list
owner or list admin email address I'm kinda hankering for that, "skip
a batch if we're behind schedule" feature though It's painful to wait
Dada Mail sleep when you know it's got time to make to be on schedule
with a mailing I'm kind of working on the algorithm on that and those
types of things aren't my fort� :)

One thing to note - be sure to replace the, "+" in your username with,
"@", or perhaps, "%", there's a bug in Dada Mail that any, "+" sign in
the SMTP option screen (basically) turns into a space Sigh

https://sourceforge
net/tracker2/?func=detail&aid=2228305&group_id=13002&atid=113002

Getting back to that, "resource temporarily unavailable" problem, the
only way I could make it happen was with a test script that tried to
open the semaphore file twice - which is good! Because that's exactly
what was supposed to happen Here's an example of it working (by
throwing back and error)

[snip]

!/usr/bin/perl -w

use strict;

use lib qw( / /DADA/perllib); use CGI qw(:standard); use CGI::Carp qw(fatalsToBrowser);

$|++;

print header();

print '

';


use DADA::Mail::MailOut;

my $mailout = DADA::Mail::MailOut->new({ -list => 'j '});

open my $fh, ">", $DADA::Config::TMP 
 '/bang
tmp' or die $!;
my $lock  = $mailout->lock_file($DADA::Config::TMP 
 '/bang
tmp');
my $lock2 = $mailout->lock_file($DADA::Config::TMP 
 '/bang
tmp');

[/snip]

Running this will give you an error,

Couldn't lock semaphore file for, /home/myaccount/
dada_files/
tmp/ 


bang
tmp - exiting with error to avoid file corruption!
    Resource temporarily unavailable at /DADA/Mail/MailOut
pm line 1783

Which is exactly what you want


I'm a little scoobied as to why this was happening to you - my guess 

is that two copies of Dada Mail perhaps were running at the same time, 

given the paths you had set in the configuration? Maybe? Dunno - but 

if the config tweak worked, well, I'll close the books on that one


>


  
Justin, you have been so good to spend so much time on a non- 
  DadaMail issue

  I appreciate your dedication to helping me get this working, even 

  though it
  had nothing to do with you
  At least you got several other issues 

  knocked
  down so it wasn't a total waste



Not a problem - I know Bluehost has Dada MAil as a one-click install 

option, so it is nice to know how well it's working on their systems, 

since a lot of people will be using it, without necessarily knowing 

what they're doing ;) Bluehost was nice enough to give me some test 

accounts, which is good! Because I have a limited amount of testing 

accounts to work with


Just to let everyone know, I've also asked WestHost for a test account 

- I don't have one yet, but I'm jumping through the various 

departments to talk to the right Guy, who may be able to help,


  
All it does is change the $i to $$, right?


That's all it does,

As a geek background, the, "$$" is a magic variable, that holds your 

process id - this way, if you're running as the same process you'll 

also use the same, recycling dbi handle - this means that you only 

make ONE connection to the SQL server
 This is good
 the, 

"connect_cached" method also does auto-reconnections, which is pretty 

useful


The process id will change when you send a mass mailing out, since you 

fork() off a child
 Since the process id will change, the dbi handle 

you've been using won't be recycled and you'll get a new dbi handle
 

There's a problem with attempting to share dbi handles between parent 

and child


 Anyways :)