ruanwenjun opened a new issue, #10827:
URL: https://github.com/apache/dolphinscheduler/issues/10827

   ### Search before asking
   
   - [X] I had searched in the 
[issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and 
found no similar feature requirement.
   
   
   ### Description
   
   Right now, the master and worker will send request/response to each other. 
And we use async mode, so once the client send a request to the server, he will 
not block, he just cache the request, and use the daemon thread to retry, if 
doesn't receive the ack of the server in a while. Once he receive the server's 
ack, he will remove the related cached request.
   <img width="638" alt="image" 
src="https://user-images.githubusercontent.com/22415594/177687774-383d63a0-4f25-4812-a35a-7262de030b4e.png";>
   
   The problem is that if the server send result to client by the old channel, 
the server may failed, due to the old channel closed.
   
   e.g.
   
   1. Master dispatch task to worker, the master client port is a random 
port(11111), the the worker server port is 1234.
   2. Worker will cache the channel(masterHost:11111).
   3. Worker will send response to master by the cached 
channel(masterHost:11111) and cached the response to memory used to retry if he 
doesn't received the ack of his response.
   
   If the channel masterHost: 11111 is closed, then the worker will always send 
response to master failed, since master doesn't has a nettyServer listen the 
11111 port.
   
   So I think when worker need to sent something to master, he need to send to 
the master's nettyServer, not master's nettyClient.
   
   ### Are you willing to submit a PR?
   
   - [X] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [X] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
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]

Reply via email to