BUG REPORT

1. Please describe the issue you observed:

• What did you do (The steps to reproduce)?
  MQMessage message;
  message.toString()

• What did you expect to see?
  It is not exception

• What did you see instead?
  Call MQMessage::toString() exception

2. Please tell us about your environment:

• What is your OS?
  ubuntu 18.04

• What is your client version?

• What is your RocketMQ version?
  RocketMQ4.4

3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

1. Please describe the issue you observed:

• What did you do (The steps to reproduce)?

rocketmq::WriteBigEndian(writeBuf , newBuf );

• What did you expect to see?
  No exception

• What did you see instead?
  /leaning/space-work/cpp-space/rocketmq-client-cpp/src/common/big_endian.h:50:52: error: invalid operands of types ‘char*’ and ‘int’ to binary ‘operator&’ buf[sizeof(T) - i - 1] = static_cast<char>(val & 0xFF); ^ /leaning/space-work/cpp-space/rocketmq-client-cpp/src/common/big_endian.h:51:9: error: invalid operands of types ‘char*’ and ‘int’ to binary ‘operator>>’ val >>= 8; ^ /leaning/space-work/cpp-space/rocketmq-client-cpp/src/common/big_endian.h:51:9: error: in evaluation of ‘operator>>=(char*, int)’

2. Please tell us about your environment:

• What is your OS?
  ubuntu 18.04

• What is your client version?
  master

• What is your RocketMQ version?
  4.4

3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

void DefaultMQPushConsumer::pullMessageAsync(PullRequest* request) {
if (request == NULL || request->isDroped()) {
LOG_WARN("Pull request is set drop with mq:%s, return",(request->m_messageQueue).toString().c_str());
request->removePullMsgEvent();
return;
}
。。。。
}

I try to set namesrv with host name ,but it doesn’t work:

1. producer.setNamesrvAddr("name1.xxx.domain:9876;name2.xxx.domain:9876");
2. producer.setNamesrvDomain("name1.xxx.domain:9876;name2.xxx.domain:9876");

And The following error occurred:

Type: MQClientException , msg: No route info of this topic, error:-1

It's ok only when i set namesrv with ip

producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");

BUG REPORT

1. Please describe the issue you observed:

• What did you do (The steps to reproduce)?
  `
  void SendCallbackWrap::operationComplete(ResponseFuture* pResponseFuture,
  bool bProducePullRequest) {

  if (!pResponse) {
  .....
  } else {
  try {
  ............
  } catch (MQException& e) {
  ..........
  if (pResponseFuture->getASyncFlag() && retryTimes < maxRetryTimes && maxRetryTimes > 1) {
  .........
  try {
  m_pClientAPI->sendMessageAsync(pResponseFuture->getBrokerAddr(), m_brokerName, m_msg, (RemotingCommand&)requestCommand, pCallback, left_timeout_ms, maxRetryTimes, retryTimes);
  } catch (MQClientException& e) {
  LOG_ERROR("retry send exception:%s, opaque:%d, retryTimes:%d, msg:%s, not retry send again", e.what(), opaque, retryTimes, m_msg.toString().data());
  exception_flag = true;
  }
  // 内存溢出，没有deleteAndZero AutoDeleteSendCallBack
  if (exception_flag == false) {
  return; //send retry again, here need return
  }
  }

    if (pCallback) {
    	MQException exception("process send response error", -1, __FILE__,
    	                      __LINE__);
    	pCallback->onException(exception);
    }
  

  }
  }
  if (pCallback && pCallback->getSendCallbackType() == autoDeleteSendCallback) {
  deleteAndZero(pCallback);
  }
  }
  `

[BUG REPORT] the CPP examples crash.

i compile this cpp project, then i get librocketmq.so which is about 30M, and librocketmq.a is about 90M, it is too big for a client sdk. i set boost_use_static_libs switch on,libevent_use_static_libs off,jsoncpp_use_static_libs on, gcc version is 4.8.5.

can anyone tell me how can reduce the size of librocketmq.so and librocketmq.a get from the project?

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

组网环境，当前3台服务器A(broker-a, broker-c-s)、B(broker-b, broker-a-s)、C(broker-c, broker-b-s)，同步复制，异步刷盘，当发送多条异步消息后此时每台服务的broker上都有消息，从控制端上也可看到master的消息同步到slave上了，此时停掉broker-a的master，启动消费者去消费，发现无法从broker-a-s，即其slave上消费，这是什么原因？

组网环境，当前3台服务器A(broker-a, broker-c-s)、B(broker-b, broker-a-s)、C(broker-c, broker-b-s)，同步复制，异步刷盘，发送顺序消息到一个master和同步到一个slave后，停掉master，创建消费者，订阅topic，注册顺序监听，启动顺序消费者时进程crash

Test Env:

• 1broker
• 1 push consumer

How to reproduce:

• Use push consumer to connect to broker,
• shutdown the broker
• restart the broker
• check the consumer

logs:

[2018-Dec-12 07:29:30.760170](info):namesrvIndex is:8, index:0, namesrvaddrlist size:1

[2018-Dec-12 07:29:31.240943](info):Wait till event base is looping

[2018-Dec-12 07:29:31.637820](info):eventcb: received event:11 on fd:14

[2018-Dec-12 07:29:31.637899](info):eventcb:rcv error event cb:11 on fd:14

[2018-Dec-12 07:29:31.637931](info):event_base_dispatch exit once

[2018-Dec-12 07:29:32.241539](info):Wait till event base is looping

[2018-Dec-12 07:29:33.242114](info):Wait till event base is looping

[2018-Dec-12 07:29:33.760524](error):GetTransport of:172.17.0.2:9876 get timed_mutex timeout

[2018-Dec-12 07:29:33.760650](info):updateTopicRouteInfoFromNameServer start:T_TestTopic

[2018-Dec-12 07:29:33.760759](info):namesrvIndex is:9, index:0, namesrvaddrlist size:1

[2018-Dec-12 07:29:34.242835](info):Wait till event base is looping

[2018-Dec-12 07:29:35.243643](info):Wait till event base is looping

[2018-Dec-12 07:29:36.244387](info):Wait till event base is looping

[2018-Dec-12 07:29:36.761118](error):GetTransport of:172.17.0.2:9876 get timed_mutex timeout

[2018-Dec-12 07:29:37.244875](info):Wait till event base is looping

[2018-Dec-12 07:29:38.245616](info):Wait till event base is looping

[2018-Dec-12 07:29:39.246274](info):Wait till event base is looping

[2018-Dec-12 07:29:40.246906](info):Wait till event base is looping

[2018-Dec-12 07:29:41.247591](info):Wait till event base is looping

[2018-Dec-12 07:29:42.248256](info):Wait till event base is looping

[2018-Dec-12 07:29:43.249143](info):Wait till event base is looping

my os is Ubuntu 16.04.2
i exec build.sh and i get the error :
configure.ac:101: error: possibly undefined macro: AC_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
i donot know what this means

In Ubuntu and MacOS, when we called C-API to get properties of messge, such as getTags and getKeys, I got wrong information.For example:

Msg Topic:test
Msg Tags:�H
Msg Keys:�H
Msg Body:world

I run "./PushConsumer“ fail after build example,but PullConsumer is ok. client log :
2019-01-18 17:31:35.315213:DefaultMQPushConsumer::boost asio async service runing
2019-01-18 17:31:35.317030:m_tcpConnectTimeout:400, m_tcpTransportTryLockTimeout:1, m_pullThreadNum:4
2019-01-18 17:31:35.317261:MQClient start,groupname:msg-persist-group_producer_sandbox,clientID:11113-fe80::f65d:28fe:7bfe:7546@DEFAULT,instanceName:DEFAULT,nameserveraddr:localhost:9876
2019-01-18 17:31:35.317323:DefaultMQProducer:msg-persist-group_producer_sandbox start
2019-01-18 17:31:35.317359:TcpRemotingClient::boost asio async service runing
2019-01-18 17:31:35.317389:update Namesrv:localhost:9876
2019-01-18 17:31:35.317633:user specfied name server address: localhost:9876
2019-01-18 17:31:35.317692:MQClientFactory:11113-fe80::f65d:28fe:7bfe:7546@DEFAULT start
2019-01-18 17:31:35.317841:sendheartbeat brokeradd is empty
2019-01-18 17:31:35.318023:start scheduled task:11113-fe80::f65d:28fe:7bfe:7546@DEFAULT
2019-01-18 17:31:35.318503:m_tcpConnectTimeout:400, m_tcpTransportTryLockTimeout:1, m_pullThreadNum:4
2019-01-18 17:31:35.318717:MQClient start,groupname:sdk,clientID:11113-fe80::f65d:28fe:7bfe:7546@sdk,instanceName:sdk,nameserveraddr:localhost:9876
2019-01-18 17:31:35.318777:TcpRemotingClient::boost asio async service runing
2019-01-18 17:31:35.318777:DefaultMQPushConsumer:sdk start
2019-01-18 17:31:35.319011:start concurrently consume service:sdk
2019-01-18 17:31:35.320613:buildSubscriptionData,:sdktesting,*
2019-01-18 17:31:35.320714:update Namesrv:localhost:9876
2019-01-18 17:31:35.320748:user specfied name server address: localhost:9876
2019-01-18 17:31:35.320776:MQClientFactory:11113-fe80::f65d:28fe:7bfe:7546@sdk start
2019-01-18 17:31:35.320866:updateTopicRouteInfoFromNameServer start:%RETRY%sdk
2019-01-18 17:31:35.321093:start scheduled task:11113-fe80::f65d:28fe:7bfe:7546@sdk
2019-01-18 17:31:35.321229:namesrvIndex is:1, index:0, namesrvaddrlist size:1
2019-01-18 17:31:35.321753:try to connect to fd:20, addr:127.0.0.1
2019-01-18 17:31:35.321929:Wait till event base is looping
2019-01-18 17:31:35.322036:Notify on event_base_dispatch
2019-01-18 17:31:35.322194:eventcb: received event:80 on fd:20
2019-01-18 17:31:35.322264:eventcb:connect to fd:20 successfully
2019-01-18 17:31:35.322310:received libevent callback event
2019-01-18 17:31:35.328046:sendheartbeat brokeradd is empty
2019-01-18 17:31:35.331145:sendheartbeat brokeradd is empty
2019-01-18 17:31:36.722216:connect timeout
2019-01-18 17:31:36.722389:connect server with addr:localhost:9876 success
2019-01-18 17:31:36.724738:updateTopicRouteInfoFromNameServer has data
2019-01-18 17:31:36.724905:updateTopicRouteInfoFromNameServer changed:%RETRY%sdk
2019-01-18 17:31:36.724944:updateTopicRouteInfoFromNameServer changed with broker name:TaoChen
2019-01-18 17:31:36.725128:updateTopicRouteInfoFromNameServer start:sdktesting
2019-01-18 17:31:36.727285:updateTopicRouteInfoFromNameServer has data
2019-01-18 17:31:36.727459:updateTopicRouteInfoFromNameServer changed:sdktesting
2019-01-18 17:31:36.727516:updateTopicRouteInfoFromNameServer changed with broker name:TaoChen
2019-01-18 17:31:36.728305:try to connect to fd:28, addr:10.8.64.103
2019-01-18 17:31:36.728513:Wait till event base is looping
2019-01-18 17:31:36.729229:Notify on event_base_dispatch
2019-01-18 17:31:36.729407:eventcb: received event:80 on fd:28
2019-01-18 17:31:36.729468:eventcb:connect to fd:28 successfully
2019-01-18 17:31:36.729513:received libevent callback event
2019-01-18 17:31:37.131392:connect timeout
2019-01-18 17:31:37.131564:connect server with addr:10.8.64.103:10911 success
2019-01-18 17:31:37.135192:notifyConsumerIdsChanged:sdk
2019-01-18 17:31:37.135263:sendheartbeat to broker:10.8.64.103:10911 success
2019-01-18 17:31:37.135375:Client factory:11113-fe80::f65d:28fe:7bfe:7546@sdk start dorebalance for consumer:sdk
2019-01-18 17:31:37.135453:Client factory:11113-fe80::f65d:28fe:7bfe:7546@sdk start dorebalance
2019-01-18 17:31:37.135497:current topic is:%RETRY%sdk
2019-01-18 17:31:37.135543:getConsumerIdList from broker:10.8.64.103:10911
2019-01-18 17:31:37.137827:client id:11113-fe80::f65d:28fe:7bfe:7546@sdk of topic:%RETRY%sdk
2019-01-18 17:31:37.137960:range is:1, index is:0, mqAllSize is:1, averageSize is:1, startIndex is:0
2019-01-18 17:31:37.138004:allocate mq:MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0]
2019-01-18 17:31:37.138033:updateRequestTableInRebalance Doesn't find old mq
2019-01-18 17:31:37.140010:CONSUME_FROM_LAST_OFFSET, lastOffset of mq:MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0] is:0
2019-01-18 17:31:37.140153:add mq:MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0], request initiall offset:0
2019-01-18 17:31:37.140208:pullRequest with mq :MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0] set pullMsgEvent
2019-01-18 17:31:37.140277:current topic is:sdktesting
2019-01-18 17:31:37.140336:getConsumerIdList from broker:10.8.64.103:10911
2019-01-18 17:31:37.140548:new pull callback for mq:MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0]
2019-01-18 17:31:37.142611:client id:11113-fe80::f65d:28fe:7bfe:7546@sdk of topic:sdktesting
2019-01-18 17:31:37.142768:range is:4, index is:0, mqAllSize is:4, averageSize is:4, startIndex is:0
2019-01-18 17:31:37.142836:allocate mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=0]
2019-01-18 17:31:37.142885:allocate mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=1]
2019-01-18 17:31:37.142930:allocate mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=2]
2019-01-18 17:31:37.142975:allocate mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=3]
2019-01-18 17:31:37.143020:updateRequestTableInRebalance Doesn't find old mq
2019-01-18 17:31:37.145007:CONSUME_FROM_LAST_OFFSET, lastOffset of mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=0] is:0
2019-01-18 17:31:37.145110:add mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=0], request initiall offset:0
2019-01-18 17:31:37.145139:updateRequestTableInRebalance Doesn't find old mq
2019-01-18 17:31:37.146870:CONSUME_FROM_LAST_OFFSET, lastOffset of mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=1] is:0
2019-01-18 17:31:37.146958:add mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=1], request initiall offset:0
2019-01-18 17:31:37.146988:updateRequestTableInRebalance Doesn't find old mq
2019-01-18 17:31:37.148753:CONSUME_FROM_LAST_OFFSET, lastOffset of mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=2] is:0
2019-01-18 17:31:37.148885:add mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=2], request initiall offset:0
2019-01-18 17:31:37.148918:updateRequestTableInRebalance Doesn't find old mq
2019-01-18 17:31:37.150613:CONSUME_FROM_LAST_OFFSET, lastOffset of mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=3] is:0
2019-01-18 17:31:37.150735:add mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=3], request initiall offset:0
2019-01-18 17:31:37.150780:pullRequest with mq :MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=0] set pullMsgEvent
2019-01-18 17:31:37.150835:pullRequest with mq :MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=1] set pullMsgEvent
2019-01-18 17:31:37.150869:pullRequest with mq :MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=2] set pullMsgEvent
2019-01-18 17:31:37.150921:pullRequest with mq :MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=3] set pullMsgEvent
2019-01-18 17:31:37.151077:current topic is:%RETRY%sdk
2019-01-18 17:31:37.151224:getConsumerIdList from broker:10.8.64.103:10911
2019-01-18 17:31:37.151070:new pull callback for mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=0]
2019-01-18 17:31:37.151416:new pull callback for mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=1]
2019-01-18 17:31:37.151613:new pull callback for mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=2]
2019-01-18 17:31:37.152059:new pull callback for mq:MessageQueue [topic=sdktesting, brokerName=TaoChen, queueId=3]
2019-01-18 17:31:37.154975:client id:11113-fe80::f65d:28fe:7bfe:7546@sdk of topic:%RETRY%sdk
2019-01-18 17:31:37.155199:range is:1, index is:0, mqAllSize is:1, averageSize is:1, startIndex is:0
2019-01-18 17:31:37.155294:allocate mq:MessageQueue [topic=%RETRY%sdk, brokerName=TaoChen, queueId=0]
2019-01-18 17:31:37.155368:current topic is:sdktesting
2019-01-18 17:31:37.155430:getConsumerIdList from broker:10.8.64.103:10911

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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:

wrong lock flag for pull request in orderly consume when unlock

• What did you do (The steps to reproduce)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

I was confused about how to send transactional message？

I want to use 'DefaultMQPullConsumer:: pull' in my code, but what's the best practice for supporting concurrent pull?

Now, I'm using multi-thread which shares one client instance, (example: std::shared_ptr), is it right? any suggestion?

Also, I want to concurrent produce msgs, but this one, I believe just multi-thread is good enough.

Thanks.

BUG REPORT

1. Please describe the issue you observed:

• What did you do (The steps to reproduce)?
  MQDecoder::createMessageId != MQDecoder::decodeMessageId

• What did you expect to see?
  MQDecoder::createMessageId == MQDecoder::decodeMessageId

• What did you see instead?
  string msgIdStr = MQDecoder::createMessageId(rocketmq::IPPort2socketAddress(inet_addr("127.0.0.1"), 10091),(int64) 1024); MQMessageId msgId = MQDecoder::decodeMessageId(msgIdStr); EXPECT_EQ(msgId.getOffset(), 1024);

2. Please tell us about your environment:

• What is your OS?
  ubuntu 18.04

• What is your client version?

• What is your RocketMQ version?
  RocketMQ 4.4

3. Other information (e.g. detailed explanation, logs, related issues, suggestions on how to fix, etc):

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

Add version info for rocketmq.so for different version
when build rocketmq client, there need version info in the so name, such as librocketmq.so.1.2.0

2. Provide any additional detail on your proposed use case for this feature.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

MQClientException , msg: Invoke Broker exception,error:-1,in file rocketmq/src/MQClientFactory.cpp> line:952

BUG REPORT

1. Please describe the issue you observed:
   Get the right value。

• What did you do (The steps to reproduce)?
  MQMessageExt *mqMessageExt = new MQMessageExt(); CMessageExt *messageExt = (CMessageExt*)mqMessageExt; mqMessageExt->setStoreTimestamp(123123); GetMessageStoreTimestamp(messageExt);

• What did you expect to see?
  CMessageExt.GetMessageStoreTimestamp == MQMessageExt.getStoreTimestamp

• What did you see instead?

when allocate opaque, 'fetch_add' is ok, don't need lock.

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

delete ResponseFuture when invokeHeartBeat is failed.

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

Do you have any plans to support build x64 version?

Or can you tell me how to change the source to support build x64 version?

2019-Apr-11 13:52:05.839388:unregisterClient to broker:10.4.44.76:10911
2019-Apr-11 13:52:05.839669:try to connect to fd:28, addr:10.4.44.76
2019-Apr-11 13:52:05.839762:Wait till event base is looping
2019-Apr-11 13:52:05.839773:Notify on event_base_dispatch
2019-Apr-11 13:52:05.853544:eventcb: received event:80 on fd:28
2019-Apr-11 13:52:05.853618:eventcb:connect to fd:28 successfully
2019-Apr-11 13:52:05.853643:received libevent callback event
2019-Apr-11 13:52:09.843417:connect timeout
2019-Apr-11 13:52:09.843516:connect server with addr:10.4.44.76:10911 success
2019-Apr-11 13:52:09.857889:unregisterClient to:10.4.44.76:10911 success

以上是日志信息，connect每个broker都耗时接近4s，看上去应该很早就connect成功了，但是依然wait了4s，日志里出现'connect timeout'。

network: 2master + 2slave;
scence: 8 * consumer_1 and 8 * consumer_2 consume the same topic with push consume method
issue: the same consumer_1 or consumer_2 instance will get the same message twice at the same time some times.

I send one message,but i found incorrent bornTimestamp.
requestHeader->bornTimestamp

requestHeader->bornTimestamp = UtilAll::currentTimeMillis();

The following unix timestamp value is what i want. But i got incorrent currentTimeMillis by UtilAll::currentTimeMillis:

current time:2018/12/25 19:41:53
unix timestamp:1545738113705
result of UtilAll::currentTimeMillis:70913705

UtilAll::currentTimeMillis

uint64_t UtilAll::currentTimeMillis() {
  boost::posix_time::ptime current_date_microseconds =
      boost::posix_time::microsec_clock::local_time();
  return current_date_microseconds.time_of_day().total_milliseconds();
}

场景：服务器A启动8个生产者不停的分别往8个不同的topic发送消息，同时服务器B启动8个不同group组的消费者不停的分别消费这8个topic，消费一段时间后出现某个队列中的消息不消费了，慢慢个别队列也停止消费。

出现2019-Feb-23 23:52:51.464556:no response got for opaque:920486
2019-Feb-23 23:52:51.464588:send msg, callback timeout, opaque:920486, sendTimes:1, maxRetryTimes:1错误后，broker-c, 的queueId=3这个队列就找不到了，即消费不到该队列中的消息。

日志：
2019-Feb-23 23:52:51.461848:FOUND:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-c, queueId=3] with size:1, nextBeginOffset:171597
2019-Feb-23 23:52:51.461897: offset result is:171597, m_queueOffsetMax is:171596, msgs size:1
2019-Feb-23 23:52:51.461932:remove these msg from m_msgTreeMap, its offset:171596
2019-Feb-23 23:52:51.461958:pullMessageAsync set opaque:920485, mq:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-b, queueId=1]
2019-Feb-23 23:52:51.462000:before insert declared filed,MAP SIZE is:2
2019-Feb-23 23:52:51.462013:invokeAsync success, addr:202.15.8.161:10911, code:11, opaque:920485
2019-Feb-23 23:52:51.462057:after insert declared filed, MAP SIZE is:12
2019-Feb-23 23:52:51.462082:total msg info are:ALIYUN171597groupaa0083231715971550934443954150007MQ_TOPIC_EFC_DEVICE_STATUS, size is:77
2019-Feb-23 23:52:51.462163:pullMessageAsync set opaque:920486, mq:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-c, queueId=3]
2019-Feb-23 23:52:51.462207:invokeAsync success, addr:202.15.8.162:10911, code:11, opaque:920486
2019-Feb-23 23:52:51.463762:fd:23, totalLen:453, bytesInMessage:449
2019-Feb-23 23:52:51.463807:had received all data with len:453 from fd:23
2019-Feb-23 23:52:51.463829:broker addr: 202.15.8.160, broker port: 10911
2019-Feb-23 23:52:51.463849:brokerAddr:202.15.8.160:10911
2019-Feb-23 23:52:51.463872: too little data received with sum = 0
2019-Feb-23 23:52:51.463914:code:0, remark:JAVA, version:277, opaque:920474, flag:1, remark:FOUND, headLen:226, bodyLen:219
2019-Feb-23 23:52:51.463975:processResponseCommand, code:11,opaque:920474, maxRetryTimes:1, retrySendTimes:1
2019-Feb-23 23:52:51.464004:cancelTimerCallback: opaque:920474
2019-Feb-23 23:52:51.464044:handleAsyncPullForResponseTimeout opaque:920474, e_code:0, msg:Success
2019-Feb-23 23:52:51.464057:PullRequest: putMessage m_queueOffsetMax:163072
2019-Feb-23 23:52:51.464136:FOUND:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-a, queueId=0] with size:1, nextBeginOffset:163073
2019-Feb-23 23:52:51.464158:m_queueOffsetMax is:163072
2019-Feb-23 23:52:51.464211: offset result is:163073, m_queueOffsetMax is:163072, msgs size:1
2019-Feb-23 23:52:51.464234:remove these msg from m_msgTreeMap, its offset:163072
2019-Feb-23 23:52:51.464277:before insert declared filed,MAP SIZE is:2
2019-Feb-23 23:52:51.464331:after insert declared filed, MAP SIZE is:12
2019-Feb-23 23:52:51.464352:total msg info are:ALIYUN163072groupaa0083201630731550934443954150007MQ_TOPIC_EFC_DEVICE_STATUS, size is:77
2019-Feb-23 23:52:51.464434:pullMessageAsync set opaque:920486, mq:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-a, queueId=0]
2019-Feb-23 23:52:51.464471:addTimerCallback:erase timerCallback opaque:920486
2019-Feb-23 23:52:51.464507:handleAsyncPullForResponseTimeout opaque:920486, e_code:0, msg:Success
2019-Feb-23 23:52:51.464509:invokeAsync success, addr:202.15.8.160:10911, code:11, opaque:920486
2019-Feb-23 23:52:51.464556:no response got for opaque:920486
2019-Feb-23 23:52:51.464588:send msg, callback timeout, opaque:920486, sendTimes:1, maxRetryTimes:1
2019-Feb-23 23:52:51.464616:pullrequest for:MessageQueue [topic=MQ_TOPIC_EFC_DEVICE_STATUS, brokerName=broker-a, queueId=0] occurs exception, reproduce it
2019-Feb-23 23:52:51.464640:eraseTimerCallback: opaque:920486
2019-Feb-23 23:52:51.464669:handleAsyncPullForResponseTimeout opaque:920486, e_code:0, msg:Success

win32_build.bat is hardcoded for Visual Studio 2015.
It's better to support both 2015 and 2017.

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?
  call NameSpaceUtil::formatNameServerURL with "192.168.17.43:9876;192.168.17.44:9876" on mac return ".17.43:9876;192.168.17.44:9876" and start consumer failed. then, encounter segment fault when exit.

• What did you expect to see?
  return "192.168.17.43:9876;192.168.17.44:9876"

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?
  macOS Mojave 10.14.4

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

CreateMessage but without DestroyMessage for example AsyncProducer and SyncProducer in CAsyncProducer.c and Producer.c

void startSendMessage(CProducer *producer) {
........
CMessage *msg = CreateMessage("T_TestTopic");
for (i = 0; i < 10; i++) {
.......
}
}

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

when many client start in same time, too many NOTIFY_CONSUMER_IDS_CHANGED cause so many rebalance, they block pullThread and all request will timeout.

• What did you expect to see?

response come, and request return.

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

有2个问题，希望能得到各位的帮助，谢谢：
1.环境是多Master多Slave模式，同步双写，使用order模式生产和消费。消费者先启动，生产者发送数据，消费者需要等很长一段时间才能消费（差不多30秒），不知道什么原因？
2.多进程消费同一个topic时，发现偶尔有重复数据，不知道什么原因？

copy s_seqNumber in RemotingCommand::Assign cause duplicated opaque.

https://help.aliyun.com/document_detail/102895.html?spm=5176.ons.ClientManagement.2.12be6c5caayp7K#20190116.1

Producer 报错日志：

[2019-Mar-20 17:04:42.658904](info):m_tcpConnectTimeout:3000, m_tcpTransportTryLockTimeout:3, m_pullThreadNum:12
[2019-Mar-20 17:04:42.659166](info):MQClient start,groupname:CID-kg-data-sync,clientID:24453-30.17.224.62@DEFAULT,instanceName:DEFAULT,nameserveraddr:MQ_INST_1730073665186091_Bae8Titg.mq-internet-access.mq-internet.aliyuncs.com:80
[2019-Mar-20 17:04:42.659202](info):DefaultMQProducer:CID-kg-data-sync start
[2019-Mar-20 17:04:42.659199](info):TcpRemotingClient::boost asio async service runing
[2019-Mar-20 17:04:42.659241](info):update Namesrv:MQ_INST_1730073665186091_Bae8Titg.mq-internet-access.mq-internet.aliyuncs.com:80
[2019-Mar-20 17:04:42.659283](info):user specfied name server address: MQ_INST_1730073665186091_Bae8Titg.mq-internet-access.mq-internet.aliyuncs.com:80
[2019-Mar-20 17:04:42.659308](info):MQClientFactory:24453-30.17.224.62@DEFAULT start
[2019-Mar-20 17:04:42.659350](warning):sendheartbeat brokeradd is empty
[2019-Mar-20 17:04:42.659418](info):start scheduled task:24453-30.17.224.62@DEFAULT
[2019-Mar-20 17:04:42.671387](warning):sendheartbeat brokeradd is empty
[2019-Mar-20 17:04:45.664350](info):updateTopicRouteInfoFromNameServer start:TBW102
[2019-Mar-20 17:04:45.664729](info):namesrvIndex is:1, index:0, namesrvaddrlist size:1
[2019-Mar-20 17:04:45.667634](info):try to connect to fd:23, addr:MQ_INST_1730073665186091_Bae8Titg.mq-internet-access.mq-internet.aliyuncs.com
[2019-Mar-20 17:04:45.667754](info):Wait till event base is looping
[2019-Mar-20 17:04:45.667793](info):Notify on event_base_dispatch
[2019-Mar-20 17:04:45.667924](info):eventcb: received event:80 on fd:23
[2019-Mar-20 17:04:45.667984](info):eventcb:connect to fd:23 successfully
[2019-Mar-20 17:04:45.668032](info):received libevent callback event
[2019-Mar-20 17:04:49.669743](info):connect timeout
[2019-Mar-20 17:04:49.669884](info):connect server with addr:MQ_INST_1730073665186091_Bae8Titg.mq-internet-access.mq-internet.aliyuncs.com:80 success
[2019-Mar-20 17:05:12.673456](warning):sendheartbeat brokeradd is empty
[2019-Mar-20 17:05:15.663867](info):updateTopicRouteInfoFromNameServer start:TBW102
[2019-Mar-20 17:05:29.833375](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.858696](info):updateTopicRouteInfoFromNameServer has data
[2019-Mar-20 17:05:29.858795](info):updateTopicRouteInfoFromNameServer changed:
[2019-Mar-20 17:05:29.858889](info):updateTopicRouteInfoFromNameServer with default
[2019-Mar-20 17:05:29.858940](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.880740](warning):tryToFindTopicPublishInfo null:
[2019-Mar-20 17:05:29.880816](warning):Retry many times, still failed
[2019-Mar-20 17:05:29.880847](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.917073](info):updateTopicRouteInfoFromNameServer has data
[2019-Mar-20 17:05:29.917208](info):updateTopicRouteInfoFromNameServer changed:
[2019-Mar-20 17:05:29.917340](info):updateTopicRouteInfoFromNameServer with default
[2019-Mar-20 17:05:29.917410](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.935410](warning):tryToFindTopicPublishInfo null:
[2019-Mar-20 17:05:29.935541](warning):Retry many times, still failed
[2019-Mar-20 17:05:29.935608](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.955637](info):updateTopicRouteInfoFromNameServer has data
[2019-Mar-20 17:05:29.955777](info):updateTopicRouteInfoFromNameServer changed:
[2019-Mar-20 17:05:29.955925](info):updateTopicRouteInfoFromNameServer with default
[2019-Mar-20 17:05:29.956007](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:29.976046](warning):tryToFindTopicPublishInfo null:
[2019-Mar-20 17:05:29.976179](warning):Retry many times, still failed
[2019-Mar-20 17:05:29.976247](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:30.002507](info):updateTopicRouteInfoFromNameServer has data
[2019-Mar-20 17:05:30.002629](info):updateTopicRouteInfoFromNameServer changed:
[2019-Mar-20 17:05:30.002705](info):updateTopicRouteInfoFromNameServer with default
[2019-Mar-20 17:05:30.002743](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:30.023208](warning):tryToFindTopicPublishInfo null:
[2019-Mar-20 17:05:30.023299](warning):Retry many times, still failed
[2019-Mar-20 17:05:30.023341](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:30.043084](info):updateTopicRouteInfoFromNameServer has data
[2019-Mar-20 17:05:30.043142](info):updateTopicRouteInfoFromNameServer changed:
[2019-Mar-20 17:05:30.043200](info):updateTopicRouteInfoFromNameServer with default
[2019-Mar-20 17:05:30.043225](info):updateTopicRouteInfoFromNameServer start:
[2019-Mar-20 17:05:30.062510](warning):tryToFindTopicPublishInfo null:
[2019-Mar-20 17:05:30.062630](warning):Retry many times, still failed
[2019-Mar-20 17:05:30.062778](error):msg: No route info of this topic: 

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.
   ----rocketmq-client-cpp should support send batch message to broker

2. Provide any additional detail on your proposed use case for this feature.
   ----increase tps for rocketmq

3. 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?
   ----should-have

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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

OS: OS X 10.11.6

LOG:

[100%] Built target UrlTest
/usr/local/Cellar/cmake/3.11.2/bin/cmake -E cmake_progress_start /Users/wangqing/Workspace/coder/rocketmq-client-cpp/tmp_build_dir/CMakeFiles 0
usage:  ar -d [-TLsv] archive file ...
	ar -m [-TLsv] archive file ...
	ar -m [-abiTLsv] position archive file ...
	ar -p [-TLsv] archive [file ...]
	ar -q [-cTLsv] archive file ...
	ar -r [-cuTLsv] archive file ...
	ar -r [-abciuTLsv] position archive file ...
	ar -t [-TLsv] archive [file ...]
	ar -x [-ouTLsv] archive [file ...]
cp: librocketmq.a: No such file or directory
Do not execution test

It failed at ar command.

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

Is there any way to prevent or catch the crash of c++ exception throw while using pure c?
Such as no topic exception when calling SendMessageSync from sample "Producer.c".
Thank u very much.

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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:

FEATURE REQUEST

1. Please describe the feature you are requesting.

Support send message oneway orderly for C API

2. Provide any additional detail on your proposed use case for this feature.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

sudo apt-get install autotools-dev
sudo apt-get install aclocal
sudo apt-get install autotools-dev
sudo apt-get install aclocal
sudo apt-get install automake
sudo apt-get install aclocal
sudo apt-get install libz-dev
sudo apt-get install libbz2-dev
sudo apt-get install libboost-all-dev

i install dependency libraies，but when i exec the build.sh，there is a error , this look like the code has bug

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?
  sh build.sh

• What did you expect to see?

• What did you see instead?
  Linking CXX shared library ../../bin/librocketmq.so
  ../../bin/lib/libboost_locale.a ../../bin/lib/libboost_iostreams.a -ldl -lpthread -lrt -lz
  /usr/bin/ld: cannot find -lz
  collect2: error: ld returned 1 exit status
  make[2]: *** [../bin/librocketmq.so] Error 1
  make[2]: Leaving directory /opt/rocketmq-client-cpp-1.2.1-rc1/tmp_build_dir' make[1]: *** [project/CMakeFiles/rocketmq_shared.dir/all] Error 2 make[1]: Leaving directory /opt/rocketmq-client-cpp-1.2.1-rc1/tmp_build_dir'
  make: *** [all] Error 2

2. Please tell us about your environment:

• What is your OS?
  CentOS7.4
• What is your client version?
  1.2.1
• What is your RocketMQ version?
  4.4

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

What does onsChannel param mean in setSessionCredentials method?

1. Please describe the issue you observed:

• What did you do (The steps to reproduce)?

Value value;
ResetOffsetRequestHeader::Decode(value);

• What did you expect to see?
  No exception

• What did you see instead?

The line exception

LOG_INFO("topic:%s, group:%s, timestamp:%lld, isForce:%d,isForce:%s", h->topic.c_str(), h->group.c_str(), h->timestamp, h->isForce, tempValue.asCString());

2. Please tell us about your environment:

• What is your OS?
  ubuntu18.04

when i use rocketmq-client-cpp, two questions bother me:

1. consume of some queues is blocking, no PULL_MESSAGE will be sent.
2. consumerOffset of some queues will bigger than its brokerOffset.

The issue tracker is ONLY used for the CPP/C client (feature request of RocketMQ need to follow RIP process). 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. 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)?

• What did you expect to see?

• What did you see instead?

2. Please tell us about your environment:

• What is your OS?

• What is your client version?

• What is your RocketMQ version?

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.

3. 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: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

CPullConsumer cannot pull message

I check the code,found:

 if (pullResult.pullStatus != E_BROKER_TIMEOUT) {
      tmpoffset = pullResult.nextBeginOffset;
 }

The pullResult.nextBeginOffset will be store in tmpoffset when pullStatus is OFFSET_ILLEGAL.
But the nextBeginOffset is not put in pullResult when pullStatus is OFFSET_ILLEGAL,see the following code:

    switch (cppPullResult.pullStatus) {
        case FOUND: {
            pullResult.pullStatus = E_FOUND;
            pullResult.maxOffset = cppPullResult.maxOffset;
            pullResult.minOffset = cppPullResult.minOffset;
            pullResult.nextBeginOffset = cppPullResult.nextBeginOffset;
            pullResult.size = cppPullResult.msgFoundList.size();
            PullResult *tmpPullResult = new PullResult(cppPullResult);
            pullResult.pData = tmpPullResult;
            //Alloc memory to save the pointer to CPP MQMessageExt, which will be release by the CPP SDK core.
            //Thus, this memory should be released by users using @ReleasePullResult
            pullResult.msgFoundList = (CMessageExt **) malloc(pullResult.size * sizeof(CMessageExt *));
            for (size_t i = 0; i < cppPullResult.msgFoundList.size(); i++) {
                MQMessageExt *msg = const_cast<MQMessageExt *>(&tmpPullResult->msgFoundList[i]);
                pullResult.msgFoundList[i] = (CMessageExt *) (msg);
            }
            break;
        }
        case NO_NEW_MSG: {
            pullResult.pullStatus = E_NO_NEW_MSG;
            break;
        }
        case NO_MATCHED_MSG: {
            pullResult.pullStatus = E_NO_MATCHED_MSG;
            break;
        }
        case OFFSET_ILLEGAL: {
            pullResult.pullStatus = E_OFFSET_ILLEGAL;
            break;
        }
        case BROKER_TIMEOUT: {
            pullResult.pullStatus = E_BROKER_TIMEOUT;
            break;
        }
        default:
            pullResult.pullStatus = E_NO_NEW_MSG;
            break;

    }

send with autoRetryTimes only works for sync producer but not works for async producer for rocketmq-client-cpp with version 1.2.0