2015-02-09 13 views
9

C'è un modo per disabilitare i tentativi automatici con ActiveJob e Sidekiq?Disabilita il tentativo automatico con ActiveJob, utilizzato con Sidekiq

So che con Sidekiq solo, non ci resta che mettere

sidekiq_options :retry => false 

come accennato qui: https://github.com/mperham/sidekiq/wiki/Error-Handling#configuration

ma non sembra di lavorare con ActiveJob e Sidekiq.

so anche la soluzione per entierly disattivare la tentativi come proposto qui: https://stackoverflow.com/a/28216822/2431728

ma non è il comportamento di cui ho bisogno.

risposta

12

Ok, grazie per la risposta.

Solo per informazioni, ho anche chiesto la questione in un problema ActiveJob Github relative a questo argomento: https://github.com/rails/activejob/issues/47

DHH me rispondere a una soluzione che non ho testato, ma che può fare il lavoro.

Personalmente, ho finalmente mettere questo in un inizializzatore per disabilitare Sidekiq riprova globalmente un funziona bene:

Sidekiq.configure_server do |config| 
    config.server_middleware do |chain| 
     chain.add Sidekiq::Middleware::Server::RetryJobs, :max_retries => 0 
    end 
end 
+4

in realtà, puoi rimuovere il middleware 'RetryJobs' come mostrato [qui] (https://github.com/mperham/sidekiq/wiki/ Middleware # middleware predefinito) – gerry3

+2

Sidekiq ha un modo incorporato per disattivare i tentativi globalmente: 'Sidekiq.default_worker_options = {retry: 0}' – Ari

+1

@Ari Non credo che funzioni per ActiveJob anche se ... solo per i lavoratori nativi di Sidekiq senza AJ – courtsimas

3

Non c'è modo di configurare nulla su Sidekiq con ActiveJob. Utilizzare un lavoratore Sidekiq se non si desidera utilizzare i valori predefiniti.

+1

Anche se usiamo un inizializzatore e le impostazioni sono le seguenti? Sidekiq.default_worker_options = {'backtrace' => 5, 'retry' => 3} –

1

Ho avuto questo stesso bisogno, cioè ActiveJob avvolgendo Sidekiq ma volendo sostenere max_retries. Inserisco questo in un inizializzatore. Se #max_retries viene definito su un lavoro ActiveJob, verrà utilizzato per impostare i tentativi. Se #ephemeral? è definito e restituisce true, il lavoro non verrà rieseguito e non verrà trasferito a "morto" se fallisce.

class Foobar::SidekiqClientMiddleware 
    def call(worker_class, msg, queue, redis_pool) 
    aj_job = ActiveJob::Base.deserialize(msg['args'][0]) rescue nil 
    msg['retry'] = aj_job.respond_to?(:max_retries) ? aj_job.max_retries : 5 
    msg['retry'] = false if aj_job.respond_to?(:ephemeral?) && aj_job.ephemeral? 
    yield 
    end 
end 

Sidekiq.configure_client do |config| 
    config.redis = { url: "redis://#{redis_host}:6379/12" } 
    config.client_middleware do |chain| 
    chain.add Foobar::SidekiqClientMiddleware 
    end 
end 

Sidekiq.configure_server do |config| 
    config.redis = { url: "redis://#{redis_host}:6379/12" } 
    config.client_middleware do |chain| 
    chain.add Foobar::SidekiqClientMiddleware 
    end 
end 

Nota: in realtà è importante aggiungere questo alla catena middleware per client e server se uno dei tuoi lavori creano nuovi posti di lavoro stessi mentre vengono eseguiti.

2

È possibile raggiungere l'eccezione e non fare nulla, invece riprovare o per configurare tentativi:

class ExampleJob < ActiveJob::Base 
    rescue_from(StandardError) do |exception| 
     Rails.logger.error "[#{self.class.name}] Hey, something was wrong with you job #{exception.to_s}"  
    end 

    def perform 
     raise StandardError, "error_message" 
    end 
    end 

    class ExampleJob < ActiveJob::Base 
    rescue_from(StandardError) do |exception| 
     retry_job wait: 5.minutes, queue: :low_priority  
    end 

    def perform 
     raise StandardError, "error_message" 
    end 
    end 

Per l'esecuzione di un nuovo tentativo è possibile utilizzare retry_on metodo retry_on method doc

Sidekiq wiki for retries with Active Job integration

Problemi correlati