Github user vanzin commented on the pull request:
https://github.com/apache/spark/pull/12113#issuecomment-217514209
The broadcast workaround looks ok to me, but does the thread pool really
help in the non-broadcast case?
The message loop eventually just calls `context.reply(mapOutputStatuses)`;
I don't see anywhere where it's actually blocking to avoid filling up the
message queues in the RPC layer. So if you're under the broadcast limit, and
you have lots and lots of executors, you still could run out of memory, right?
On a side not, I remember from a long time ago that there was talk about
embedding this information in the tasks sent to executors (i.e. the task would
contain the location of the shuffle blocks needed to finish that task), instead
of having every executor fetch the whole output map. Did you consider that
option when looking at this? Without too much thinking it seems like it would
be a better (and simpler?) long-term solution, but maybe I'm missing something.
---
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]
