View Issue Details

IDProjectCategoryView StatusLast Update
0014115phpList 3 pluginsGeneralpublic06-02-19 11:35
Reporterflohack Assigned To 
Status newResolutionopen 
Summary0014115: rsslib.php: user send check compares interval too strict
DescriptionWhen sending to users, user_rss is checked for send permission to a specific user. The comparison which is done relies on INTERVAL xy.... however, the date field in user_rss gets updated with the actual send timestamp of the corresponding mail. Now, as time goes by, users at the end of a batch will have noticeable later timestamp (seconds to minutes).
The next send check may or may not eliminate these users since it is "toot early" for them to send. The timestamp in user_rss should therefore be the actual start time and date of the send process, rather than when the email left the server. Therefore, all users will be treated equal.
Additionally the INTERVAL comparison in rsslib.php should get some extra seconds to be on the safe side. glitching clocks and other long term run problems could get eliminated this way.
TagsNo tags attached.


related to 0014762 new RSS-Messages get wrong embargo time 



27-09-10 09:42

reporter   ~0051098


Oh yes !!!

Changing to batch start time would be a far better implementation.

I have 4000 user list that gets emailed monthly for an ecommerce site. The ecommerce site is on shared hosting and 4000 users all responding to the mail-out within a few hours of each other would absolutely crash the hosting account for abuse. Therefore they are trickled out 30 seconds apart - takes about 2 days to send to them all. (Helps with large mail host flood avoidance too - e.g. Hotmail or AOL)

Following month, there is a 2-day variance in last send date and only about 10% of the users get the next email - ecommerce results take a hit, and the site loses money and return visitors = not good.

Logic dictates the "last mail date" absolutely should be the point of batch start. That could even allow me to batch throttle so the entire 4000 list is throttled to distribute receipt over say a 28-day spread, leading to a constant daily trickle of returning customers - would exceptionally please the client if that happened.


Issue History

Date Modified Username Field Change
15-04-08 10:15 flohack New Issue
02-06-10 00:56 h2b2 Target Version => 2.11.4
02-06-10 01:00 h2b2 Relationship added related to 0014762
27-09-10 09:42 gazouteast Note Added: 0051098
23-05-12 14:51 michiel Project phpList 3 application => rssmanager
23-05-12 14:51 michiel Category RSS => General
06-02-19 11:35 erion Project rssmanager => phpList 3 plugins