Skip to content
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

[13.0] Add ddmrp_cron_actions_as_job #81

Merged
merged 5 commits into from
Feb 3, 2021

Conversation

guewen
Copy link
Member

@guewen guewen commented Oct 29, 2020

It makes every calls to "cron_actions" run in queue jobs.

The jobs have an identity key with "identity_exact", meaning that only
one occurence of a job for the same buffer with the same arguments
(only_nfp) will be created at a time (e.g. when the state of a
stock.move is changed several times in the same transaction or in
a different transaction in a short timeframe).

It needs OCA/queue#274 and OCA/queue#275

@OCA-git-bot
Copy link
Contributor

Hi @JordiBForgeFlow, @LoisRForgeFlow,
some modules you are maintaining are being modified, check this out!

@guewen guewen changed the title Add ddmrp_cron_actions_as_job [13.0] Add ddmrp_cron_actions_as_job Oct 29, 2020
simahawk
simahawk previously approved these changes Oct 29, 2020
Copy link

@simahawk simahawk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG

ddmrp/tests/common.py Show resolved Hide resolved
@guewen guewen changed the title [13.0] Add ddmrp_cron_actions_as_job [WIP][13.0] Add ddmrp_cron_actions_as_job Oct 29, 2020
@guewen
Copy link
Member Author

guewen commented Oct 29, 2020

OCA/queue#270 has a bug, so I'll propose a temporary alternative solution until I can fix this one

@guewen guewen dismissed simahawk’s stale review November 2, 2020 07:31

changed implementation, and need some work from me on the queue_job PRs to be ready

@guewen
Copy link
Member Author

guewen commented Nov 2, 2020

I pushed a new implementation that works by patching the method instead of relying on a decorator (see OCA/queue#270 (comment)). I still need to work on OCA/queue#274 for this to be ready.

@guewen guewen force-pushed the 13.0-ddmrp-auto-nfp-job branch 2 times, most recently from 83f87dc to 5515cf3 Compare November 2, 2020 15:41
@guewen guewen changed the title [WIP][13.0] Add ddmrp_cron_actions_as_job [13.0] Add ddmrp_cron_actions_as_job Nov 2, 2020
@mileo
Copy link
Member

mileo commented Feb 2, 2021

Could you add the module to oca_requirements.txt?

@guewen
Copy link
Member Author

guewen commented Feb 3, 2021

Could you add the module to oca_requirements.txt?

done

@guewen
Copy link
Member Author

guewen commented Feb 3, 2021

@JordiBForgeFlow @LoisRForgeFlow

I included the commits of #66 with a new commit fixing issues of #66:

  • Call commit once per chunk instead of once per record: commit flushes
    and clears the env, forcing a fetch of all the records of the chunk
    after each line.
  • Remove buffer.refresh() in cron_ddmrp(): this deprecated method
    calls invalidate_cache() without ids and field names, which forces
    a fetch of all the records of the chunk at each line. If it is
    required to invalidate something (but I could not find any
    explanation), we should invalidate only the ids and fields that needs
    invalidation (hopefully only non-stored computed fields). Or at the
    very least, do not fetch the 50 records of the browse at once but one
    by one (but that'd be a pity).

The duration of cron_ddmrp() (when generating jobs with ddmrp_cron_actions_as_job) goes from 8 minutes to 35 seconds.

Pay attention to the usage of refresh() / invalidate_cache() without specifying what to invalidate. It will force fetching again the records and computations, for all the pre-fetched ids. In the case of cron_actions, forcing to read the whole chunk again. As there was no indication why it was necessary, I removed it (when delaying a queue job it's never needed actually).

@guewen
Copy link
Member Author

guewen commented Feb 3, 2021

Pay attention to the usage of refresh() / invalidate_cache() without specifying what to invalidate. It will force fetching again the records and computations, for all the pre-fetched ids. In the case of cron_actions, forcing to read the whole chunk again. As there was no indication why it was necessary, I removed it (when delaying a queue job it's never needed actually).

As some tests failed, I looked again at this and found some fields to invalidate: ce5d553, these are the non-stored computed fields used by cron_actions

guewen and others added 5 commits February 3, 2021 09:54
It makes calls to "cron_actions" run in queue jobs.

The jobs have an identity key with "identity_exact", meaning that only
one occurence of a job for the same buffer with the same arguments
(only_nfp) will be created at a time (e.g. when the state of a
stock.move is changed several times in the same transaction or in
a different transaction in a short timeframe).

It needs OCA/queue#274 and
OCA/queue#275
commits and locking the buffers for too long.
* Call commit once per chunk instead of once per record: commit flushes
  and clears the env, forcing a fetch of all the records of the chunk
  after each line.
* Remove `buffer.refresh()` in cron_ddmrp(): this deprecated method
  calls `invalidate_cache()` without ids and field names, which forces
  a fetch of all the records of the chunk at each line. If it is
  required to invalidate something (but I could not find any
  explanation), we should invalidate only the ids and fields that needs
  invalidation (hopefully only non-stored computed fields). Or at the
  very least, do not fetch the 50 records of the browse at once but one
  by one (but that'd be a pity).

The duration of cron_ddmrp() (when generating jobs with
ddmrp_cron_actions_as_job) goes from 8 minutes to 35 seconds.
Fix tests:

* test_22_procure_recommended
* test_23_buffer_zones_all

It is possible that the invalidation is only required because of the
tests and would not be required at runtime. But this has been proposed
in the past: OCA#59

However, this commit tries to invalidate the less possible fields to
limit the computations and data to fetch again.
Copy link
Member

@jgrandguillaume jgrandguillaume left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM for what I can judge about.

Copy link
Contributor

@LoisRForgeFlow LoisRForgeFlow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Thanks for the detailed commit messages, it eases following the rational behind the changes.

ddmrp/models/stock_buffer.py Show resolved Hide resolved
@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@LoisRForgeFlow
Copy link
Contributor

/ocabot merge minor

@OCA-git-bot
Copy link
Contributor

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 13.0-ocabot-merge-pr-81-by-LoisRForgeFlow-bump-minor, awaiting test results.

@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at dd449e7. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants