Default poll interval 1 second for execution_mode :external

[hms]

I'm currently configured with:
config.active_job.queue_adapter = :good_job
config.good_job.execution_mode = :external
config.good_job.queues = 'queue1:1;queue2:1;queue3:1;-queue4:2' # Yes, I know this needs a serious rethink

and relying on defaults for the rest of my behaviors.

What I'm seeing in the logs is a poll every second, rather than the expected default of 10 seconds.

When I add the configuration:
config.good_job.poll_interval = 30

I get the expected polling interval.

[bensheldon]

That's weird! Could you share what GoodJob.configuration.poll_interval is in your Rails console?

Here's how the poll interval is configured if that helps you maybe track down where this might be set:

good_job/lib/good_job/configuration.rb

Lines 142 to 160 in 7f9df97

	# The number of seconds between polls for jobs. GoodJob will execute jobs
	# on queues continuously until a queue is empty, at which point it will
	# poll (using this interval) for new queued jobs to execute.
	# @return [Integer]
	def poll_interval
	interval = (
	options[:poll_interval] ||
	rails_config[:poll_interval] ||
	env['GOOD_JOB_POLL_INTERVAL']
	)
	if interval
	interval.to_i
	elsif Rails.env.development? && execution_mode.in?([:async, :async_all, :async_server])
	DEFAULT_DEVELOPMENT_ASYNC_POLL_INTERVAL
	else
	DEFAULT_POLL_INTERVAL
	end
	end

[hms]

@bensheldon

I'm start to wonder if it wasn't a misunderstanding on my part. I assumed when the doc's suggested defaults, that I didn't have to set them in my initializer. Was that wrong? In the mean time, I've set all of the config values for now and once I get past this deadline, I'll look at things a little harder.

Thank you so much for a great product and the fast help.

hms

[bensheldon]

Your understanding is correct, you should not have to set a value and the default value (based on that code I shared) should be the value that's used.

I'm still at the debugging stage where I am imagining that your application is somewhere setting this value to 1 (maybe an initializer or environment variable you're overlooking) and that's why it's polling every second. I've not seen anything (yet!) that would imply that GoodJob is not using the configuration correctly.

[bensheldon]

Oh! Maybe you only saw the excerpt that GitHub generated for that code in these comments. If you click into it, there's more highlighted that shows the default constants.

[hms]

Ben, I’ll chase this again in the AMHalOn Jan 30, 2024, at 9:05 PM, bensheldon ***@***.***> wrote: Oh! Maybe you only saw the excerpt that GitHub generated for that code in this comment. If you click into it, there's more highlighted that shows the default constants. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[hms]

@bensheldon

I dug in more this morning with fresh eyes. I am unable to reproduce the issue. But just to confirm while I might be crazy, I'm not hallucinating, I did go back to double check my development.log and can see the 1 second query interval.

One thing I did change moving my good_job configuration from application.rb to initializers/good_job.rb.

Things seem to be working now, so it's looking like there is a code path that's triggering the behavior that I'm not hitting at the moment. I do know at the time, I was dealing with a failing job due to combination of an API based error and ActiveMailer Interceptors loosing it's mind. I'll dig into that a little as time permits.

Again, thank you for a fantastic product and the super responsive support.

[hms]

@bensheldon

I did some more digging (when rested) and I'm unable to recreate the problem. I'm leaning toward it was the result of a failing mail job because of a failing interceptor, and since that problem is behind me, it's hard to recreate a test case.

On the flip side, I did find one thing that was interesting (at least to me). As part of my reorganization, I moved the good_job configuration from config/application.rb to initializers/good_job.rb.

On thing that config variable that initially made the trip was:

active_job.queue_adapter = :good_job

• When active_job.queue_adapter = :good_job is in the initializer, I was getting "thread already in transaction" errors from AR.
• When that configuration option is in application.rb and all of the other config settings are in the initializer, things work just fine.

[bensheldon]

I'm glad to hear that it is working, though it's too bad you had such a mystery!

config.active_job.queue_adapter = :good_job

... should live in the config/application.rb (or config/environments/*.rb). This is a longtime ambiguity of Rails that some configuration is ok to be set in initializers, and some isn't. Example of that: rails/rails#34985

( "thread already in transaction" is a weird error though! I wonder if that's coming from the Rails AsyncAdapter being initialized.)