[Pulp-dev] Port Pulp3 to use RQ

Brian Bouterse bbouters at redhat.com
Thu Mar 22 17:58:12 UTC 2018

Thanks for all the discussion both on list and on irc. After more
investigation, it sounds like there are no feature gaps, but we will need
to incorporate this workaround
<https://github.com/rq/rq/issues/684#issuecomment-352152369> to cancel a
task that is already running.

The feedback I've heard on the idea is that it's valuable and looks
feasible, but we won't really know until we prototype it a bit. Based on
the technical outline in the previous email, I believe it can be prototyped
in a day or two. I plan to do this soon, once I contribute to a few other
required-for-beta planning items first. I'll post my PR to see what other
think of the change, probably next week.

On Wed, Mar 21, 2018 at 6:41 PM, Daniel Alley <dalley at redhat.com> wrote:

> I meant in the sense that, what is the aftermath when it comes back
> online, and is it screwed up in ways that cause side effects.
> On Wed, Mar 21, 2018 at 5:02 PM, Jeremy Audet <jaudet at redhat.com> wrote:
>> > RQ does not support revoking tasks.  If you send the worker a SIGINT,
>> it will finish the task and then stop processing new ones.  If you send the
>> worker SIGKILL, it will stop immediately, but I don't think it gracefully
>> handles this circumstance.
>> Nothing handles SIGKILL gracefully. Processes can't catch that signal.
>> `kill -9 $pid` sends SIGKILL.
>> If one is looking for a way to gracefully, immediately kill an RQ
>> worker, then SIGTERM may do the trick. Anecdotally, many processes
>> handle this signal in a hurried fashion. Semantically, this is
>> appropriate: SIGINT is the "terminal interrupt" signal (Ctrl+c sends
>> SIGINT), whereas SIGTERM is the "termination signal."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180322/4d25bf23/attachment.htm>

More information about the Pulp-dev mailing list