You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently unique fields does the most of the migration work based on db; this means the start up is lock until the query gets done for a while.
As a Saas we need to do the migration in background, be not eager on resources (lock tables for a while or use intensive gpu), also the tracking is not possible since the query run as an one unit, the process one by one give us more logs and granularity about any error for a single contentlet (for instance if a contentlet unique field generations fails, we can track and continue with others)
The proposal will use a Thread pool with two thread max, in order to run 2 content types at the same time.
The proposal will have more logs, so we can see the progress or how is it going
The proposal could be fire automatically or by demand, it allow us to do not need to restart the server in case we need to dry run and re-run (aka run by rest only ADMIN)
The proposal will use a batches of 100 contentlets per read per thread to avoid the intensive usage of the cpu and memory
In order to avoid the starvation, we need to sleep the two threads any time a batch is processed by one second (configurable) this will allow other threads in competition to do their work
Proposed Objective
Core Features
Proposed Priority
Priority 3 - Average
Acceptance Criteria
No response
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
No response
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response
The text was updated successfully, but these errors were encountered:
Parent Issue
No response
Task
Currently unique fields does the most of the migration work based on db; this means the start up is lock until the query gets done for a while.
As a Saas we need to do the migration in background, be not eager on resources (lock tables for a while or use intensive gpu), also the tracking is not possible since the query run as an one unit, the process one by one give us more logs and granularity about any error for a single contentlet (for instance if a contentlet unique field generations fails, we can track and continue with others)
Proposed Objective
Core Features
Proposed Priority
Priority 3 - Average
Acceptance Criteria
No response
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
No response
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response
The text was updated successfully, but these errors were encountered: