Subscription functionality

I have two questions related to the subscription functionality: 1. What is the exact meaning with the Interval-values. If the user has chosen "daily", would that imply that the subscription mail is generated in the scheduler's first run of the next day. Or is it run immediately after a change has occured as well as first thing on the next day. 2. Is there any limit on the number of subscribers that can be sent to in one single subscription task? Theoretically - and hence in also in reality - it might happen that a lot of user subcribe to the same page and having the same interval. I'm not using the term job here, because one solution would be to distribute the task over several jobs. 3. When changing the subscriber's interval e.g. from daily to immediately, I have experienced a delay in effect. Is that also run as a background work by the scheduler? Regards Christian Wallgren
Oct 08, 2004 9:46
1. Every time a user gets a subscription mail we store the current exact date in the personalization store, next time we find a subscription to be delivered to the same user we check that ( + ) < before we mail it. 2. Normally users have different intervals, subscriptions and different (see previous discussion in answer 1) so the load is distributed over time. If you set the subscription job to run every other day you would ofcourse queue up more mails than if you were to schedule it every hour as default. Sending hundreds of mails per job is usally no problem. 3. "Immediately" is "as soon as possible" which meens the next time the subscription job runs, hence the delay.
Oct 08, 2004 10:32
Thank you, but I'm still confused, maybe on a higher level... I will put the question in more real terms: The customer wants a newsletter service. There are many features in the subscription package that appeal: The possiblity to set subscription on or off and the self registration, which comes very handy. The difference, though, being that a newsletter is expected to be distributed at a certain time, regardless to any choice of subscription. Given that the users may sacrifice the freedom of selecting subsciption interval, this solution works well, with the only drawback being the risk of a mass rush of mail. In your answer on 1. you say that delivery time is related to + . But what is lastmail set to in case of the first mail? My guess is that you use entrance time as a substitute. If we look at question 2. the spreading of intervals among the users will not help in our case, since the frequency of the actual change of document(once a week) is typically longer than the interval(daily). What would be more interesting in our case (and even generally I think) is the time, when the user actually entered the subscription. Wouldn't it be better to enter a second condition in pseudo: > ? That would make distribute mail load over time in an efficient and independent way, especially if jobs are frequently run. For test purposes the 0-interval should be kept as it is today, without considering time of subscription entrance. Do you have any suggestion to how to solve the newsletter problem and is the proposed solution viable and something which could be considered? Regards Christian
Oct 10, 2004 17:38
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.