Document config AJ details + LRJ/VP + combo

[mensfeld]

ref https://github.com/karafka/karafka/issues/798

[whithajess]

Just to add to this - I think It would be great to document a similar feature list to those adapters directly in ActiveJob Queue Adapters.

|                   | Async | Queues | Delayed    | Priorities | Timeout | Retries |
|-------------------|-------|--------|------------|------------|---------|---------|
| Backburner        | Yes   | Yes    | Yes        | Yes        | Job     | Global  |
| Delayed Job       | Yes   | Yes    | Yes        | Job        | Global  | Global  |
| Que               | Yes   | Yes    | Yes        | Job        | No      | Job     |
| queue_classic     | Yes   | Yes    | Yes*       | No         | No      | No      |
| Resque            | Yes   | Yes    | Yes (Gem)  | Queue      | Global  | Yes     |
| Sidekiq           | Yes   | Yes    | Yes        | Queue      | No      | Job     |
| Sneakers          | Yes   | Yes    | No         | Queue      | Queue   | No      |
| Sucker Punch      | Yes   | Yes    | Yes        | No         | No      | No      |
| Active Job Async  | Yes   | Yes    | Yes        | No         | No      | No      |
| Active Job Inline | No    | Yes    | N/A        | N/A        | N/A     | N/A     |

My understanding from what I have read so far is it would look like this:		Async	Queues	Delayed	Priorities	Timeout	Retries
Karafka	Yes	Yes	No	No	Global	No

Looking at this:

• Async
  • Via threads (Individual Jobs are Sync)
• Timeouts
  • My understanding is the timeout for the Job (not the Kafka consumer) would be defined by how long max.poll.interval.ms is set for Kafka as if the job hits this the consumer would be considered dead by Kafka - this could cause issues as the Job is not necessarily going to stop and another member of the consumer group could pick it up (Im doing some testing around this now)

[mensfeld]

@whithajess in Rails itself I cannot as they no longer accept PRs for new adapters.

Also, don't you think we have retries? ;) Upon crash Karafka will retry the job based on the retry policies

[whithajess]

@whithajess in Rails itself I cannot as they no longer accept PRs for new adapters.

Also, don't you think we have retries? ;) Upon crash Karafka will retry the job based on the retry policies

No just in the ActiveJob documentation you are writing.

I didn't think it was configurable other than the back off?

Job: The number of retries can be set per instance of the job class.

Yes: The Number of retries can be configured globally, for each instance or on the queue. This adapter may also present failed instances of the job class that can be restarted.

Global: The adapter has a global number of retries.

No: The adapter does not allow the number of retries to be configured. N/A: The adapter does not run in a separate process, and therefore doesn't support retries.

[mensfeld]

Ah ok. I thought you meant a general retries policy. The AJ jobs yes, no retries of theirs on that one.

[mensfeld]

Note for myself: document AJ with LRJ + VP

[mensfeld]

AJ and VP are documented.