HubQin opened a new issue, #1047:
URL: https://github.com/apache/rocketmq-client-go/issues/1047

   The issue tracker is **ONLY** used for the go client (feature request of 
RocketMQ need to
   follow [RIP 
process](https://github.com/apache/rocketmq/wiki/RocketMQ-Improvement-Proposal)).
 Keep in mind, please check
   whether there is an existing same report before your raise a new one.
   
   Alternately (especially if your communication is not a bug report), you can 
send mail to
   our [mailing lists](http://rocketmq.apache.org/about/contact/). We welcome 
any friendly suggestions, bug fixes,
   collaboration, and other improvements.
   
   Please ensure that your bug report is clear and that it is complete. 
Otherwise, we may be unable to understand it or to
   reproduce it, either of which would prevent us from fixing the bug. We 
strongly recommend the report(bug report or
   feature request) could include some hints as to the following:
   
   **BUG REPORT**
   
   1. Please describe the issue you observed:
   
       - What did you do (The steps to reproduce)?
           - in example : 
https://github.com/apache/rocketmq-client-go/blob/master/examples/consumer/rpc/main.go
           - we can see code like this:
   
    ```
        err = c.Subscribe(topic, consumer.MessageSelector{
                Type: consumer.TAG, Expression: "*"}, func(ctx context.Context, 
msgs ...*primitive.MessageExt) (consumer.ConsumeResult, error) {
   
                fmt.Printf("subscribe callback: %v \n", msgs)
                for _, msg := range msgs {
                        fmt.Printf("handle message: %s", msg.String())
                        // why sleep here ? because if not sleep, consumer 
reply message, but producer not register to broker, it will
                        // make the broker can't find the reply channel.
                        // only the go client has this problem.
                        time.Sleep(time.Millisecond * 1000)
                        fmt.Println("consumer sleep over, start reply")
   
                        replyContent := []byte("reply message contents.")
                        replyMessage, err := consumer.CreateReplyMessage(msg, 
replyContent)
                        if err != nil {
                                fmt.Printf("create reply message err:%v\n", err)
                                continue
                        }
   .
   .
   .
   
   ```
   
   the comments say that:
   
      ```
      // why sleep here ? because if not sleep, consumer reply message, but 
producer not register to broker, it will
      // make the broker can't find the reply channel.
      // only the go client has this problem.
      ```    
   
   
    I wonder why should add `time.Sleep(time.Millisecond * 1000)` and how to 
resolve this problem? it obviously slow down my program.
   
    - What did you expect to see?
      - If remove line `time.Sleep(time.Millisecond * 1000)`, the rpc producer 
should receive the response
   
    - What did you see instead?
      - Actually, when remove `time.Sleep(time.Millisecond * 1000)`, the rpc 
producer report error message:
   
   ```
   Request message error: send request message to RequestTopic OK, but wait 
reply message timeout 5000 ms
   time="2023-05-08T10:31:51+08:00" level=error msg="send request message to 
RequestTopic OK, but wait reply message timeout 5000 ms"
   ```
   
   2. Please tell us about your environment:
   
       - What is your OS?
           - windows 10
   
       - What is your client version?
           - run client in windows10 , rocketmq-client-go version: 
github.com/apache/rocketmq-client-go/v2 v2.1.2-0.20230412142645-25003f6f083d
   
       - What is your RocketMQ version?
           - namesrv and broker in docker (rocketmq:4.7.0-alpine)
   
   3. Other information (e.g. detailed explanation, logs, related issues, 
suggestions on how to fix, etc):
   
   **FEATURE REQUEST**
   
   1. Please describe the feature you are requesting.
   
   2. Provide any additional detail on your proposed use case for this feature.
   
   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?
   
   4. If there are some sub-tasks using -[] for each subtask and create a 
corresponding issue to map to the sub task:
   
       - [sub-task1-issue-number](example_sub_issue1_link_here): sub-task1 
description here,
       - [sub-task2-issue-number](example_sub_issue2_link_here): sub-task2 
description here,
       - ...
   


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