One thing to note here, it’s relevant I think. Try to avoid doing stuff like calling out to external services (local or otherwise) during database transactions. It seems obvious (you’re going to deal with record not found errors, or deadlocks), but in a complex system it’s possible to do this without realising.
In our case it turned out we were re-sizing images during a transaction. These were background jobs so not as much of an issue as if this was happening on the front-end, but the transactions were holding onto rows for long enough that other requests were deadlocking when we put more user load on the system. Will. > On 30 Oct 2015, at 15:48, Francis Fish <[email protected]> wrote: > > My fun discovery of the week is that Sidekiq is too fast. > > I was using after_save to send something to a rules engine for extra > processing after creating it, kept seeing a message saying the record doesn't > exist, but it would work on the retry (after I had stopped catching the > exception - not good practice rilly). > > After several hours of wtf and trying to get delay() to stop biting Mike Hart > found the sidekiq troubleshooting article where it ways use after commit. > > Then all was perfik again. -- You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/d/optout.
