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

Internal bulk response size may exceed over load_limit of DRb #30

Closed
y10k opened this issue Nov 19, 2019 · 2 comments
Closed

Internal bulk response size may exceed over load_limit of DRb #30

y10k opened this issue Nov 19, 2019 · 2 comments
Labels

Comments

@y10k
Copy link
Owner

y10k commented Nov 19, 2019

Internal responses from engine to decoder are bulked to reduce DRb communication overhead.
Total size of the responses is not taken into account, and it may exceed over the DRb communication upper limit.
The FETCH command is particularly dangerous.

@y10k y10k added the bug label Nov 19, 2019
@y10k
Copy link
Owner Author

y10k commented Nov 22, 2019

Any IMAP command in the selected state can return any untagged responses, potentially exceeding the DRb's load_limit, though I think it's almost impossible.
Every IMAP commands may be treated as a bulk response just in case.

y10k added a commit that referenced this issue Dec 6, 2019
Github Issue: #30

Define class to aggregate behavior of bulk response.
y10k added a commit that referenced this issue Dec 6, 2019
Github Issue: #30

Codes of internal bulk response are replaced by bulk response class.
y10k added a commit that referenced this issue Dec 6, 2019
Github Issue: #30

If bulk response is fragmented, the overhead of DRb's IPC increases.
When fragmentation is severe, the overhead is reduced by joining them
into a large chunk.
@y10k
Copy link
Owner Author

y10k commented Dec 6, 2019

It is a future task to make untagged responses internal bulked.

@y10k y10k closed this as completed Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant