Closed tedt10e closed 2 years ago
I just spent time reading through the README and realized those are all mentioned in README. π
I've just set ActionMailer::MailDeliveryJob.retry_on StandardError, wait: :exponentially_longer, attempts: Float::INFINITY
in initializer/good_job.rb and it attempting nicely as below.
25-Jan-2022 09:38:13.545 25-Jan-2022 09:38:16.686 25-Jan-2022 09:38:34.792 25-Jan-2022 09:39:57.880 25-Jan-2022 09:44:15.991 25-Jan-2022 09:54:43.094 25-Jan-2022 10:16:21.095
I guess this default behavior (to retry continuously) does not come from GJ. (Is it the default behavior of ActiveJob/MaileDeliveryJob?)
Is it something GoodJob can set as a default behavior to set wait: :exponentially_longer?
Or probably it is better to mention somewhere near the top of the README to be aware of this default behavior.
For many of us, we usually use the default settings.
I'm afraid someone else might face the same issue for their production server if they are unaware of this default behavior.
Thanks β€οΈ
That stinks that your disk filled up. I can try to explain the current state of affairs, which is a somewhat cascading problem.
My goal for GoodJob 3.0 is to change the defaults
cleanup_interval
so that GoodJob will delete old jobs (and thus resolve my worry about filling up the database)
So the way I'm imagining your scenario to play out in the GoodJob 3.0 world is:
GoodJob::Execution
table in the database, and see that it had errored and not completed successfully.Hey Ben,
Thank you so muchπ for your time and the explanation.
Setting the default in GJ3 sounds excellent.
In the meantime, it's time for me to upgrade GJ from 1.9.6 to the latest version π
Hello Ben,
I recently had an issue with the production server as there is no more storage space due to the log generated by the failed jobs.
It happened when there is an issue connecting to the mail server but it keeps trying to send mail continuously (in milliseconds) and generates error logs.
I've included the sample from the logs below., but only copy the first 3 and remove the stack trace from the first 2 for readability.
As you can see from the below, it first attempts at 25-Jan-2022 04:49:51.640 then 25-Jan-2022 04:49:51.781 then 25-Jan-2022 04:49:51.943 and so on ... which immediately filled up the whole storage of the server.
I'm still using GJ 1.9.6 (I'm a bit late behind to upgrade π) with JRuby 9.2.19, Rails 6.1.4, Tomcat 9, Postgres 13.
I'm not sure it is something that we need to configure for GJ not to repeatedly attempt to deliver the job. At this moment, I do not set any setting for GJ except config.good_job = { execution_mode: :async, max_threads: 5, poll_interval: 30 } in production.rb
Can you please help me advise what is the best way to handle this behavior? π