Github user shubhamchopra commented on the issue:
https://github.com/apache/spark/pull/13152
The state being managed inside getRandomPeer() is also modified in a couple
of other places, so it won't be a very clean change to remove some of it out of
getRandomPeer. Even if that is done, I agree that your approach would only mean
calling getNextPeer. It would however mean adding adding more state to ensure
expected behavior in cases where block replication fails on a peer.
I am flexible about the implementation choices, so can do the modifications
if needed. Just to clarify on the motivation of this interface, I have another
PR [SPARK-15354](https://github.com/apache/spark/pull/13932) that shows a
couple of prioritizers that I intend to add (including a simple one that
replicates HDFS's block replication strategy). Note that in case of failures,
the list of peers is requested from the master afresh and is optimized over
again and with this interface. Let me know what you think.
---
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]
