[GitHub] [rocketmq] Erik1288 opened a new issue, #4496: [OPTIMIZATION] Response should not be processed during the NettyReqeustProcessor requestProcess, neither by being assigned as NULL nor by being written to the Netty channel.

[GitBox]

Erik1288 opened a new issue, #4496:
URL: https://github.com/apache/rocketmq/issues/4496

   
   Here's some cases:
   <img width="1074" alt="image" 
src="https://user-images.githubusercontent.com/8181966/174936891-2988913f-dd35-4a17-affb-78e77cb41410.png";>
   When implementing zeroCopy, the response is written to the netty channel 
even before the processRequest method ends.
   
   <img width="927" alt="image" 
src="https://user-images.githubusercontent.com/8181966/174937336-4e168289-84ee-4296-a8c5-a5e1bd59e577.png";>
   When implementing long-polling, the response is assigned and returned as 
NULL instead of returning an asynchronous result.
   
   **FEATURE REQUEST**
   
   1. Please describe the feature you are requesting.
   * Refactoring the processRequest method signatures in concrete Processors by 
no longer taking channel as a parameter.
   * Refactoring logic like long-polling and Zerocopy that are not properly 
processing response during the NettyReqeustProcessor processing.
   
   3. Provide any additional detail on your proposed use case for this feature.
   No
   
   2. Indicate the importance of this issue to you (blocker, must-have, 
should-have, nice-to-have). Are you currently using any workarounds to address 
this issue?
   Nich to have. It will greatly facilitate batch request-response 
implementation.


-- 
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: dev-unsubscr...@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org