[Pulp-dev] Port Pulp3 to use RQ

[Brian Bouterse]

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>