Listmonk sleeping forever

[rafalsk]

Version:

• listmonk: 2.2.0
• OS: Linux, official docker container

Description of the bug and steps to reproduce:
I noticed this for the first time when upgrading the docker container to version -1 as of current.

In short, the campaign it would start processing the first bunch of messages, then hit a limit (set) and then.. it would sleep indefinitely.. processing would never resume... nothing in logs.

Upgraded to the latest release in hopes for this being resolved, no luck.

The only thing that helps is to kill the container and start it again (and then... some recipients would never be delivered as assumably Listmonk would have assumed that all the ones that had been pre-fetched from the DB,- the last time the container started - had been delivered. Which is NOT the case, as these recipients had been pre-fetrched indeed but only the part was delivered before the throttling limit was hit, the other part was not, and not would never be delivered as listmonk would increment the index from which it fetches recipients by the size of the entire window. That should probably be yet another bug report.

all that can be seen in logs is:
2022/09/29 11:52:38start processing campaign (New research paper) 2022/09/29 11:53:14messages exceeded (30) for the window (1h0m0s since 29 Sep 22 11:52 +0000). Sleeping for 59m19s.

[knadh]

hm, will investigate this. Have you explicitly set 30 messages per hour in Settings -> Performance -> Sliding window settings?

[rafalsk]

folks, tell you what, I got the issue resolved BUT, we are after mitigating the issue as such right, so let me tell you what I know.

1. the issue appeared to surface after upgrading to version current-1.
2. I did not changes to any of the configuration files. Even still, some of the settings appeared messed up. From what I recall it held for the username to the smtp server in particular. Before, I had a sliding window set to 30 messages per hour, I did not a single change to that setting, again. It appeared fine I had it set to deliver 30 messages per hour and to fetch 100 entries from the database at a time.

now, how I resolved the issue:
I simply set for it to send 30 messages per hour (tops) AND to pre-fetch only 30 messages from the DB at a time (so to possibly eliminate bug #2).

Now everything works, don't ask me why.

Yet again, the 'bug' was immune to restarts of the container and to pausing/resumption of campaigns.

[knadh]

Thanks for the update. The configuration file only has DB settings and the site URL though, nothing to do with SMTP settings. This behaviour is strange though. The last upgrade made no changes to settings, hm. I'll close this issue for now as this isn't reproducible.