[jira] [Commented] (ROCKETMQ-121) Support message filtering based on SQL92

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977962#comment-15977962
 ] 

ASF GitHub Bot commented on ROCKETMQ-121:
-

Github user vsair commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/82
  
@zhouxinyu  Conflicts have been resolved. Thanks.


> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-121) Support message filtering based on SQL92

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977953#comment-15977953
 ] 

ASF GitHub Bot commented on ROCKETMQ-121:
-

Github user coveralls commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/82
  

[![Coverage 
Status](https://coveralls.io/builds/11175865/badge)](https://coveralls.io/builds/11175865)

Coverage increased (+3.3%) to 37.892% when pulling 
**09dca7851d7a85e4e609a5f34d6abd91dc092b91 on vsair:ROCKETMQ-121** into 
**42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop**.



> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-121) Support message filtering based on SQL92

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977954#comment-15977954
 ] 

ASF GitHub Bot commented on ROCKETMQ-121:
-

Github user coveralls commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/82
  

[![Coverage 
Status](https://coveralls.io/builds/11175865/badge)](https://coveralls.io/builds/11175865)

Coverage increased (+3.3%) to 37.892% when pulling 
**09dca7851d7a85e4e609a5f34d6abd91dc092b91 on vsair:ROCKETMQ-121** into 
**42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop**.



> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-121) Support message filtering based on SQL92

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15977955#comment-15977955
 ] 

ASF GitHub Bot commented on ROCKETMQ-121:
-

Github user coveralls commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/82
  

[![Coverage 
Status](https://coveralls.io/builds/11175865/badge)](https://coveralls.io/builds/11175865)

Coverage increased (+3.3%) to 37.892% when pulling 
**09dca7851d7a85e4e609a5f34d6abd91dc092b91 on vsair:ROCKETMQ-121** into 
**42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop**.



> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-184) It takes too long(3-33 seconds) to switch to read from slave when master crashes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976840#comment-15976840
 ] 

ASF GitHub Bot commented on ROCKETMQ-184:
-

Github user coveralls commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/95
  

[![Coverage 
Status](https://coveralls.io/builds/11165283/badge)](https://coveralls.io/builds/11165283)

Coverage increased (+0.04%) to 34.666% when pulling 
**0dc37e1c10450f143e58faa857f5bf8ccbee1ca3 on 
Jaskey:ROCKETMQ-184-slave-switch** into 
**42f78c281cbeb5072b04eaf03b1a8059b8d281a7 on apache:develop**.



> It takes too long(3-33 seconds) to switch to read from slave when master 
> crashes
> 
>
> Key: ROCKETMQ-184
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-184
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client, rocketmq-remoting
>Reporter: Jaskey Lam
>Assignee: Xiaorui Wang
> Fix For: 4.2.0-incubating
>
>
> When master crashes, no notifier callback is triggered to pull message again.
> Instead, it relies on the scan service to trigger timeout and then re pull.
> But the pulling command has 30 seconds timeout, and after timeout, pulling 
> operation will be scheduled after 3 seconds.
> So it takes 3 to 33 seconds to switch to slave, which is too long and can be 
> optimized.
> The root cause is the below repull cost too long to be triggered when master 
> crashes
> {code}
> @Override
> public void onException(Throwable e) {
> if 
> (!pullRequest.getMessageQueue().getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX))
>  {
> log.warn("execute the pull request exception", e);
> }
> 
> DefaultMQPushConsumerImpl.this.executePullRequestLater(pullRequest, 
> PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-185) RocketMQ-MySQL design

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976813#comment-15976813
 ] 

ASF GitHub Bot commented on ROCKETMQ-185:
-

Github user zhaoqun911 commented on the issue:

https://github.com/apache/incubator-rocketmq-externals/pull/16
  
@vsair Yes,that's right.


> RocketMQ-MySQL design
> -
>
> Key: ROCKETMQ-185
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-185
> Project: Apache RocketMQ
>  Issue Type: New Feature
>  Components: rocketmq-externals
>Reporter: Qun Zhao
>Assignee: Qun Zhao
>
> This issue is purpose to discuss about RocketMQ-MySQL design.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-184) It takes too long(3-33 seconds) to switch to read from slave when master crashes

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976773#comment-15976773
 ] 

ASF GitHub Bot commented on ROCKETMQ-184:
-

GitHub user Jaskey opened a pull request:

https://github.com/apache/incubator-rocketmq/pull/95

[ROCKETMQ-184]-It takes too long(3-33 seconds) to switch to read from slave 
when master crashes


JIRA:https://issues.apache.org/jira/browse/ROCKETMQ-184?jql=project%20%3D%20ROCKETMQ

Problem, no listener is triggered when Chanel is close. 

When async command sent to the server, and the server is crash before 
sending response to client, the callback can not be invoked in time. Instead, 
the callback can only be triggered by the timeout scan service. 

This is obvious for pulling message since the timeout is by default 30 
seconds. So if master crashes before process response to the client, the client 
can not repull until scan service tell it, which takes at most 30 seconds. And 
repull will have 3 seconds delay, so the HA to read from slave has to take 3-33 
seconds when this problem occurs.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Jaskey/incubator-rocketmq 
ROCKETMQ-184-slave-switch

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-rocketmq/pull/95.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #95


commit 0dc37e1c10450f143e58faa857f5bf8ccbee1ca3
Author: Jaskey 
Date:   2017-04-19T09:13:09Z

invoke callback when channel is close after  sending async command




> It takes too long(3-33 seconds) to switch to read from slave when master 
> crashes
> 
>
> Key: ROCKETMQ-184
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-184
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client, rocketmq-remoting
>Reporter: Jaskey Lam
>Assignee: Xiaorui Wang
> Fix For: 4.2.0-incubating
>
>
> When master crashes, no notifier callback is triggered to pull message again.
> Instead, it relies on the scan service to trigger timeout and then re pull.
> But the pulling command has 30 seconds timeout, and after timeout, pulling 
> operation will be scheduled after 3 seconds.
> So it takes 3 to 33 seconds to switch to slave, which is too long and can be 
> optimized.
> The root cause is the below repull cost too long to be triggered when master 
> crashes
> {code}
> @Override
> public void onException(Throwable e) {
> if 
> (!pullRequest.getMessageQueue().getTopic().startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX))
>  {
> log.warn("execute the pull request exception", e);
> }
> 
> DefaultMQPushConsumerImpl.this.executePullRequestLater(pullRequest, 
> PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-129) Provide C/C++ sdk

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976528#comment-15976528
 ] 

ASF GitHub Bot commented on ROCKETMQ-129:
-

Github user hooligan520 commented on the issue:

https://github.com/apache/incubator-rocketmq-externals/pull/11
  
@zhouxinyu my github email is hooligan_...@qq.com


> Provide C/C++ sdk
> -
>
> Key: ROCKETMQ-129
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-129
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-externals
>Reporter: Eason Chen
>Assignee: Xiaorui Wang
>
> A lot of C legacy system needs to integrate with RocketMQ but no C SDK, it is 
> hard to use for business since rebuild using java is a big effort.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-81) Add the RocketMq plugin for the Apache Spark

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976379#comment-15976379
 ] 

ASF GitHub Bot commented on ROCKETMQ-81:


Github user vesense commented on the issue:

https://github.com/apache/incubator-rocketmq-externals/pull/4
  
NOTICE: PR #5 has merged into this one, the work are completed by both 
@hustfxj and I. And I have added the credit for him too.


> Add the RocketMq plugin for the Apache Spark
> 
>
> Key: ROCKETMQ-81
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-81
> Project: Apache RocketMQ
>  Issue Type: Task
>  Components: rocketmq-externals
>Affects Versions: 4.1.0-incubating
>Reporter: Longda Feng
>Assignee: Xin Wang
>Priority: Minor
>
> Since the Apache RocketMq 4.0 will be released in the next few days, we can 
> start the job of adding the RocketMq plugin for the Apache Spark.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-36) Improve broker's GC logs storing

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-36:
--
Fix Version/s: 4.1.0-incubating

> Improve broker's GC logs storing
> 
>
> Key: ROCKETMQ-36
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-36
> Project: Apache RocketMQ
>  Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.1.0-incubating
>
>
> To avoid disk I/O potential competition between GC and broker threads, GC 
> logs are placed into {{/dev/shm}}. This is a valid concern, but I propose 
> more consideration to be done to situations when the system crashes (and, as 
> a result, in-memory logs disappear).
> Long-term logging is essential for analysis of the brokers' performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-63) Integrate spark plugin

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-63:
--
Component/s: rocketmq-externals

> Integrate spark plugin
> --
>
> Key: ROCKETMQ-63
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-63
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-externals
>Reporter: hustfxj
>Assignee: vongosling
>
> In fact I have finished it. Now we can consumer messages  of RocketMq at 
> spark job. And the plugin supports the two modes: pull and push .



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-63) Integrate spark plugin

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-63:
--
Fix Version/s: (was: 4.1.0-incubating)

> Integrate spark plugin
> --
>
> Key: ROCKETMQ-63
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-63
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-externals
>Reporter: hustfxj
>Assignee: vongosling
>
> In fact I have finished it. Now we can consumer messages  of RocketMq at 
> spark job. And the plugin supports the two modes: pull and push .



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-71) remove commitlog, messagequeue bug

[yukon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976242#comment-15976242
 ] 

yukon commented on ROCKETMQ-71:
---

Just add a config item in your broker config file, like this:
{code}
cleanResourceInterval=100
{code}

> remove commitlog, messagequeue bug
> --
>
> Key: ROCKETMQ-71
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-71
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: liyinsheng
>Assignee: vongosling
>
> there is the following code in DefaultMessageStore.java 
> this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
> @Override
> public void run() {
> DefaultMessageStore.this.cleanFilesPeriodically();
> }
> }, 1000 * 60, this.messageStoreConfig.getCleanResourceInterval(), 
> TimeUnit.MILLISECONDS);
> scheduleAtFixedRate function should change to scheduleAtFixedRate because 
> executions will commence after {@code initialDelay} then {@code 
> initialDelay+period}, then {@code initialDelay + 2 * period}, and so on,that 
> means executions delay time should more and more longer



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-72) DefaultMessageStore cannot be properly shutdown when failed in the middle of start()

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-72:
--
Fix Version/s: 4.1.0-incubating

> DefaultMessageStore cannot be properly shutdown when failed in the middle of 
> start()
> 
>
> Key: ROCKETMQ-72
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-72
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Critical
> Fix For: 4.1.0-incubating
>
>
> If {{DefaultMessageStore#start}} fails before it reaches {{this.shutdown = 
> false;}} it remains _true_ and prevents proper shutdown.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-73) Do something with jmenv.tbsite.net

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-73:
--
Fix Version/s: (was: 4.1.0-incubating)
   4.2.0-incubating

> Do something with jmenv.tbsite.net
> --
>
> Key: ROCKETMQ-73
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-73
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Roman Shtykh
>Assignee: vongosling
> Fix For: 4.2.0-incubating
>
>
> When a user does not set name server address at the broker as an env 
> variable, (when enabled) an attempt to get the information from 
> {{jmenv.tbsite.net}} is done.
> It looks like something very specific to Alibaba (or some segment of 
> companies) and can be removed.
> The concern is -- we have a component in the code that can make calls to a 
> service ({{jmenv.tbsite.net}} in this case) that a user knows nothing about.
> As an option, instead of removing it, we can have an explanation about how a 
> user can configure a similar nameserver service.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-77) [TEST] org.apache.rocketmq.tools.* have NPEs

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-77.
-

> [TEST] org.apache.rocketmq.tools.* have NPEs
> 
>
> Key: ROCKETMQ-77
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-77
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-tools
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.1.0-incubating
>
>
> Run {{mvn test}} and see {{org.apache.rocketmq.tools.*}} having NPEs, because 
> no nameserver is started.
> This can be fixed by, for instance, having {{IntegrationTestBase}} staring a 
> nameserver when tests are being run.
> In general, I would throw an exception whenever obtaining a nameserver is 
> failed, rather than returning {{null}}, because a connection to the 
> nameserver is a must to do any useful work in RocketMQ.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-80) Add batch feature

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-80.
-

> Add batch feature
> -
>
> Key: ROCKETMQ-80
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-80
> Project: Apache RocketMQ
>  Issue Type: New Feature
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: dongeforever
>Assignee: dongeforever
> Fix For: 4.1.0-incubating
>
>
> Tests show that Kafka's million-level TPS is mainly owed to batch. When set 
> batch size to 1, the TPS is reduced an order of magnitude. So I try to add 
> this feature to RocketMQ.
> For a minimal effort, it works as follows:
> Only add synchronous send functions to MQProducer interface, just like 
> send(final Collection msgs).
> Use MessageBatch which extends Message and implements Iterable.
> Use byte buffer instead of list of objects to avoid too much GC in Broker.
> Split the decode and encode logic from lockForPutMessage to avoid too many 
> race conditions.
> Tests:
> On linux with 24 Core 48G Ram and SSD, using 50 threads to send 50Byte(body) 
> message in batch size 50, we get about 150w TPS until the disk is full.
> Potential problems:
> Although the messages can be accumulated in the Broker very quickly, it need 
> time to dispatch to the consume queue, which is much slower than accepting 
> messages. So the messages may not be able to be consumed immediately.
> We may need to refactor the ReputMessageService to solve this problem.
> And if guys have some ideas, please let me know or just share it in this 
> issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-82) Add the RocketMQ plugin for the Apache Flink

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-82:
--
Component/s: rocketmq-externals

> Add the RocketMQ plugin for the Apache Flink
> 
>
> Key: ROCKETMQ-82
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-82
> Project: Apache RocketMQ
>  Issue Type: Task
>  Components: rocketmq-externals
>Reporter: Longda Feng
>Assignee: Xin Wang
>Priority: Minor
>
> Since the Apache RocketMq 4.0 will be released in the next few days, we can 
> start the job of adding the RocketMq plugin for the Apache Flink.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-84) Cover example-module by integration test

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-84.
-
Resolution: Won't Fix

> Cover example-module by integration test
> 
>
> Key: ROCKETMQ-84
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-84
> Project: Apache RocketMQ
>  Issue Type: Improvement
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: dongeforever
>
> Since example-module isn't covered by unit test, so may be it test can do 
> this job. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Work started] (ROCKETMQ-86) Polish the release file format

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on ROCKETMQ-86 started by yukon.
-
> Polish the release file format
> --
>
> Key: ROCKETMQ-86
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-86
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: yukon
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> To match the source package format, modify the release file format from .tgz 
> to .zip.
> Refer to release.xml and release-client.xml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-86) Polish the release file format

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-86:
--
Fix Version/s: 4.1.0-incubating

> Polish the release file format
> --
>
> Key: ROCKETMQ-86
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-86
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: yukon
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> To match the source package format, modify the release file format from .tgz 
> to .zip.
> Refer to release.xml and release-client.xml



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-85) Polish README file and remove all the 3rd party links in it.

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-85.
-

> Polish README file and remove all the 3rd party links in it.
> 
>
> Key: ROCKETMQ-85
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-85
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 4.0.0-incubating
>Reporter: yukon
>Assignee: yukon
>Priority: Minor
> Fix For: 4.0.0-incubating
>
>
> Polish README file and remove all the 3rd party links in it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Work started] (ROCKETMQ-88) Polish the developer list in pom.xml

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on ROCKETMQ-88 started by yukon.
-
> Polish the developer list in pom.xml
> 
>
> Key: ROCKETMQ-88
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-88
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> As [~jmclean] mentioned:
> The pom lists a number of developers and GitHub links, this is unusual for an 
> Apache project.
> Consider remove the developer list or the GitHub links.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-88) Polish the developer list in pom.xml

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-88:
--
Fix Version/s: 4.1.0-incubating

> Polish the developer list in pom.xml
> 
>
> Key: ROCKETMQ-88
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-88
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> As [~jmclean] mentioned:
> The pom lists a number of developers and GitHub links, this is unusual for an 
> Apache project.
> Consider remove the developer list or the GitHub links.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-89) WS_DOMAIN_NAME, SUBGROUP default values overrides custom values passed by java options

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-89.
-

> WS_DOMAIN_NAME, SUBGROUP default values overrides custom values passed by 
> java options
> --
>
> Key: ROCKETMQ-89
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-89
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-broker
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-89) WS_DOMAIN_NAME, SUBGROUP default values overrides custom values passed by java options

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-89.
---
Resolution: Fixed

> WS_DOMAIN_NAME, SUBGROUP default values overrides custom values passed by 
> java options
> --
>
> Key: ROCKETMQ-89
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-89
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-broker
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-90) Include client IP per message queue of consumer progress command output

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976221#comment-15976221
 ] 

ASF GitHub Bot commented on ROCKETMQ-90:


Github user zhouxinyu commented on the issue:

https://github.com/apache/incubator-rocketmq/pull/56
  
@lizhanhui why did we close this PR without merge?


> Include client IP per message queue of consumer progress command output
> ---
>
> Key: ROCKETMQ-90
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-90
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-tools
>Affects Versions: 4.1.0-incubating
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
>
> Sometimes we monitor message accumulation which is not caused by traffic 
> surge, instead by buggy application consuming code. If we can quickly figure 
> out IP of which client(s) is experiencing  glitches, it saves much time 
> diagnosing issues.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-95) The config files of client log have been damaged

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-95.
-

> The config files of client log have been damaged
> 
>
> Key: ROCKETMQ-95
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-95
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Eric Liu
>Assignee: Eric Liu
>  Labels: easyfix
> Fix For: 4.1.0-incubating
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Config files:
> log4j_rocketmq_client.xml , logback_rocketmq_client.xml
> There is no log info printed at client, because config files are damaged, 
> such as:
> %properties, %defaultTopicQueueNums



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-102) When shutdown(), the persisted offet is not the latest consumed message, which may cause repeated messages

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-102:
---
Fix Version/s: 4.1.0-incubating

> When shutdown(), the persisted offet is not the latest consumed message, 
> which may cause repeated messages
> --
>
> Key: ROCKETMQ-102
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-102
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Jaskey Lam
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> When shutdown push consumer, push consumer will shutdwon thread pool then 
> persist offset.
> While shutdown thread pool is only stop submiting message to consume, which 
> does not stop consuming message which exists in the the thread queue or is 
> already being consumed.
> Which will cause repeated message very easily though user are shutdown 
> gracefully according to the provided interface.
> A way to solve this problem is needed. Such as accpet a param that how long 
> to wait for thread pool to terminated.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-103) Add startup scripts for the windows platform

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-103.
--
Resolution: Duplicate

> Add startup scripts for the windows platform
> 
>
> Key: ROCKETMQ-103
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-103
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-broker
>Reporter: Xiaorui Wang
>Assignee: yukon
>Priority: Minor
>
> Windows users is a very large user groups, especially in the trial product 
> user groups, it is necessary to increase the windows boot mode



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-107) Access ServiceState is not thread safe when start() or shutdown()

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-107.
--

> Access ServiceState is not thread safe when start() or shutdown()
> -
>
> Key: ROCKETMQ-107
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-107
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> When start() or shutdown(), service's state is not thread safe which may 
> break happen-before.
> For example: 
> {code}
> switch (this.serviceState) {
> case CREATE_JUST:
> log.info("the consumer [{}] start beginning. messageModel={}, 
> isUnitMode={}", this.defaultMQPushConsumer.getConsumerGroup(),
> this.defaultMQPushConsumer.getMessageModel(), 
> this.defaultMQPushConsumer.isUnitMode());
> this.serviceState = ServiceState.START_FAILED;
> ..// do some start job here
> this.serviceState = ServiceState.RUNNING;
> break;
> case RUNNING:
> case START_FAILED:
> case SHUTDOWN_ALREADY:
> throw new MQClientException("The PushConsumer service state 
> not OK, maybe started once, "//
> + this.serviceState//
> + FAQUrl.suggestTodo(FAQUrl.CLIENT_SERVICE_NOT_OK),
> null);
> default:
> break;
> }
> {code}
> 1. If the user is start twice in two thread, the resources may initize twice.
> 2. if the user start in threadA and shutdown very quicky in another thread B, 
> shutdown may not reclaim the resources.
> Though the sceniro is very uncommon, but it is indeed a bug here. Fix is 
> actually quite trivial.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-106) Add flow control on topic level

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-106:
---
Fix Version/s: 4.1.0-incubating

> Add flow control on topic level
> ---
>
> Key: ROCKETMQ-106
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-106
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
> Fix For: 4.1.0-incubating
>
>
> *Motivations*
> For current flow control, we can only control on queue level. 
> Howerver, the numbers of queue allocated may be dynamic changed. For example, 
> I might hope to control that at most 1000 messages can be pulled from broker 
> to protect my client. And I have no idea how many queue I am allocated. Maybe 
> I will have 5 queue and 5 instances so I set `pullThresholdForQueue`=1000, 
> which works as expected when one is fine. But as long as any instances 
> crashes, some instances may be allocated  more than one queue, which will 
> make messages pulled from broker exceed my expectations.
> A configuration of  `pullThresholdForTopic` is propably most user hopes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-107) Access ServiceState is not thread safe when start() or shutdown()

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-107.

Resolution: Fixed

> Access ServiceState is not thread safe when start() or shutdown()
> -
>
> Key: ROCKETMQ-107
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-107
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> When start() or shutdown(), service's state is not thread safe which may 
> break happen-before.
> For example: 
> {code}
> switch (this.serviceState) {
> case CREATE_JUST:
> log.info("the consumer [{}] start beginning. messageModel={}, 
> isUnitMode={}", this.defaultMQPushConsumer.getConsumerGroup(),
> this.defaultMQPushConsumer.getMessageModel(), 
> this.defaultMQPushConsumer.isUnitMode());
> this.serviceState = ServiceState.START_FAILED;
> ..// do some start job here
> this.serviceState = ServiceState.RUNNING;
> break;
> case RUNNING:
> case START_FAILED:
> case SHUTDOWN_ALREADY:
> throw new MQClientException("The PushConsumer service state 
> not OK, maybe started once, "//
> + this.serviceState//
> + FAQUrl.suggestTodo(FAQUrl.CLIENT_SERVICE_NOT_OK),
> null);
> default:
> break;
> }
> {code}
> 1. If the user is start twice in two thread, the resources may initize twice.
> 2. if the user start in threadA and shutdown very quicky in another thread B, 
> shutdown may not reclaim the resources.
> Though the sceniro is very uncommon, but it is indeed a bug here. Fix is 
> actually quite trivial.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-111) fix possible MQClientException when query message before today

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-111.
--

> fix possible MQClientException when query message before today
> --
>
> Key: ROCKETMQ-111
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-111
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-commons
>Affects Versions: 4.0.0-incubating
>Reporter: Yiling Feng
>Assignee: Jixiang Jin
>  Labels: build
> Fix For: 4.0.0-incubating
>
>
> Using "cal.set(Calendar.HOUR,0);" when query message before today which may 
> result in :
> "org.apache.rocketmq.client.exception.MQClientException: CODE: 208 DESC: 
> query message by key finished, but no message. "
> "HOUR" is used for the 12-hour clock.This will cause the start time of the 
> query message to be greater than the creation time of the message.
> Implemenations:
> Using "HOUR_OF_DAY" instead of "HOUR"."HOUR_OF_DAY" is used for the 24-hour 
> clock.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-114) Add javadoc to codebase

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-114:
---
Fix Version/s: 4.1.0-incubating

> Add javadoc to codebase
> ---
>
> Key: ROCKETMQ-114
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-114
> Project: Apache RocketMQ
>  Issue Type: Improvement
>Reporter: Zhanhui Li
>Assignee: vongosling
> Fix For: 4.1.0-incubating
>
>
> Quality documentation is critically important to develop and maintain a 
> project. The better the documentation is, the 
> easier it will be for other participants to understand and respond properly.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-117) add telnet port in NameServer , convenient for the user of mq to debug

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-117:
---
Fix Version/s: 4.1.0-incubating

> add telnet port in NameServer , convenient for the user of mq to debug 
> ---
>
> Key: ROCKETMQ-117
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-117
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-namesrv
>Reporter: zhaoziyan
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> add telnet port in NameServer . convenient for the user of mq
> to debug . Connection and Offset information 
> telnet Nameserver 9875 port
> for example telnet 192.168.186.131 9875
> Welcome . CMD for example
> consumerProgress -g zzHelloSubGroup
> consumerConnection -g zzHelloSubGroup
> producerConnection -t zzHello -g zzHelloSendGroup
> topicStatus -t zzHello
> topicStatus -t zzHello
> #Broker Name #QID #Min Offset #Max Offset #Last Updated
> broker-a 0 0 20 2017-03-03 16:19:36,904
> broker-a 1 0 19 2017-03-03 16:19:36,916
> broker-a 2 0 18 2017-03-03 16:00:37,802
> broker-a 3 0 18 2017-03-03 16:00:37,813



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-118) broker haServer ??

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-118.
--
Resolution: Won't Fix

> broker haServer ??
> --
>
> Key: ROCKETMQ-118
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-118
> Project: Apache RocketMQ
>  Issue Type: Wish
>Reporter: zhaoziyan
>Assignee: vongosling
>  Labels: features
>
> getHAServerAddr()
> String addr = this.brokerConfig.getBrokerIP2() + ":" + 
> this.messageStoreConfig.getHaListenPort();
> in nameServer some log like this ( in conf ,ip1=ip2=10.126.84.66)
> new broker registerd, 10.126.84.66:10911 HAServer: 10.126.84.66:10912
> the use of haServer 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-121) Support message filtering based on SQL92

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-121:
---
Fix Version/s: 4.1.0-incubating

> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-119) Shutdown PullMessageService properly

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-119.

Resolution: Fixed

> Shutdown PullMessageService properly
> 
>
> Key: ROCKETMQ-119
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-119
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ROCKETMQ-121) Support message filtering based on SQL92

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon reassigned ROCKETMQ-121:
--

Assignee: Eric Liu  (was: vongosling)

> Support message filtering based on SQL92
> 
>
> Key: ROCKETMQ-121
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-121
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client, rocketmq-store
>Reporter: yukon
>Assignee: Eric Liu
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> So far, RocketMQ only support message filtering feature by `TAG`, but one 
> message only can own one tag, this is too limited to meet complex business 
> requirements.
> So, we want to define and implement a reasonable filter language based on a 
> subset of the SQL 92 expression syntax to support customized message 
> filtering.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-126) Provide a docker image for RocketMQ

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-126:
---
Component/s: (was: build)
 rocketmq-externals

> Provide a docker image for RocketMQ
> ---
>
> Key: ROCKETMQ-126
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-126
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-externals
>Reporter: yukon
>Assignee: Rich Zhang
>Priority: Minor
>
> Provide a docker image for easy deployment and management, optimize for the 
> latest version.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-78) Prepare and place Dockerfile under incubator-rocketmq/

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-78:
--
Component/s: rocketmq-externals

> Prepare and place Dockerfile under incubator-rocketmq/
> --
>
> Key: ROCKETMQ-78
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-78
> Project: Apache RocketMQ
>  Issue Type: Task
>  Components: rocketmq-externals
>Reporter: Roman Shtykh
>Assignee: vongosling
>
> {{Dockerfile}} has to be placed under {{incubator-rocketmq/}}, probably in 
> {{docker}} directory.
> See 
> https://github.com/apache/ignite/tree/master/modules/docker
> https://github.com/apache/flink/tree/master/flink-contrib/docker-flink
> https://github.com/apache/hbase/tree/master/dev-support/docker



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-127) Provide a rocketmq-proxy to support MQTT protocol

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-127:
---
Fix Version/s: 4.2.0-incubating

> Provide a rocketmq-proxy to support MQTT protocol
> -
>
> Key: ROCKETMQ-127
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-127
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-externals
>Reporter: yukon
>Priority: Minor
> Fix For: 4.2.0-incubating
>
>
> MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity 
> protocol, which has been widely used in IoT. Support MQTT, give RocketMQ the 
> power to connect everything.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-128) Support HA switch automatically

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-128:
---
Fix Version/s: (was: 4.1.0-incubating)

> Support HA switch automatically
> ---
>
> Key: ROCKETMQ-128
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-128
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-broker
>Affects Versions: 4.0.0-incubating
>Reporter: Eason Chen
>Assignee: yukon
>
> Ha is an very important feature in production , when server crash, how to 
> keep continuity of business is the first job.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-134) The offset of message filter by tags may be not commit to broker

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-134:
---
Summary: The offset of message filter by tags may be not commit to broker  
(was: the offset of message filter by tags may be not commit to broker)

> The offset of message filter by tags may be not commit to broker
> 
>
> Key: ROCKETMQ-134
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-134
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Jie.Tang
>Assignee: Xiaorui Wang
>Priority: Trivial
> Fix For: 4.1.0-incubating
>
>
> when different string has a same hash code.the message commit offset of 
> filtered message may be not commit to broker.
> for example:
> 1.consumer pull message from broker, broker return status FOUND and messages 
> filter by tags hash code
> 2.consumer client get the messages and than processPullResult will filter 
> message by tags.
> 3.PullCallback may get a pullResult which status is FOUND but messageList is 
> empty.(filter by tags)
> but only NO_MATCHED_MSG and NO_NEW_MSG will correctTagsOffset
> we can't commit the right with status of FOUND(for messageList is empty).
> Is that so?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-134) the offset of message filter by tags may be not commit to broker

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-134:
---
Fix Version/s: 4.1.0-incubating

> the offset of message filter by tags may be not commit to broker
> 
>
> Key: ROCKETMQ-134
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-134
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: Jie.Tang
>Assignee: Xiaorui Wang
>Priority: Trivial
> Fix For: 4.1.0-incubating
>
>
> when different string has a same hash code.the message commit offset of 
> filtered message may be not commit to broker.
> for example:
> 1.consumer pull message from broker, broker return status FOUND and messages 
> filter by tags hash code
> 2.consumer client get the messages and than processPullResult will filter 
> message by tags.
> 3.PullCallback may get a pullResult which status is FOUND but messageList is 
> empty.(filter by tags)
> but only NO_MATCHED_MSG and NO_NEW_MSG will correctTagsOffset
> we can't commit the right with status of FOUND(for messageList is empty).
> Is that so?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (ROCKETMQ-135) Broker cannot be properly finalized on failure to load a storage plugin

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon reopened ROCKETMQ-135:


> Broker cannot be properly finalized on failure to load a storage plugin
> ---
>
> Key: ROCKETMQ-135
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-135
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-broker
>Affects Versions: 4.0.0-incubating
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.1.0-incubating
>
>
> When a storage plugin fails ( 
> {{org.apache.rocketmq.broker.plugin.MessageStoreFactory#build}} ), it 
> terminates the broker without proper finalization.
> This is because {{RuntimeException}} is thrown by the above-mentioned method 
> and it is never properly handled.
> I propose creating a {{BrokerException}}, throw it and properly handle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-136) Provide a handy message queue selector for order message sharding

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-136:
---
Fix Version/s: 4.2.0-incubating

> Provide a handy message queue selector for order message sharding
> -
>
> Key: ROCKETMQ-136
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-136
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.2.0-incubating
>
>
> When order message is needed, users need to provide a message queue selector 
> to make sure that the messages which has the same shading key should be sent 
> to the same message queue.
> Actually this is a very common scenario with a common solutions, say 
> consistent hashing.
> We should provide a handy selector for them to easily do that, what they only 
> need to provide is a sharding key.
> A consistent hash selector will meet most of the user's need.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-137) no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control

[yukon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976193#comment-15976193
 ] 

yukon commented on ROCKETMQ-137:


Hi [~easonchen], could you please pick this issue up if you don't mind.

> no longer pull message when clean expired message earlier than callback 
> return CONSUME_SUCCESS because of flow control
> --
>
> Key: ROCKETMQ-137
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-137
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: Eason Chen
>Assignee: Xiaorui Wang
> Fix For: 4.2.0-incubating
>
> Attachments: QQ截图20170309181223.png, QQ截图20170309181305.png
>
>
> no longer pull message when clean expired message earlier than callback 
> return CONSUME_SUCCESS because of flow control



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-137) no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-137:
---
Fix Version/s: 4.2.0-incubating

> no longer pull message when clean expired message earlier than callback 
> return CONSUME_SUCCESS because of flow control
> --
>
> Key: ROCKETMQ-137
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-137
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: Eason Chen
>Assignee: Xiaorui Wang
> Fix For: 4.2.0-incubating
>
> Attachments: QQ截图20170309181223.png, QQ截图20170309181305.png
>
>
> no longer pull message when clean expired message earlier than callback 
> return CONSUME_SUCCESS because of flow control



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-138) Add AuthenticationException class to remove hard coded Aliyun authentication class

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-138.

Resolution: Fixed

> Add AuthenticationException class to remove hard coded Aliyun authentication 
> class
> --
>
> Key: ROCKETMQ-138
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-138
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-remoting
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> in NettyRemotingAbstract.java
> a hard coded aliyun class is used 
> {code}
> catch (Throwable e) {
> if 
> (!"com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException"
> .equals(e.getClass().getCanonicalName())) {
> PLOG.error("process request exception", e);
> PLOG.error(cmd.toString());
> }
> {code}
> A common AuthenticationException should be added to identify Authentication 
> failure.  Developers can throw this exception so that remoting component can 
> ignore it



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-138) Add AuthenticationException class to remove hard coded Aliyun authentication class

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-138.
--

> Add AuthenticationException class to remove hard coded Aliyun authentication 
> class
> --
>
> Key: ROCKETMQ-138
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-138
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-remoting
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> in NettyRemotingAbstract.java
> a hard coded aliyun class is used 
> {code}
> catch (Throwable e) {
> if 
> (!"com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException"
> .equals(e.getClass().getCanonicalName())) {
> PLOG.error("process request exception", e);
> PLOG.error(cmd.toString());
> }
> {code}
> A common AuthenticationException should be added to identify Authentication 
> failure.  Developers can throw this exception so that remoting component can 
> ignore it



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-138) Add AuthenticationException class to remove hard coded Aliyun authentication class

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-138:
---
Fix Version/s: 4.1.0-incubating

> Add AuthenticationException class to remove hard coded Aliyun authentication 
> class
> --
>
> Key: ROCKETMQ-138
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-138
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-remoting
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> in NettyRemotingAbstract.java
> a hard coded aliyun class is used 
> {code}
> catch (Throwable e) {
> if 
> (!"com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException"
> .equals(e.getClass().getCanonicalName())) {
> PLOG.error("process request exception", e);
> PLOG.error(cmd.toString());
> }
> {code}
> A common AuthenticationException should be added to identify Authentication 
> failure.  Developers can throw this exception so that remoting component can 
> ignore it



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-139) Degrade the client related modules' JDK version to 1.6

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-139.
--

> Degrade the client related modules' JDK version to 1.6
> --
>
> Key: ROCKETMQ-139
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-139
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client, rocketmq-commons, rocketmq-remoting
>Affects Versions: 4.0.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> Recently, some customers report that their applications require JDK1.6, so 
> rollback to JDK 1.6 in client related modules to maintain compatibility.
> Client related modules: client, common, remoting.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-140) Register higher version broker against old name servers

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-140.
--

> Register higher version broker against old name servers
> ---
>
> Key: ROCKETMQ-140
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-140
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-namesrv
>Affects Versions: 4.1.0-incubating
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> When register higher version brokers again old name servers, 
> IndexOutOfBoundaryException may be thrown, causing registration failure.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-139) Degrade the client related modules' JDK version to 1.6

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-139.

Resolution: Fixed

> Degrade the client related modules' JDK version to 1.6
> --
>
> Key: ROCKETMQ-139
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-139
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client, rocketmq-commons, rocketmq-remoting
>Affects Versions: 4.0.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> Recently, some customers report that their applications require JDK1.6, so 
> rollback to JDK 1.6 in client related modules to maintain compatibility.
> Client related modules: client, common, remoting.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-141) Make producers establish connection eagerly to new joined brokers

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-141:
---
Fix Version/s: 4.1.0-incubating

> Make producers establish connection eagerly to new joined brokers
> -
>
> Key: ROCKETMQ-141
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-141
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Affects Versions: 4.1.0-incubating
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
> Fix For: 4.1.0-incubating
>
>
> When new brokers joins the cluster, MQ producer clients polls name server and 
> add the new-joined brokers to topicPublishInfo in case the new-joined broker 
> bears the topic. Later on, the producers may send messages to the new-joined 
> brokers.
> This achieves part of scalable goals and works fine for most cases. However, 
> we ran an issue in this process. The problem is when new broker joins the 
> cluster, the producer clients blocks for quite a while even if when 
> asynchronous send method is employed, which is very miserable for latency 
> sensitive scenarios.  
> After analyzing the root cause, it turns out that producer clients need to 
> establish a connection to the new-joined brokers the first time it sends a 
> message, as is blocking. 
> This issue is to establish a connection to new-joined brokers immediately 
> after polling name server and make them available to send methods thereafter. 
> Thus, when send is called against new-joined brokers, there is a writable 
> channel readily available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-140) Register higher version broker against old name servers

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-140:
---
Fix Version/s: 4.1.0-incubating

> Register higher version broker against old name servers
> ---
>
> Key: ROCKETMQ-140
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-140
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-namesrv
>Affects Versions: 4.1.0-incubating
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> When register higher version brokers again old name servers, 
> IndexOutOfBoundaryException may be thrown, causing registration failure.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-142) benchmark test store log warn "found a illegal magic code 0x0" . The message have any meaning ?? What does it stand for ??

[yukon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976189#comment-15976189
 ] 

yukon commented on ROCKETMQ-142:


May be your commit log has been damaged.

> benchmark test store  log warn "found a illegal magic code 0x0" . The message 
> have any meaning ?? What does it stand for ??
> ---
>
> Key: ROCKETMQ-142
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-142
> Project: Apache RocketMQ
>  Issue Type: Test
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating, 4.1.0-incubating
>Reporter: zhaoziyan
>Assignee: yukon
>
> ./store.log:2017-03-13 20:00:49 WARN main - found a illegal magic code 0x0
> ./store.log:2017-03-13 20:06:53 WARN main - found a illegal magic code 0x0
> Here is the code 
>  public DispatchRequest checkMessageAndReturnSize(java.nio.ByteBuffer 
> byteBuffer, final boolean checkCRC, final boolean readBody) {
> try {
> // 1 TOTAL SIZE
> int totalSize = byteBuffer.getInt();
> // 2 MAGIC CODE
> int magicCode = byteBuffer.getInt();
> switch (magicCode) {
> case MESSAGE_MAGIC_CODE:
> break;
> case BLANK_MAGIC_CODE:
> return new DispatchRequest(0, true /* success */);
> default:
> log.warn("found a illegal magic code 0x" + 
> Integer.toHexString(magicCode));
> return new DispatchRequest(-1, false /* success */);
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-144) Aggregate distribution specific files to a new module

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-144.
--

> Aggregate distribution specific files to a new module
> -
>
> Key: ROCKETMQ-144
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-144
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
> Fix For: 4.1.0-incubating
>
>
> When running maven-assembly-plugin, it constantly warns and suggests to use a 
> separate sub-module to aggregate packaging files, which are scattered in the 
> parent projects. Usage of this is exemplified 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-142) benchmark test store log warn "found a illegal magic code 0x0" . The message have any meaning ?? What does it stand for ??

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-142.
--
Resolution: Won't Fix

> benchmark test store  log warn "found a illegal magic code 0x0" . The message 
> have any meaning ?? What does it stand for ??
> ---
>
> Key: ROCKETMQ-142
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-142
> Project: Apache RocketMQ
>  Issue Type: Test
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating, 4.1.0-incubating
>Reporter: zhaoziyan
>Assignee: yukon
>
> ./store.log:2017-03-13 20:00:49 WARN main - found a illegal magic code 0x0
> ./store.log:2017-03-13 20:06:53 WARN main - found a illegal magic code 0x0
> Here is the code 
>  public DispatchRequest checkMessageAndReturnSize(java.nio.ByteBuffer 
> byteBuffer, final boolean checkCRC, final boolean readBody) {
> try {
> // 1 TOTAL SIZE
> int totalSize = byteBuffer.getInt();
> // 2 MAGIC CODE
> int magicCode = byteBuffer.getInt();
> switch (magicCode) {
> case MESSAGE_MAGIC_CODE:
> break;
> case BLANK_MAGIC_CODE:
> return new DispatchRequest(0, true /* success */);
> default:
> log.warn("found a illegal magic code 0x" + 
> Integer.toHexString(magicCode));
> return new DispatchRequest(-1, false /* success */);
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-144) Aggregate distribution specific files to a new module

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-144.

Resolution: Fixed

> Aggregate distribution specific files to a new module
> -
>
> Key: ROCKETMQ-144
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-144
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
> Fix For: 4.1.0-incubating
>
>
> When running maven-assembly-plugin, it constantly warns and suggests to use a 
> separate sub-module to aggregate packaging files, which are scattered in the 
> parent projects. Usage of this is exemplified 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-144) Aggregate distribution specific files to a new module

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-144:
---
Component/s: build

> Aggregate distribution specific files to a new module
> -
>
> Key: ROCKETMQ-144
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-144
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
> Fix For: 4.1.0-incubating
>
>
> When running maven-assembly-plugin, it constantly warns and suggests to use a 
> separate sub-module to aggregate packaging files, which are scattered in the 
> parent projects. Usage of this is exemplified 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-144) Aggregate distribution specific files to a new module

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-144:
---
Fix Version/s: 4.1.0-incubating

> Aggregate distribution specific files to a new module
> -
>
> Key: ROCKETMQ-144
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-144
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: build
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
> Fix For: 4.1.0-incubating
>
>
> When running maven-assembly-plugin, it constantly warns and suggests to use a 
> separate sub-module to aggregate packaging files, which are scattered in the 
> parent projects. Usage of this is exemplified 
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-148.

Resolution: Fixed

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-147) Support usrname+passwd authentication and ip+topic certification

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-147:
---
Fix Version/s: 4.2.0-incubating

> Support usrname+passwd authentication and ip+topic certification 
> -
>
> Key: ROCKETMQ-147
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-147
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-broker
>Reporter: Eason Chen
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> It will be very helpfull if support usrname+passwd authentication and 
> ip+topic certification in production



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-148.
--

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-146) Hit "port out of range:" in decodeMessageId happens sometimes

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-146:
---
Fix Version/s: 4.2.0-incubating

> Hit "port out of range:" in decodeMessageId happens sometimes
> -
>
> Key: ROCKETMQ-146
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-146
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client, rocketmq-commons
>Reporter: Eason Chen
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
> Attachments: {A99BE06A-745B-4FA8-859D-EFB6FB18E851}.png
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-148.
--

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon reopened ROCKETMQ-148:


> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-148.

Resolution: Fixed

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-148:
---
Labels: docuentation  (was: )

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>  Labels: docuentation
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-148:
---
Summary: Migrate all relevant docs from the old Github project's wiki to 
the ASF site  (was: Please migrate all relevant docs from the old Github 
project's wiki to the ASF site)

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-148) Migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-148:
---
Fix Version/s: 4.1.0-incubating

> Migrate all relevant docs from the old Github project's wiki to the ASF site
> 
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ROCKETMQ-148) Please migrate all relevant docs from the old Github project's wiki to the ASF site

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon reassigned ROCKETMQ-148:
--

Assignee: yukon  (was: vongosling)

> Please migrate all relevant docs from the old Github project's wiki to the 
> ASF site
> ---
>
> Key: ROCKETMQ-148
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-148
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Bruce Snyder
>Assignee: yukon
>
> There still seems to be links from the new ASF site to docs that reside in 
> the old Github project's wiki. Any relevant documents that still exist on the 
> old Github wiki need to be migrated to the new ASF site. Below are some 
> examples:
> * See the [Team page|http://rocketmq.incubator.apache.org/about/team/] and 
> the link to the Contributing document that still resides on the old Github 
> project's wiki
> * See the [Motivation 
> page|http://rocketmq.incubator.apache.org/docs/motivation/] that links to the 
> how_to_support_more_queues doc on the old Github wiki
> * See the [CLI Admin Tool 
> page|http://rocketmq.incubator.apache.org/docs/cli-admin-tool/] that links to 
> the rocketmq-tools module that throws a 404
> There could very well be other pages that need the same treatment, so please 
> do not consider the list above to be comprehensive.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-150) Support both OuterIP and InnerIP

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-150:
---
Fix Version/s: 4.2.0-incubating

> Support both OuterIP and InnerIP
> 
>
> Key: ROCKETMQ-150
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-150
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-broker
>Reporter: Eason Chen
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> client connect to outer ip
> broker listen on innerip
> how to connect them is a problem



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-151) Support one slave map to two master

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-151:
---
Fix Version/s: 4.2.0-incubating

> Support one slave map to two master
> ---
>
> Key: ROCKETMQ-151
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-151
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-broker
>Reporter: Eason Chen
>Assignee: vongosling
> Fix For: 4.2.0-incubating
>
>
> since slave can not be used 100% ,but we do need it to backup message, it is 
> big waste to have so many slaves, so if it can let one slave map to two or 
> more master 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-151) Support one slave map to two master

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-151:
---
Component/s: rocketmq-broker

> Support one slave map to two master
> ---
>
> Key: ROCKETMQ-151
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-151
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-broker
>Reporter: Eason Chen
>Assignee: vongosling
> Fix For: 4.2.0-incubating
>
>
> since slave can not be used 100% ,but we do need it to backup message, it is 
> big waste to have so many slaves, so if it can let one slave map to two or 
> more master 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ROCKETMQ-152) lockForPutMessage CAS may cause system load very high and putMessage cost more than 500ms if the sendMessageThread num is very much

[yukon (JIRA)]

[ 
https://issues.apache.org/jira/browse/ROCKETMQ-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15976178#comment-15976178
 ] 

yukon commented on ROCKETMQ-152:


If you set a large sendMessageThreadPoolNums, please use ReentrantLock instead 
of spin lock.

> lockForPutMessage CAS  may cause  system load very high and putMessage cost 
> more than 500ms if the sendMessageThread num is very much 
> --
>
> Key: ROCKETMQ-152
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-152
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: sendMessageThreadPoolNums=128 and 
> JDK jdk1.7.0_80 linux 2.6.32-504.el6.x86_64 and  have more than 50 g free
> mem 
>Reporter: zhaoziyan
>Assignee: yukon
> Attachments: QQ截图20170322152327.png
>
>
> broker store  sendMessageThreadPoolNums=128
> 16 thread 1000bytes benchmark test ， System load to 100
> put message acquire the lock may spin，cause System load high and putMessage 
> cost more than 500ms
> /**
>  * Spin util acquired the lock.
>  */
> private void lockForPutMessage() {
> if 
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
>  {
> putMessageNormalLock.lock();
> } else {
> boolean flag;
> do {
> flag = this.putMessageSpinLock.compareAndSet(true, false);
> }
> while (!flag);
> }
> }
> 2017-03-22 14:40:16 WARN SendMessageThread_101 - putMessage not in lock 
> eclipse time(ms)=1030, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_34 - putMessage not in lock 
> eclipse time(ms)=1932, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_3 - putMessage not in lock eclipse 
> time(ms)=581, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_57 - putMessage not in lock 
> eclipse time(ms)=583, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_123 - putMessage not in lock 
> eclipse time(ms)=2225, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_1 - putMessage not in lock eclipse 
> time(ms)=1642, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_58 - putMessage not in lock 
> eclipse time(ms)=587, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_19 - putMessage not in lock 
> eclipse time(ms)=1369, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_32 - putMessage not in lock 
> eclipse time(ms)=1896, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_2 - putMessage not in lock eclipse 
> time(ms)=1018, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_122 - putMessage not in lock 
> eclipse time(ms)=657, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_120 - putMessage not in lock 
> eclipse time(ms)=592, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_88 - putMessage not in lock 
> eclipse time(ms)=559, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_44 - putMessage not in lock 
> eclipse time(ms)=892, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_79 - putMessage not in lock 
> eclipse time(ms)=699, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_84 - putMessage not in lock 
> eclipse time(ms)=616, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_112 - putMessage not in lock 
> eclipse time(ms)=515, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_59 - putMessage not in lock 
> eclipse time(ms)=1301, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_96 - putMessage not in lock 
> eclipse time(ms)=635, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_90 - lockForPutMessage 
> cost:317
> 2017-03-22 14:40:16 WARN SendMessageThread_10 - lockForPutMessage 
> cost:447
> 2017-03-22 14:40:16 WARN SendMessageThread_62 - lockForPutMessage 
> cost:450
> 2017-03-22 14:40:16 WARN SendMessageThread_93 - lockForPutMessage 
> cost:131
> 2017-03-22 14:40:16 WARN SendMessageThread_8 - lockForPutMessage 
> cost:171
> 2017-03-22 14:40:16 WARN SendMessageThread_93 - lockForPutMessage 
> cost:4
> 2017-03-22 14:40:16 WARN SendMessageThread_105 - lockForPutMessage 
> cost:666
> 2017-03-22 14:40:16 WARN SendMessageThread_127 - lockForPutMessage 
> cost:689
> 2017-03-22 14:40:16 WARN SendMessageThread_30 - lockForPutMessage 
> cost:341
> 2017-03-22 14:40:16 WARN SendMessageThread_70 - lockForPutMessage 
> cost:317
> 2017-03-22 14:40:16 WARN SendMessageThread_92 - lockForPutMessage 
> cost:58
> 2017-03-22 14:40:16 WARN SendMessageThread_63 - 

[jira] [Closed] (ROCKETMQ-152) lockForPutMessage CAS may cause system load very high and putMessage cost more than 500ms if the sendMessageThread num is very much

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-152.
--
Resolution: Won't Fix

> lockForPutMessage CAS  may cause  system load very high and putMessage cost 
> more than 500ms if the sendMessageThread num is very much 
> --
>
> Key: ROCKETMQ-152
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-152
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: sendMessageThreadPoolNums=128 and 
> JDK jdk1.7.0_80 linux 2.6.32-504.el6.x86_64 and  have more than 50 g free
> mem 
>Reporter: zhaoziyan
>Assignee: yukon
> Attachments: QQ截图20170322152327.png
>
>
> broker store  sendMessageThreadPoolNums=128
> 16 thread 1000bytes benchmark test ， System load to 100
> put message acquire the lock may spin，cause System load high and putMessage 
> cost more than 500ms
> /**
>  * Spin util acquired the lock.
>  */
> private void lockForPutMessage() {
> if 
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
>  {
> putMessageNormalLock.lock();
> } else {
> boolean flag;
> do {
> flag = this.putMessageSpinLock.compareAndSet(true, false);
> }
> while (!flag);
> }
> }
> 2017-03-22 14:40:16 WARN SendMessageThread_101 - putMessage not in lock 
> eclipse time(ms)=1030, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_34 - putMessage not in lock 
> eclipse time(ms)=1932, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_3 - putMessage not in lock eclipse 
> time(ms)=581, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_57 - putMessage not in lock 
> eclipse time(ms)=583, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_123 - putMessage not in lock 
> eclipse time(ms)=2225, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_1 - putMessage not in lock eclipse 
> time(ms)=1642, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_58 - putMessage not in lock 
> eclipse time(ms)=587, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_19 - putMessage not in lock 
> eclipse time(ms)=1369, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_32 - putMessage not in lock 
> eclipse time(ms)=1896, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_2 - putMessage not in lock eclipse 
> time(ms)=1018, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_122 - putMessage not in lock 
> eclipse time(ms)=657, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_120 - putMessage not in lock 
> eclipse time(ms)=592, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_88 - putMessage not in lock 
> eclipse time(ms)=559, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_44 - putMessage not in lock 
> eclipse time(ms)=892, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_79 - putMessage not in lock 
> eclipse time(ms)=699, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_84 - putMessage not in lock 
> eclipse time(ms)=616, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_112 - putMessage not in lock 
> eclipse time(ms)=515, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_59 - putMessage not in lock 
> eclipse time(ms)=1301, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_96 - putMessage not in lock 
> eclipse time(ms)=635, bodyLength=10013
> 2017-03-22 14:40:16 WARN SendMessageThread_90 - lockForPutMessage 
> cost:317
> 2017-03-22 14:40:16 WARN SendMessageThread_10 - lockForPutMessage 
> cost:447
> 2017-03-22 14:40:16 WARN SendMessageThread_62 - lockForPutMessage 
> cost:450
> 2017-03-22 14:40:16 WARN SendMessageThread_93 - lockForPutMessage 
> cost:131
> 2017-03-22 14:40:16 WARN SendMessageThread_8 - lockForPutMessage 
> cost:171
> 2017-03-22 14:40:16 WARN SendMessageThread_93 - lockForPutMessage 
> cost:4
> 2017-03-22 14:40:16 WARN SendMessageThread_105 - lockForPutMessage 
> cost:666
> 2017-03-22 14:40:16 WARN SendMessageThread_127 - lockForPutMessage 
> cost:689
> 2017-03-22 14:40:16 WARN SendMessageThread_30 - lockForPutMessage 
> cost:341
> 2017-03-22 14:40:16 WARN SendMessageThread_70 - lockForPutMessage 
> cost:317
> 2017-03-22 14:40:16 WARN SendMessageThread_92 - lockForPutMessage 
> cost:58
> 2017-03-22 14:40:16 WARN SendMessageThread_63 - lockForPutMessage 
> cost:261
> 2017-03-22 14:40:16 WARN SendMessageThread_98 - lockForPutMessage 

[jira] [Resolved] (ROCKETMQ-153) Fetch name server address dynamically

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon resolved ROCKETMQ-153.

Resolution: Fixed

> Fetch name server address dynamically
> -
>
> Key: ROCKETMQ-153
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-153
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> The client can't fetch the name server address dynamically from now, because 
> of the wrong initialization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-153) Fetch name server address dynamically

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-153.
--

> Fetch name server address dynamically
> -
>
> Key: ROCKETMQ-153
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-153
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: yukon
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> The client can't fetch the name server address dynamically from now, because 
> of the wrong initialization.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-154) Add a newline after help info

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-154.
--

> Add a newline after help info
> -
>
> Key: ROCKETMQ-154
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-154
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-tools
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> This is a very minor change. After execute command sh mqadmin, I get the last 
> line info:
> See {code}'mqadmin help ' for more information on a specific 
> command.[xinwang@hadoop bin]${code}
> Maybe we can improve this by adding a newline.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-155) Fix typo in ClientConfig

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-155:
---
Fix Version/s: 4.1.0-incubating

> Fix typo in ClientConfig
> 
>
> Key: ROCKETMQ-155
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-155
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> rename pollNameServerInteval to pollNameServerInterval



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-154) Add a newline after help info

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-154:
---
Summary: Add a newline after help info  (was: add a newline after help info)

> Add a newline after help info
> -
>
> Key: ROCKETMQ-154
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-154
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-tools
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> This is a very minor change. After execute command sh mqadmin, I get the last 
> line info:
> See {code}'mqadmin help ' for more information on a specific 
> command.[xinwang@hadoop bin]${code}
> Maybe we can improve this by adding a newline.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-155) Fix typo in ClientConfig

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-155.
--

> Fix typo in ClientConfig
> 
>
> Key: ROCKETMQ-155
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-155
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> rename pollNameServerInteval to pollNameServerInterval



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-155) Fix typo in ClientConfig

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-155:
---
Summary: Fix typo in ClientConfig  (was: fix typo in ClientConfig)

> Fix typo in ClientConfig
> 
>
> Key: ROCKETMQ-155
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-155
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> rename pollNameServerInteval to pollNameServerInterval



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-154) add a newline after help info

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-154:
---
Fix Version/s: 4.1.0-incubating

> add a newline after help info
> -
>
> Key: ROCKETMQ-154
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-154
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-tools
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> This is a very minor change. After execute command sh mqadmin, I get the last 
> line info:
> See {code}'mqadmin help ' for more information on a specific 
> command.[xinwang@hadoop bin]${code}
> Maybe we can improve this by adding a newline.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-158) Remove logback dependency for rocketmq-tools

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-158:
---
Fix Version/s: 4.1.0-incubating

> Remove logback dependency for rocketmq-tools
> 
>
> Key: ROCKETMQ-158
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-158
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-tools
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> Since user may need to use some admin interfaces to maintain something like 
> create topic, manage queues.
> They will need to use rocketmq-tools which contains DefaultMQAdminExt.
> But rocketmq-tools has explicitly depend on logback-classic and logback-core, 
> which may be conflict with the logging framework of the user's application.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-159) same group Consumers can create much instance on one Process

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-159.
--
Resolution: Won't Fix

> same group Consumers can create much instance on one Process
> 
>
> Key: ROCKETMQ-159
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-159
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: zhangyuan
>Assignee: Xiaorui Wang
>
> ordely or one thread Concurrently Consumer can be create many instance in one 
> Process;
> or Consumer can one queue bind one thread model ,to enhance concurrent 
> performance



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-160) SendHeartBeart log may not be triggered in the same expected period

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-160:
---
Fix Version/s: 4.1.0-incubating

> SendHeartBeart log may not be triggered in the same expected period
> ---
>
> Key: ROCKETMQ-160
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-160
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> {code}
> private void sendHeartbeatToAllBroker() {
> final HeartbeatData heartbeatData = this.prepareHeartbeatData();
> final boolean producerEmpty = 
> heartbeatData.getProducerDataSet().isEmpty();
> final boolean consumerEmpty = 
> heartbeatData.getConsumerDataSet().isEmpty();
> if (producerEmpty && consumerEmpty) {
> log.warn("sending heartbeat, but no consumer and no producer");
> return;
> }
> long times = this.storeTimesTotal.getAndIncrement();//here every time 
> when the method is call, the times will increase even though acatully no 
> heartbeat is sent
> Iterator>> it = 
> this.brokerAddrTable.entrySet().iterator();
> while (it.hasNext()) {
> Entry> entry = it.next();
> String brokerName = entry.getKey();
> HashMap oneTable = entry.getValue();
> if (oneTable != null) {
> for (Map.Entry entry1 : oneTable.entrySet()) {
> Long id = entry1.getKey();
> String addr = entry1.getValue();
> if (addr != null) {
> if (consumerEmpty) {
> if (id != MixAll.MASTER_ID)
> continue;
> }
> try {
> this.mQClientAPIImpl.sendHearbeat(addr, 
> heartbeatData, 3000);
> if (times % 20 == 0) {//since the first call is 
> times !=1, the heart beat log for the first heart beat could be missed
> log.info("send heart beat to broker[{} {} {}] 
> success", brokerName, id, addr);
> log.info(heartbeatData.toString());
> }
> } catch (Exception e) {
> if (this.isBrokerInNameServer(addr)) {
> log.error("send heart beat to broker 
> exception", e);
> } else {
> log.info("send heart beat to broker[{} {} {}] 
> exception, because the broker not up, forget it", brokerName,
> id, addr);
> }
> }
> }
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-161) Update runbroker.sh and runserver.sh to support user defined jvm memory flag

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-161:
---
Fix Version/s: 4.1.0-incubating

> Update runbroker.sh and runserver.sh to support user defined jvm memory flag
> 
>
> Key: ROCKETMQ-161
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-161
> Project: Apache RocketMQ
>  Issue Type: Improvement
>Reporter: dongeforever
>Assignee: dongeforever
> Fix For: 4.1.0-incubating
>
>
> JVM mem flag is hard coded in runbroker.sh as follows:
> JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g"
> If one want to change such flag, he has to change the script, this is not 
> friendly, especially in docker environment.
> Instead, it is able to use an environment variable to handle user defined 
> flag, like:
> if [ -z $BROKER_MEM_OPS ]; then
> BROKER_MEM_OPS =  "-Xms8g -Xmx8g -Xmn4g"
> fi 
> JAVA_OPT="${JAVA_OPT} -server $BROKER_MEM_OPS"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-162) Fix wrong link in site post

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-162.
--

> Fix wrong link in site post
> ---
>
> Key: ROCKETMQ-162
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-162
> Project: Apache RocketMQ
>  Issue Type: Bug
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>
>  RocketMQ Beam Repository in page[1] should be linked to 
> https://github.com/rocketmq/rocketmq-beam
> [1] 
> https://rocketmq.incubator.apache.org/activity/launch-rocketmq-code-marathon/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-163) DefaultMQPullConsumer.java批量拉取消息最大只能拉800个

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-163.
--
Resolution: Won't Fix

> DefaultMQPullConsumer.java批量拉取消息最大只能拉800个
> -
>
> Key: ROCKETMQ-163
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-163
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: linux
>Reporter: 郭中奇
>Assignee: yukon
>
> {code}
>  final int MaxFilterMessageCount = 16000;
> final boolean diskFallRecorded = this.messageStoreConfig.isDiskFallRecorded();
> for (; i < bufferConsumeQueue.getSize() && i < MaxFilterMessageCount; i += 
> ConsumeQueue.CQStoreUnitSize) {
>   long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
>   int sizePy = bufferConsumeQueue.getByteBuffer().getInt();
>   long tagsCode = bufferConsumeQueue.getByteBuffer().getLong();
>   maxPhyOffsetPulling = offsetPy;
>   if (nextPhyFileStartOffset != Long.MIN_VALUE) {
> if (offsetPy < nextPhyFileStartOffset)
> continue;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-163) DefaultMQPullConsumer.java批量拉取消息最大只能拉800个

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-163:
---
Fix Version/s: (was: 4.1.0-incubating)

> DefaultMQPullConsumer.java批量拉取消息最大只能拉800个
> -
>
> Key: ROCKETMQ-163
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-163
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: linux
>Reporter: 郭中奇
>Assignee: yukon
>
> {code}
>  final int MaxFilterMessageCount = 16000;
> final boolean diskFallRecorded = this.messageStoreConfig.isDiskFallRecorded();
> for (; i < bufferConsumeQueue.getSize() && i < MaxFilterMessageCount; i += 
> ConsumeQueue.CQStoreUnitSize) {
>   long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
>   int sizePy = bufferConsumeQueue.getByteBuffer().getInt();
>   long tagsCode = bufferConsumeQueue.getByteBuffer().getLong();
>   maxPhyOffsetPulling = offsetPy;
>   if (nextPhyFileStartOffset != Long.MIN_VALUE) {
> if (offsetPy < nextPhyFileStartOffset)
> continue;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-163) DefaultMQPullConsumer.java批量拉取消息最大只能拉800个

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-163:
---
Description: 
{code}
 final int MaxFilterMessageCount = 16000;
final boolean diskFallRecorded = this.messageStoreConfig.isDiskFallRecorded();
for (; i < bufferConsumeQueue.getSize() && i < MaxFilterMessageCount; i += 
ConsumeQueue.CQStoreUnitSize) {
  long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
  int sizePy = bufferConsumeQueue.getByteBuffer().getInt();
  long tagsCode = bufferConsumeQueue.getByteBuffer().getLong();

  maxPhyOffsetPulling = offsetPy;

  if (nextPhyFileStartOffset != Long.MIN_VALUE) {
if (offsetPy < nextPhyFileStartOffset)
continue;
  }
{code}

  was:
{code}
 final int MaxFilterMessageCount = 16000;
final boolean diskFallRecorded = 
this.messageStoreConfig.isDiskFallRecorded();
for (; i < bufferConsumeQueue.getSize() && i < 
MaxFilterMessageCount; i += ConsumeQueue.CQStoreUnitSize) {
long offsetPy = 
bufferConsumeQueue.getByteBuffer().getLong();
int sizePy = 
bufferConsumeQueue.getByteBuffer().getInt();
long tagsCode = 
bufferConsumeQueue.getByteBuffer().getLong();

maxPhyOffsetPulling = offsetPy;


if (nextPhyFileStartOffset != Long.MIN_VALUE) {
if (offsetPy < nextPhyFileStartOffset)
continue;
}
{code}


> DefaultMQPullConsumer.java批量拉取消息最大只能拉800个
> -
>
> Key: ROCKETMQ-163
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-163
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: linux
>Reporter: 郭中奇
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> {code}
>  final int MaxFilterMessageCount = 16000;
> final boolean diskFallRecorded = this.messageStoreConfig.isDiskFallRecorded();
> for (; i < bufferConsumeQueue.getSize() && i < MaxFilterMessageCount; i += 
> ConsumeQueue.CQStoreUnitSize) {
>   long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
>   int sizePy = bufferConsumeQueue.getByteBuffer().getInt();
>   long tagsCode = bufferConsumeQueue.getByteBuffer().getLong();
>   maxPhyOffsetPulling = offsetPy;
>   if (nextPhyFileStartOffset != Long.MIN_VALUE) {
> if (offsetPy < nextPhyFileStartOffset)
> continue;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-163) DefaultMQPullConsumer.java批量拉取消息最大只能拉800个

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-163:
---
Description: 
{code}
 final int MaxFilterMessageCount = 16000;
final boolean diskFallRecorded = 
this.messageStoreConfig.isDiskFallRecorded();
for (; i < bufferConsumeQueue.getSize() && i < 
MaxFilterMessageCount; i += ConsumeQueue.CQStoreUnitSize) {
long offsetPy = 
bufferConsumeQueue.getByteBuffer().getLong();
int sizePy = 
bufferConsumeQueue.getByteBuffer().getInt();
long tagsCode = 
bufferConsumeQueue.getByteBuffer().getLong();

maxPhyOffsetPulling = offsetPy;


if (nextPhyFileStartOffset != Long.MIN_VALUE) {
if (offsetPy < nextPhyFileStartOffset)
continue;
}
{code}

  was:
 final int MaxFilterMessageCount = 16000;
final boolean diskFallRecorded = 
this.messageStoreConfig.isDiskFallRecorded();
for (; i < bufferConsumeQueue.getSize() && i < 
MaxFilterMessageCount; i += ConsumeQueue.CQStoreUnitSize) {
long offsetPy = 
bufferConsumeQueue.getByteBuffer().getLong();
int sizePy = 
bufferConsumeQueue.getByteBuffer().getInt();
long tagsCode = 
bufferConsumeQueue.getByteBuffer().getLong();

maxPhyOffsetPulling = offsetPy;


if (nextPhyFileStartOffset != Long.MIN_VALUE) {
if (offsetPy < nextPhyFileStartOffset)
continue;
}


> DefaultMQPullConsumer.java批量拉取消息最大只能拉800个
> -
>
> Key: ROCKETMQ-163
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-163
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
> Environment: linux
>Reporter: 郭中奇
>Assignee: yukon
> Fix For: 4.1.0-incubating
>
>
> {code}
>  final int MaxFilterMessageCount = 16000;
> final boolean diskFallRecorded = 
> this.messageStoreConfig.isDiskFallRecorded();
> for (; i < bufferConsumeQueue.getSize() && i < 
> MaxFilterMessageCount; i += ConsumeQueue.CQStoreUnitSize) {
> long offsetPy = 
> bufferConsumeQueue.getByteBuffer().getLong();
> int sizePy = 
> bufferConsumeQueue.getByteBuffer().getInt();
> long tagsCode = 
> bufferConsumeQueue.getByteBuffer().getLong();
> maxPhyOffsetPulling = offsetPy;
> if (nextPhyFileStartOffset != Long.MIN_VALUE) {
> if (offsetPy < nextPhyFileStartOffset)
> continue;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-164) findMappedFileByOffset failure, ArrayIndexOutOfBoundsException: -143

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-164:
---
Fix Version/s: 4.2.0-incubating

> findMappedFileByOffset failure, ArrayIndexOutOfBoundsException: -143
> 
>
> Key: ROCKETMQ-164
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-164
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
>Reporter: Eason Chen
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> we use sync_master and slave, when slave left behind from master too long and 
> then hit this exception when restart again maybe because comitlog has been 
> deleted.
> wo suggest handle this exception.   
> 2017-03-24 09:55:25 WARN PullMessageThread_4 - findMappedFileByOffset failure.
> java.lang.ArrayIndexOutOfBoundsException: -143
> at 
> java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:387) 
> ~[na:1.8.0_121]
> at 
> java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:396) 
> ~[na:1.8.0_121]
> at 
> org.apache.rocketmq.store.MappedFileQueue.findMappedFileByOffset(MappedFileQueue.java:476)
>  ~[rocketmq-store-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at org.apache.rocketmq.store.CommitLog.getMessage(CommitLog.java:730) 
> [rocketmq-store-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at 
> org.apache.rocketmq.store.DefaultMessageStore.getMessage(DefaultMessageStore.java:430)
>  [rocketmq-store-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at .
> at 
> org.apache.rocketmq.broker.processor.PullMessageProcessor.processRequest(PullMessageProcessor.java:190)
>  [rocketmq-broker-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at 
> org.apache.rocketmq.broker.processor.PullMessageProcessor.processRequest(PullMessageProcessor.java:74)
>  [rocketmq-broker-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at 
> org.apache.rocketmq.remoting.netty.NettyRemotingAbstract$1.run(NettyRemotingAbstract.java:108)
>  [rocketmq-remoting-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at 
> org.apache.rocketmq.remoting.netty.RequestTask.run(RequestTask.java:80) 
> [rocketmq-remoting-4.1.0-incubating-SNAPSHOT.jar:4.1.0-incubating-SNAPSHOT]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_121]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_121]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_121]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> 2017-03-24 09:55:25 WARN PullMessageThread_26 - findMappedFileByOffset 
> failure.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ROCKETMQ-165) Maximum pull batch size hard-coded restricted

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon closed ROCKETMQ-165.
--

> Maximum pull batch size hard-coded restricted
> -
>
> Key: ROCKETMQ-165
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-165
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-store
>Affects Versions: 4.1.0-incubating
>Reporter: Zhanhui Li
>Assignee: Zhanhui Li
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ROCKETMQ-167) namesrv RouteInfoManager scanNotActiveBroker have the Thread competition

[yukon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ROCKETMQ-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

yukon updated ROCKETMQ-167:
---
Fix Version/s: 4.2.0-incubating

> namesrv RouteInfoManager scanNotActiveBroker  have the Thread competition
> -
>
> Key: ROCKETMQ-167
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-167
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-namesrv
>Affects Versions: 4.0.0-incubating
>Reporter: zhaoziyan
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> {code}
> public void scanNotActiveBroker() {
> Iterator> it = 
> this.brokerLiveTable.entrySet().iterator();
> while (it.hasNext()) {
> Entry next = it.next();
> long last = next.getValue().getLastUpdateTimestamp();
> if ((last + BROKER_CHANNEL_EXPIRED_TIME) < 
> System.currentTimeMillis()) {
> RemotingUtil.closeChannel(next.getValue().getChannel());
> it.remove();
> log.warn("The broker channel expired, {} {}ms", 
> next.getKey(), BROKER_CHANNEL_EXPIRED_TIME);
> this.onChannelDestroy(next.getKey(), 
> next.getValue().getChannel());
> }
> }
> }
> {code}
> scanNotActiveBroker dont have the writelock ,but it is modify the 
> brokerLiveTable and Iterator the brokerLiveTable .
> NSScheduledThread and nettyeventExcutor Thread have the  competition.
>   The scanNotActiveBroker  may throw 
>   java.util.ConcurrentModificationException: null 
>  and nevel run again 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)