Sunday, Aug 29, 10:20PM

[karzilla]

Bug counts: resolved 229, assigned 23, needs-review 19

Continuing on the subject of things that weren't as hard as I feared: making a gearman worker.

Here's your basic gearman worker in its entirety:

use LJ::Worker::Gearman;
gearman_decl( 'name-of-worker'  => \&worker );
gearman_work();
sub worker {
    # stuff what needs doing
}

And then you call it with something like LJ::gearman_client()->dispatch_background( 'name-of-worker', ...) (at least for my purposes, which were "go do this other time-consuming thing somewhere else and don't tell me what happens.")

The only real voodoo, AFAICT, is that you have to use Storable methods (freeze/thaw) for passing the function arguments from the web execution to the worker execution. I just did a copy and paste of code from someone else's worker script and it worked like a charm.

Later on I get to either write more gearman workers or overcome my fear of TheSchwartz, depending on whether or not gearman can do everything I need for delivering vgifts.

Comments

[alierak]

Also, it looks like the non-Gearman, non-Schwartz workers are: birthday-notify, directory-meta, expunge-users, paidstatus, search-updater, stats-collection, subscribe-hubbub, and t-memlimit. Most of those inherit from LJ::Worker::Manual, but a couple are just doing their own thing. I think these types may be suited for background tasks that are either periodic or asynchronously queued and don't need many bells and whistles.

[kareila]

I think the main advantage of using Gearman for this particular task is that it won't attempt multiple simultaneous executions of the worker with the same arguments, thanks to the uniqueness component. I wouldn't want to use a manual worker for anything triggered by viewing content.

A manual worker might be the thing for delivering queued vgifts, though. That's very similar to what birthday-notify and paidstatus are doing, I imagine.