afterincomparableyum commented on code in PR #3583:
URL: https://github.com/apache/celeborn/pull/3583#discussion_r2813488475
##########
cpp/celeborn/client/reader/CelebornInputStream.cpp:
##########
@@ -189,9 +205,58 @@ void CelebornInputStream::moveToNextReader() {
std::shared_ptr<PartitionReader> CelebornInputStream::createReaderWithRetry(
const protocol::PartitionLocation& location) {
- // TODO: support retrying when createReader failed. Maybe switch to peer
- // location?
- return createReader(location);
+ const protocol::PartitionLocation* currentLocation = &location;
+ std::exception_ptr lastException;
+
+ while (fetchChunkRetryCnt_ < fetchChunkMaxRetry_) {
+ try {
+ VLOG(1) << "Create reader for location " << currentLocation->host << ":"
+ << currentLocation->fetchPort;
+ if (isExcluded(*currentLocation)) {
+ throw std::runtime_error(
+ "Fetch data from excluded worker! " +
+ currentLocation->hostAndFetchPort());
+ }
+ auto reader = createReader(*currentLocation);
+ return reader;
+ } catch (const std::exception& e) {
+ lastException = std::current_exception();
+ excludeFailedFetchLocation(currentLocation->hostAndFetchPort(), e);
+ fetchChunkRetryCnt_++;
+
+ if (currentLocation->hasPeer() && !readSkewPartitionWithoutMapRange_) {
+ if (fetchChunkRetryCnt_ % 2 == 0) {
+ std::this_thread::sleep_for(
+ std::chrono::milliseconds(retryWait_.count()));
+ }
Review Comment:
This is a good observation, but it is not necessarily a bug. The C++
behavior here matches the Java behavior exactly. The peer relationship is
one-directional by design. In Java, `setPeer` is only ever called on the
primary, meaning java has the same one directional relationship.
@SteNicholas what do you think? Right now, it matches the Java behavior,
meaning it will try it on the primary, switch to replica on failure, and retry
on replica for remaining attempts. Should we change this behavior or keep it as
is?
I say keep it as is. I am not worried about this comment by Copilot AI.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
