phpList sends 2 mails then stops

ℹ️ Support
1

Hello guys, after a migration to a new hosting I have this problem. Any help would be appreciate…
I start the queue and I can see in my log that 1 mail is sent, then it awaits the right throttling time, then send the second mail and awaits. But then, nothing more happens, the wheel keeps rolling, nothing in the log…
I have to stop and resume the processing manually :frowning:

Here my config and a log:

These are my settings for my host (100 / h)
define(“MAILQUEUE_BATCH_SIZE”,100);
define(“MAILQUEUE_BATCH_PERIOD”,3600);
define(‘MAILQUEUE_THROTTLE’,0);
define(‘MAILQUEUE_AUTOTHROTTLE’,1);
define(‘USE_DOMAIN_THROTTLE’,1);
define(‘DOMAIN_BATCH_SIZE’,1);
define(‘DOMAIN_BATCH_PERIOD’,60);

log:
Ereigniss Datum Nachrichtentext
3245729 21 März 2019 11:48:10 waiting for 42.7 seconds to meet target of 36 seconds per message

3245728 21 März 2019 11:48:10 It took 0.3488140000 seconds to send

3245727 21 März 2019 11:48:10 Sending 232 to annamontersino@fastwebnet.it

3245726 21 März 2019 11:47:41 waiting for 35.6 seconds to meet target of 36 seconds per message

3245725 21 März 2019 11:47:41 It took 0.3537110000 seconds to send

3245724 21 März 2019 11:47:41 Sending 232 to andreacaniato@gmail.com

3245723 21 März 2019 11:47:41 Found them: 195 to process

3245722 21 März 2019 11:47:41 User select query select distinct u.id from phplist_listuser as listuser inner join phplist_user_user as u ON u.id = listuser.userid inner join phplist_listmessage as listmessage ON listuser.listid = listmessage.listid left join phplist_usermessage as um ON (um.messageid = 232 and um.userid = listuser.userid) where listmessage.messageid = 232 and listmessage.listid = listuser.listid and u.id = listuser.userid and um.userid IS NULL and u.confirmed and !u.blacklisted and !u.disabled

3245721 21 März 2019 11:47:41 Looking for subscribers

3245720 21 März 2019 11:47:41 Processing campaign 232

I have phpList 3.4.0

Thanks a lot!

2

I did some tests, changed my configuration to send 1 message per 36 seconds batch (which is 100 per hour) and found out, the problem is, phpList does not recall itself.
These are the log entry since me starting processing the queue, after the last entry nothing more happens:

3246046 22 März 2019 00:05:25 Waiting for 30 seconds before reloading
3246045 22 März 2019 00:05:25 Finished this run
3246044 22 März 2019 00:05:25 1 messages sent in 20.61 seconds (174 msgs/hr)
3246043 22 März 2019 00:05:25 batch limit reached: 1 (1)
3246042 22 März 2019 00:05:05 waiting for 35.6 seconds to meet target of 36 seconds per message
3246041 22 März 2019 00:05:05 It took 0.3578960000 seconds to send
3246040 22 März 2019 00:05:05 Sending 232 to xxxxxxx@gmail.com
3246039 22 März 2019 00:05:05 Found them: 159 to process
3246038 22 März 2019 00:05:05 User select query select distinct u.id from phplist_listuser as listuser inner join phplist_user_user as u ON u.id = listuser.userid inner join phplist_listmessage as listmessage ON listuser.listid = listmessage.listid left join phplist_usermessage as um ON (um.messageid = 232 and um.userid = listuser.userid) where listmessage.messageid = 232 and listmessage.listid = listuser.listid and u.id = listuser.userid and um.userid IS NULL and u.confirmed and !u.blacklisted and !u.disabled
3246037 22 März 2019 00:05:05 Looking for subscribers
3246036 22 März 2019 00:05:05 Processing campaign 232
3246035 22 März 2019 00:05:05 sending of this campaign will stop, if it is still going in 6 days 23 hours 59 minutes 10 seconds
3246034 22 März 2019 00:05:05 Please leave this window open. phpList will process your queue until all messages have been sent. This may take a while
3246033 22 März 2019 00:05:05 One campaign to process.
3246032 22 März 2019 00:05:05 Processing has started,
3246031 22 März 2019 00:05:05 select id from phplist_message where status not in (“draft”, “sent”, “prepared”, “suspended”) and embargo
3246030 22 März 2019 00:05:05 Maximum time for queue processing: 60

I ALSO FOUND OUT, if I stop processing and restart right after the second mail is sent, nothing happens, I have to wait at least 5 minutes since the second mail was sent.

Any ideas?

I made more tests, set a higher numbers of emails per period. I discovered, it is not about 2 emails, it is about time: phpList just works for 1 minute and then stopps.

Does this have to do with the first line in the log starting processing the queue?

3246621 22 March 2019 10:09:27 Maximum time for queue processing: 60
Page: pageaction

Can someone please help?

3

Sounds like you need to change the batch settings. Some links that may help:

4

Thanks for answering. I red everything about that, but maybe I didn’t understand it right, then accordingly to my provider regulations (max 100 Emails per hour) I wrote in config:
define(“MAILQUEUE_BATCH_SIZE”,100);
define(“MAILQUEUE_BATCH_PERIOD”,3600);
define(‘MAILQUEUE_THROTTLE’,0);
define(‘MAILQUEUE_AUTOTHROTTLE’,1);

Is this wrong?

5

That is correct. When run through the browser the queue processing is limited to 60s. You should use a cron job to process the queue, as that does not have the restriction.

1 Like
6

In my old provider I didn’t have this problem, I always clicked on “Process queue” and let the browser window open until it was finished, sometimes for hours, sometime all day.

I am not on a dedicated server, my provider does not allow to run cron jobs…

Is there another solution?

7

@accorinti You can try changing the batch/throttle configuration to reflect that limit of 60s on the elapsed time. Maybe a batch size of 1 and a batch period of 60 might work better.

The alternative to a cron job is to use remote processing https://resources.phplist.com/system/remote_processing . There is a service provided by phplist.com but in the past that seems to have been unreliable in whether it is actually running. There are also third-party cron providers such as https://cron-job.org/en/

8

The phpList.com remote queue processing service has been running reliably for years. It went down recently for a couple of weeks, but was brought back up and has been working normally again since.

9

OK thank you, I will try that.