XF 2.3 Cron vs job entry in db

[Taylor J]

What would be the preferred way to handle what could be a huge amount of jobs being created for scale wise?

For my use case a cron would be the simplest way to get this done but it would then have the down side of the task/function that needs to run not running at the exact time that is set for the moderator feature to end, but a job would allow that to happen.

The major downside I can think of running the task/function off of a job is that on busy forums where this feature could be used a lot it could end up with a good amount of rows in the xf_job table.

I want to go the job route but please do tell if that isn't the proper way to handle this.

 

[Sim]

Can the task be broken into smaller restartable chunks? Jobs are ideal for that.

Can you give some more details about the nature of the task being performed?

Is each task unique and independent? (eg sending an email or notification to one person), or is it performing the same process on a large amount of data (eg processing many rows in the database) ?

If you look at many of the core Cron tasks, they actually just start a job themselves - the logic is all in the job (or in a service used by the job), and the cron is merely the trigger that creates the job.

 

[Taylor J]

At a set time, which will be the only differing factor each time, the job will perform the same function of just changing a field on a users xf_user row to a 0.

A moderator will be able to set a certain time span from any amount of days and/or hours specified by the addons options which is when the task will need to be set off. Wouldn't need to be restart able I don't believe but there could/will be instances where a job entry if going down that route will happen at the same time as others. Example: Moderator1 sets a time span of 3 days 1 hour. Exactly 3 days later Moderator2 sets a time span of 1 hour, so now those two jobs would be fired at the same time.

 

[Sim]

Jobs are not really intended to be used for delayed execution. I've not thought through all of the implications of implementing such a system.

I suggest a different approach - have another table that specifies a user_id to be updated and a timestamp for when this should be executed.

Then you set up a cron (executing once per hour is probably enough?) which checks whether there is any data in the table where the timestamp is lower than the current XF time and if so, creates a job - the job is set to loop through each row and change the field and then delete the entry in the trigger table. The job can be restartable as per most XF core jobs (look at how they are implemented for ideas on how to implement yours) - so that if there end up being a large number of rows to be updated, the job can restart as required.

 

[Taylor J]

Jobs are not really intended to be used for delayed execution. I've not thought through all of the implications of implementing such a system.

I suggest a different approach - have another table that specifies a user_id to be updated and a timestamp for when this should be executed.

Then you set up a cron (executing once per hour is probably enough?) which checks whether there is any data in the table where the timestamp is lower than the current XF time and if so, creates a job - the job is set to loop through each row and change the field and then delete the entry in the trigger table. The job can be restartable as per most XF core jobs (look at how they are implemented for ideas on how to implement yours) - so that if there end up being a large number of rows to be updated, the job can restart as required.

I've been attempting to work on a solution based on what you described above but had some more questions as I ran into a blocker in my head.

The table that the job would be looping through would be the xf_user, would looping through every single row be smart for big boards that could have to update any number of users at a time (if multiple users were set to have a field on their db record changed at the same time, but all in random spots in the xf_user table)?

I should have provided this in my last post but was a bit sleepy and rushing the post but to go into deeper context the feature will allow moderators or whomever has the permissions to place another user on a posting probation which would then set a field on them to true.

Also you saying that jobs aren't really intended for delayed executions made me question this approach all together as that's the way I went about it with my Blogs addon for scheduled posts lol.

Actually while typing out the above I thought of having the cron just call the job but call it with every user_id that would need to be updated. I just still haven't figured out how jobs actually restart from where they left off yet as it hasn't rattled in my brain properly yet while reading through a few (Cron, UserGroupPromotions, AbstractJob). Mainly just because I don't understand where previousAttempts gets it's data from.