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

bulkio: refactor bulk processors to use ProcessorBase #57293

Closed
3 tasks done
pbardea opened this issue Dec 1, 2020 · 2 comments · Fixed by #57124
Closed
3 tasks done

bulkio: refactor bulk processors to use ProcessorBase #57293

pbardea opened this issue Dec 1, 2020 · 2 comments · Fixed by #57124
Assignees
Labels
A-disaster-recovery C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-disaster-recovery

Comments

@pbardea
Copy link
Contributor

pbardea commented Dec 1, 2020

Processors are expected to embed a ProcessorBase. BulkIO processors behave differently from typical SQL processors and have not in the past. It would be good to refactor these to use processor base as it is more actively maintained and supports mechanisms for draining errors through a flow if the bulk IO flows get more complex.

One thing of note is that BulkIO processors typically execute long-lasting requests and therefore benefit from running in parallel (they are frequently waiting on network or IO and are therefore not CPU bound).

@pbardea pbardea added C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) A-disaster-recovery labels Dec 1, 2020
@pbardea pbardea self-assigned this Dec 1, 2020
@pbardea pbardea linked a pull request Dec 1, 2020 that will close this issue
craig bot pushed a commit that referenced this issue Dec 14, 2020
57124: importccl: refactor import processor to use ProcessorBase r=pbardea a=pbardea

This commit refactors the import processor to use ProcessorBase.
Although this processor doesn't have any inputs and the main utility
that ProcessorBase provides is management of draining inputs, there is
still some utility for this processor to embed a ProcessorBase. As
tracing and other infrastructural improvements are made to
ProcessorBase, this allows the import processor to stay up to date with
these changes.

The way that this processor works is that it kicks off a goroutine on
start that will begin the import and start sending progress updates over
an internally maintained channel. Next() will continually read from that
channel until it is fully consumed, and then read the returned summary
generated by the goroutine.

Import is build this way so that it can manage concurrency internally to
the processor.

Relates to #57293.

Release note: None

Co-authored-by: Paul Bardea <[email protected]>
@craig craig bot closed this as completed in #57124 Dec 14, 2020
@pbardea
Copy link
Contributor Author

pbardea commented Dec 14, 2020

This got closed prematurely -- reopening until the other processor changes are merged.

@pbardea pbardea reopened this Dec 14, 2020
craig bot pushed a commit that referenced this issue Feb 1, 2021
57128:  backupccl: refactor backup/restore processors to use ProcessorBase r=adityamaru a=pbardea

This PR refactors the remaining processors used in backup/restore to use ProcessorBase.

Informs #57293.

See individual commits.

Co-authored-by: Paul Bardea <[email protected]>
@pbardea
Copy link
Contributor Author

pbardea commented Feb 26, 2021

@pbardea pbardea closed this as completed Feb 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-disaster-recovery C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) T-disaster-recovery
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants