Github user vanzin commented on the pull request:
https://github.com/apache/spark/pull/5377#issuecomment-97596699
> I'm worried about CPU heavy encryption blocking the IO thread calling
transferTo
Yeah, that's the part that sucks with the current approach. But I couldn't
find an alternative.
- ThreadPerChannelEventLoop can solve the problem but doesn't sound like
the right approach.
- Using a separate thread pool for the encryption / decryption handlers is
possible, but we still need to guarantee ordering when pushing messages on the
outbound path; I don't think you're allowed to call blocking methods (like
`ChannelPromise.sync()`) in channel threads.
Alternative suggestions are mostly welcome, if available.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
