-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenExchangeRate being hit 2x as often as retrieve_every
configuration.
#152
Comments
@dbernheisel thanks again for a fabulously detailed report. I will dig into this later today. Clearly not acceptable to be consuming at twice the expected rate. |
I changed schedule_work(0)
schedule_work(config.retrieve_every) to be simply: schedule_work(0) And then let it run for a few iterations and I believe there is now only a single event loop. Would you consider trying this by configuring Of course please re-open if the issue isn't fixed as you see it. |
Yep. I'll report back on Monday |
Confirmed fixed. Thanks so much. |
I've published ex_money version 5.15.1 with the following changelog entry: Bug Fixes
Thanks again for the report! |
The ExchangeRate Retriever seems to have duplicate timers scheduled whenever
retrieve_every
is configured, this results in the OpenExchangeRates (of whichever configured api module) to fetch rates 2x as often.I believe it's happening here:
money/lib/money/exchange_rates/exchange_rates_retriever.ex
Lines 263 to 267 in 7fab9d5
Which both land here:
money/lib/money/exchange_rates/exchange_rates_retriever.ex
Lines 329 to 333 in 7fab9d5
Let's try to track it, and let's assume
retrieve_every
is 1000ms.schedule_work(0)
casts a message to immediately fetch exchange rates. This is put into mailbox. Expected to process immediately after initializing.schedule_work(1000)
casts another message to fetch exchange rates 1000ms from now.:latest_rates
message is processed in the mailbox, the API is immediately hit and now weschedule_work(1000)
again, expected around 1002ms (now + 1000ms).One solution I've done to avoid this issue is to store a reference of the timer in the genserver state, and whenever scheduling work, you cancel the timer and reset it.
The text was updated successfully, but these errors were encountered: