Manual queue processing times out

I was trying to send an email campaign last night. I have recently upgraded to 3.3.1 and haven’t had time yet to reconfigure the cron processes to handle thing automatically. So I was using the built in ‘Process Queue’ functions through the PHPList web pages on our system. I have tried using these things before and it has always kind of confounded me.

So I turned off my screen saver, turned off the computer power saving and sleep modes (set both to ‘never’), started up the PHPList Process Queue process and the processing page showed up, feedback appeared, and it started spinning. Great - so far so good. Some emails showed up for people on the list.

This list is somewhat large - about 1000 people. Our email service only allows about 150/hr to be sent, so I have set the Throttle configuration in PHPList accordingly. But how do I get the web page to actually finish processing things? I had left the web page front and center and was the ‘in focus’ window on my screen. Then I went to bed. It appears that the web page itself timed out - when I checked back in in the morning it still showed the feedback from the first run of processing and when I clicked on something the system made me log in again.


This occasionally happens to me partway through processing, did you try processing again? If there is a glitch and it doesn’t connect after the delay it just fails and does not retry.
It should continue if your session does not time out so make sure you throttle settings have not left too long, little and often is best. When you set off a process queue, wait for it to progress to the next batch and then you know its working
I submitted an alternative delay method on github that might help or might not.

In my attempts to re-run this campaign the other morning, I left the web page 'Queue processing active for over an hour…it never updated. So when I refreshed the screen using the browser functions, it had timed out again and I had to re-log in. As soon as I did the processing refreshed and it showed new numbers for the current state of things.

But it doesn’t seem to be processing automatically - certainly doesn’t seem to work without my intervention.

Once I get the configuration all done I’ll be using the cron to start/execute the processing, so this shouldn’t be an issue. But it has always kind of stuck in my mind as an issue for those times when I need to manually move things along because something else seems to have broken.

What is your configuration to throttle down to 150/hour?

You might want to consider a cron job for your sending. It’s basically a command run on the commandline (not the web interface), and is run periodically by the cron deamon on your server. I typically set the period to every 5 minutes. The result is that every 5 minutes, the system looks for any messages in the queue, and sends the proper quantity so that it is sending at the batch and throttle does not get exceeded.

Configuration for throttling is:
define(‘MAILQUEUE_BATCH_SIZE’, 145);

@Dan: I have since gone back and set up the cron job, yes - that is my typical configuration. This time just happened to be before I got everything all configured and running smoothly, so I had to run it manually.

this leaves half an hour between batches, session timeout is often 20/24 minutes thats why it fails.
try doing less per batch, try batch size 2 with a batch period of 60. thats 120/hr but actual will be less. you can then change to period of 45 or so to get close to 150/hr.

Ah, OK - thanks for the tips. I’ll give some smaller/more-frequent batch sizes a shot.

Sculptex, thank you, thank you, thank you.
I originally had batches of 100 over 3600 seconds (1 hour) but the “send the queue” page simply timed out, so that the only way to continue sending was manually to refresh it, usually requiring a login.
Changing to batch size 2 and batch period 60 kept the page alive until the queue was finished. I got a queue processing report email after each batch, so I got a lot of emails, but it is possible to stop these as explained in the link in the email.