SteNicholas commented on code in PR #3239:
URL: https://github.com/apache/celeborn/pull/3239#discussion_r2071167489
##########
common/src/main/java/org/apache/celeborn/common/network/server/TransportChannelHandler.java:
##########
@@ -152,8 +153,18 @@ public void channelInactive(ChannelHandlerContext ctx)
throws Exception {
@Override
public void channelRead(ChannelHandlerContext ctx, Object request) throws
Exception {
- if (request instanceof RequestMessage && !(request instanceof Heartbeat)) {
- requestHandler.handle((RequestMessage) request);
+ if (request instanceof RequestMessage) {
+ if (request instanceof Heartbeat) {
+ logger.debug("Received heartbeat from {}.",
NettyUtils.getRemoteAddress(ctx.channel()));
+ if (!enableHeartbeat) {
+ // Which disables heartbeat should send heartbeat for processing
heartbeat to avoid
+ // reading idleness of which enables heartbeat.
+ requestHandler.processHeartbeat();
Review Comment:
@mridulm, there is no case that both sides constantly sending Heartbeat's to
each other. I could give the following situations:
1. worker disables heartbeat and client disables heartbeat: the heartbeat
message does not send.
2. worker enables heartbeat and client disables heartbeat: client invokes
`processHeartbeat` and `fireChannelRead`, but worker only invoke
`fireChannelRead`.
3. worker disables heartbeat and client enables heartbeat: worker invokes
`processHeartbeat` and `fireChannelRead`, but client only invoke
`fireChannelRead`.
4. worker enables heartbeat and client enables heartbeat: worker and client
only invoke `fireChannelRead`.
Therefore, the heartbeat is only used to keep both sides of conection not
read idle and does not constantly send heartbeat. PTAL.
--
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]
