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

2017-09-25 Thread yukon (JIRA)

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

yukon resolved ROCKETMQ-106.

Resolution: Duplicate

> 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.2.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.4.14#64029)


[jira] [Created] (ROCKETMQ-294) Do flow control on the number and size dimensions when pull message

2017-09-25 Thread yukon (JIRA)
yukon created ROCKETMQ-294:
--

 Summary: Do flow control on the number and size dimensions when 
pull message
 Key: ROCKETMQ-294
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-294
 Project: Apache RocketMQ
  Issue Type: Improvement
  Components: rocketmq-client
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


*Motivations*

Current flow control strategy only support on Queue level, each message queue 
can cache 1000 message by default. 

When lots of message queue are assigned to one consumer instance, the consumer 
will cache too many messages, may cause OOM exception.

On the other hand, only control the message amount is not enough, should 
support do flow control on the number and size dimensions, on Topic and Queue 
level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-275) The comment of PushConsumer’s configuration “unitMode” is ambiguous

2017-09-05 Thread yukon (JIRA)

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

yukon updated ROCKETMQ-275:
---
Priority: Minor  (was: Major)

> The comment of PushConsumer’s configuration “unitMode” is ambiguous
> ---
>
> Key: ROCKETMQ-275
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-275
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Mark Yang
>Assignee: Xiaorui Wang
>Priority: Minor
>
> The code in DefaultMQPushConsumer.java 
>/**
>  * Whether the unit of subscription group
>  */
> private boolean unitMode = false;
> -
> What “unitMode” really mean, How do we use it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ROCKETMQ-275) The comment of PushConsumer’s configuration “unitMode” is ambiguous

2017-09-05 Thread yukon (JIRA)

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

yukon commented on ROCKETMQ-275:


Hi, since it's just a question, could you please use our mailing list? please 
refer to: http://rocketmq.apache.org/about/contact/

> The comment of PushConsumer’s configuration “unitMode” is ambiguous
> ---
>
> Key: ROCKETMQ-275
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-275
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Mark Yang
>Assignee: Xiaorui Wang
>
> The code in DefaultMQPushConsumer.java 
>/**
>  * Whether the unit of subscription group
>  */
> private boolean unitMode = false;
> -
> What “unitMode” really mean, How do we use it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-275) The comment of PushConsumer’s configuration “unitMode” is ambiguous

2017-09-05 Thread yukon (JIRA)

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

yukon updated ROCKETMQ-275:
---
Issue Type: Improvement  (was: Bug)

> The comment of PushConsumer’s configuration “unitMode” is ambiguous
> ---
>
> Key: ROCKETMQ-275
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-275
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client
>Reporter: Mark Yang
>Assignee: Xiaorui Wang
>
> The code in DefaultMQPushConsumer.java 
>/**
>  * Whether the unit of subscription group
>  */
> private boolean unitMode = false;
> -
> What “unitMode” really mean, How do we use it ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-276) rocketmq-spark

2017-09-05 Thread yukon (JIRA)

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

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

> rocketmq-spark 
> ---
>
> Key: ROCKETMQ-276
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-276
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-externals
>Affects Versions: 4.1.0-incubating
>Reporter: weiqichx
>Assignee: dongeforever
>  Labels: patch
> Attachments: RocketMqRDD.scala
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When Multiple-broker in queue running, appear Failed to get records for 
> rs-consumer after polling.
> Cause: RocketMqRDDIterator hasNext used offsetRange sum all broker. however 
> the first broker doesn't has next MessageExt. but index is serial in next 
> function.
> fixed patch in attachment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-277) get localhost throw java.net.UnknownHostException,when server hostname not in /etc/hosts

2017-09-05 Thread yukon (JIRA)

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

yukon updated ROCKETMQ-277:
---
Issue Type: Improvement  (was: Bug)

> get localhost throw java.net.UnknownHostException,when server hostname  not 
> in /etc/hosts
> -
>
> Key: ROCKETMQ-277
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-277
> Project: Apache RocketMQ
>  Issue Type: Improvement
>  Components: rocketmq-client, rocketmq-commons
>Affects Versions: 4.0.0-incubating, 4.1.0-incubating
>Reporter: yubaofu
>Assignee: Xiaorui Wang
> Fix For: 4.2.0-incubating
>
>
> if server hostname not in /etc/hosts, 
> org.apache.rocketmq.common.MixAll#localhost throw  UnknownHostException 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ROCKETMQ-276) rocketmq-spark

2017-09-05 Thread yukon (JIRA)

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

yukon commented on ROCKETMQ-276:


Hi, thanks for your report.

Attach a patch isn't a good method, cloud you please submit a PR to 
https://github.com/apache/incubator-rocketmq-externals?

And there is a doc can help you to submit your first PR: 
http://rocketmq.apache.org/docs/how-to-contribute/

> rocketmq-spark 
> ---
>
> Key: ROCKETMQ-276
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-276
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-externals
>Affects Versions: 4.1.0-incubating
>Reporter: weiqichx
>Assignee: dongeforever
>  Labels: patch
> Fix For: 4.1.0-incubating
>
> Attachments: RocketMqRDD.scala
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> When Multiple-broker in queue running, appear Failed to get records for 
> rs-consumer after polling.
> Cause: RocketMqRDDIterator hasNext used offsetRange sum all broker. however 
> the first broker doesn't has next MessageExt. but index is serial in next 
> function.
> fixed patch in attachment.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-285) file test error when make link

2017-09-05 Thread yukon (JIRA)

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

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

> file test error when make link
> --
>
> Key: ROCKETMQ-285
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-285
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: build
>Affects Versions: 4.0.0-incubating, 4.1.0-incubating
>Reporter: willim.z
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> error file path: distribution/bin/os.sh.
> line 62.
> cannot test ${HOME}/tmpfs while making link to ./tmpfs
> change "ln -s /dev/shm tmpfs" to "ln -s /dev/shm ${HOME}/tmpfs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (ROCKETMQ-285) file test error when make link

2017-09-05 Thread yukon (JIRA)

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

yukon reassigned ROCKETMQ-285:
--

Assignee: yukon  (was: Stevens Chew)

> file test error when make link
> --
>
> Key: ROCKETMQ-285
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-285
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: build
>Affects Versions: 4.0.0-incubating, 4.1.0-incubating
>Reporter: willim.z
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> error file path: distribution/bin/os.sh.
> line 62.
> cannot test ${HOME}/tmpfs while making link to ./tmpfs
> change "ln -s /dev/shm tmpfs" to "ln -s /dev/shm ${HOME}/tmpfs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ROCKETMQ-267) server may reject messages when pdflush write dirty data back info disk

2017-09-04 Thread yukon (JIRA)

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

yukon commented on ROCKETMQ-267:


[~after_sss] Did you try this parameter `transientStorePoolEnable=true`? And it 
would be great if you could provide a solution for this issue -:)

> server may reject messages when pdflush write dirty data back info disk
> ---
>
> Key: ROCKETMQ-267
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-267
> Project: Apache RocketMQ
>  Issue Type: Bug
>Affects Versions: 4.1.0-incubating
> Environment: linux
>Reporter: wenqi.huang
>Assignee: vongosling
>Priority: Critical
> Attachments: screenshot-1.png
>
>
> I found the following error in the client's log :
> 2017-08-10 09:06:57  ERROR [DubboServerHandler-10.28.109.45:20994-thread-475] 
> c.c.d.a.c.b.r.RocketMQMsgProducer[RocketMQMsgProducer.java:42] -> Send ons 
> msg failed, topic=TopicSubOrderDataSync, tag=TagActivityDataSync, 
> key=activity-order-411320385584760066, msg=411320385584760066
> org.apache.rocketmq.client.exception.MQBrokerException: CODE: 2  DESC: 
> [TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in 
> queue: 208ms, size of queue: 17
> For more information, please visit the url, 
> http://rocketmq.apache.org/docs/faq/
>   at 
> org.apache.rocketmq.client.impl.MQClientAPIImpl.processSendResponse(MQClientAPIImpl.java:531)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessageSync(MQClientAPIImpl.java:345)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessage(MQClientAPIImpl.java:327)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessage(MQClientAPIImpl.java:290)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendKernelImpl(DefaultMQProducerImpl.java:688)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDefaultImpl(DefaultMQProducerImpl.java:458)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1049)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1008)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
>   at 
> org.apache.rocketmq.client.producer.DefaultMQProducer.send(DefaultMQProducer.java:204)
>  ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
> and I look into store.log in RocketMQ Broker, and found that at the same 
> time, the following line is there:
> 2017-08-10 09:06:57 INFO FlushRealTimeService - Flush data to disk costs 1240 
> ms
> I look into the source code, and found that rocketmq have some index files, 
> which rocketmq will not write immediately(because it is wrote randomlly), but 
> when a index file write finished(about 500MB), rocketmq finally force it into 
> disk, that means dirty pages will be about 500MB maximally, (I have executed 
> the bin/os.sh under RocketMQ,  which change the default behavior of linux 
> pdflush).because the [vm.dirty_ratio] is 50, and the available memory is 
> about 1600MB at my linux machine, 500MB will not exceed 50% of 1600M, so 
> pdflush will not executed in this way. So I guess writeback will impact the 
> RT of  write.
> So I write a testcase and proved this, the code is:
> {code}
> public class MappedFileTest {
> public static void main(String[] args) throws IOException, 
> InterruptedException {
> //mock rocketmq's index file
> String indexFile = "/home/admin/rocketmq-data/index/index";
> int indexFileToWriteInMB = 180;
> FileChannel indexFileChannel = new RandomAccessFile(new 
> File(indexFile), "rw").getChannel();
> final MappedByteBuffer indexFileBuffer = 
> indexFileChannel.map(MapMode.READ_WRITE, 0, 1024*1024*500);//500M
> //put some dirty data, attention that the data size will not overflow 
> vm.dirty_background_ratio;
> // because we set vm.dirty_expire_centisecs to 3000,so after 30 
> seconds,pdflush will writeback the dirty data into disk.
> byte[] bs = new byte[1024*1024*indexFileToWriteInMB];//180m
> Arrays.fill(bs,(byte)1);
> indexFileBuffer.put(bs);
> //mock rocketmq's commitlog file
> String commitLogFile = 
> 

[jira] [Updated] (ROCKETMQ-267) server may reject messages when pdflush write dirty data back info disk

2017-09-04 Thread yukon (JIRA)

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

yukon updated ROCKETMQ-267:
---
Description: 
I found the following error in the client's log :

2017-08-10 09:06:57  ERROR [DubboServerHandler-10.28.109.45:20994-thread-475] 
c.c.d.a.c.b.r.RocketMQMsgProducer[RocketMQMsgProducer.java:42] -> Send ons msg 
failed, topic=TopicSubOrderDataSync, tag=TagActivityDataSync, 
key=activity-order-411320385584760066, msg=411320385584760066
org.apache.rocketmq.client.exception.MQBrokerException: CODE: 2  DESC: 
[TIMEOUT_CLEAN_QUEUE]broker busy, start flow control for a while, period in 
queue: 208ms, size of queue: 17
For more information, please visit the url, http://rocketmq.apache.org/docs/faq/
at 
org.apache.rocketmq.client.impl.MQClientAPIImpl.processSendResponse(MQClientAPIImpl.java:531)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessageSync(MQClientAPIImpl.java:345)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessage(MQClientAPIImpl.java:327)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.MQClientAPIImpl.sendMessage(MQClientAPIImpl.java:290)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendKernelImpl(DefaultMQProducerImpl.java:688)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.sendDefaultImpl(DefaultMQProducerImpl.java:458)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1049)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl.send(DefaultMQProducerImpl.java:1008)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]
at 
org.apache.rocketmq.client.producer.DefaultMQProducer.send(DefaultMQProducer.java:204)
 ~[rocketmq-client-4.0.0-incubating.jar!/:4.0.0-incubating]

and I look into store.log in RocketMQ Broker, and found that at the same time, 
the following line is there:

2017-08-10 09:06:57 INFO FlushRealTimeService - Flush data to disk costs 1240 ms

I look into the source code, and found that rocketmq have some index files, 
which rocketmq will not write immediately(because it is wrote randomlly), but 
when a index file write finished(about 500MB), rocketmq finally force it into 
disk, that means dirty pages will be about 500MB maximally, (I have executed 
the bin/os.sh under RocketMQ,  which change the default behavior of linux 
pdflush).because the [vm.dirty_ratio] is 50, and the available memory is about 
1600MB at my linux machine, 500MB will not exceed 50% of 1600M, so pdflush will 
not executed in this way. So I guess writeback will impact the RT of  write.

So I write a testcase and proved this, the code is:

{code}
public class MappedFileTest {
public static void main(String[] args) throws IOException, 
InterruptedException {
//mock rocketmq's index file
String indexFile = "/home/admin/rocketmq-data/index/index";
int indexFileToWriteInMB = 180;
FileChannel indexFileChannel = new RandomAccessFile(new 
File(indexFile), "rw").getChannel();
final MappedByteBuffer indexFileBuffer = 
indexFileChannel.map(MapMode.READ_WRITE, 0, 1024*1024*500);//500M

//put some dirty data, attention that the data size will not overflow 
vm.dirty_background_ratio;
// because we set vm.dirty_expire_centisecs to 3000,so after 30 
seconds,pdflush will writeback the dirty data into disk.
byte[] bs = new byte[1024*1024*indexFileToWriteInMB];//180m
Arrays.fill(bs,(byte)1);
indexFileBuffer.put(bs);

//mock rocketmq's commitlog file
String commitLogFile = "/home/admin/rocketmq-data/commitlog/commitlog";
FileChannel commitLogChannel = new RandomAccessFile(new 
File(commitLogFile), "rw").getChannel();
final MappedByteBuffer commitLogBuffer = 
commitLogChannel.map(MapMode.READ_WRITE, 0, 1024*1024*1024);//1G

final Object lockObj = new Object();

//mock FlushCommitLogService to writeback dirty data of commitLog into 
disk.
FlushCommitLogService commitLogService = new 
FlushCommitLogService(lockObj, commitLogBuffer);
commitLogService.start();

//mock messageReceived to write data into commitLogFile.
mockMessageReceived(lockObj, commitLogBuffer);

//wait for about 30 seconds(let linux pdflush to writeback dirty data 
of indexFile), then you will see some output like(this will block the thread 
that handle messages, then client will fail to send 

[jira] [Created] (ROCKETMQ-270) Slave Broker can't start normally if master broker has been leaned commit log

2017-08-18 Thread yukon (JIRA)
yukon created ROCKETMQ-270:
--

 Summary: Slave Broker can't start normally if master broker has 
been leaned commit log
 Key: ROCKETMQ-270
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-270
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: rocketmq-broker
Affects Versions: 4.1.0-incubating, 4.0.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


How to reproduce this bug?

1. Start master broker, and write lots of messages until broker starts cleaning 
commit log.
2. When the first commit log file isn't 00, start slave broker.

In current state, slave broker will pull messages from master broker, but the 
first message's offset isn't zero, and isn't equal to commit offset, so slave 
broker could't do right flush.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-260) The wrong lock used when destroy IndexService

2017-08-10 Thread yukon (JIRA)
yukon created ROCKETMQ-260:
--

 Summary: The wrong lock used when destroy IndexService
 Key: ROCKETMQ-260
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-260
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: build
Affects Versions: 4.1.0-incubating, 4.0.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


When destroy IndexService, the indexFileList should be cleared with write lock 
guarantee, but destroy method uses read lock insted.

{code}
public void destroy() {
try {
this.readWriteLock.readLock().lock();
for (IndexFile f : this.indexFileList) {
f.destroy(1000 * 3);
}
this.indexFileList.clear();
} catch (Exception e) {
log.error("destroy exception", e);
} finally {
this.readWriteLock.readLock().unlock();
}
}
{code} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-259) Too many reflection calls when decode remoting command header

2017-08-10 Thread yukon (JIRA)
yukon created ROCKETMQ-259:
--

 Summary: Too many reflection calls when decode remoting command 
header
 Key: ROCKETMQ-259
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-259
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: rocketmq-remoting
Affects Versions: 4.1.0-incubating, 4.0.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


Each field in a CommandCustomHeader will be checked to ensure some key fields 
aren't null when decode RemotingCommand header. This process will cause a 
reflection call, and current code has a cache mechanism, but it doesn't work.

{code}
Annotation annotation = getNotNullAnnotation(field);
if (annotation != null) {
throw new RemotingCommandException("the custom field <" + fieldName + "> is 
null");
}
{code}

{code}
private Annotation getNotNullAnnotation(Field field) {
Annotation annotation = NOT_NULL_ANNOTATION_CACHE.get(field);

if (annotation == null) { 
annotation = field.getAnnotation(CFNotNull.class); //[1]
synchronized (NOT_NULL_ANNOTATION_CACHE) {
NOT_NULL_ANNOTATION_CACHE.put(field, annotation);
}
}
return annotation;
}
{code}

[1]. If a field doesn't has CFNotNull annotation, each check will cause a 
reflection call.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-258) Move benchmark scripts to distribution module

2017-08-10 Thread yukon (JIRA)
yukon created ROCKETMQ-258:
--

 Summary: Move benchmark scripts to distribution module
 Key: ROCKETMQ-258
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-258
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: build
Affects Versions: 4.1.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


The [benchmark 
scripts|https://github.com/apache/incubator-rocketmq/tree/master/benchmark] 
should be moved to distribution module, otherwise the binary release will lose 
these scripts.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (ROCKETMQ-252) After running for a period of time, the consumer side is stopped

2017-07-30 Thread yukon (JIRA)

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

yukon commented on ROCKETMQ-252:


Please provide more details, client logs and subscription code~

> After running for a period of time, the consumer side is stopped
> 
>
> Key: ROCKETMQ-252
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-252
> Project: Apache RocketMQ
>  Issue Type: Bug
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: chen sun
>Assignee: Xiaorui Wang
>
> After running for a period of time, the consumer side of the suspension, the 
> current system using push mode, version V4.0, you must take the restart 
> consumer or restart RMQ to restore.
> 运行一段时间后消费端停止消费,目前系统采用push模式,版本V4.0,必须采取重启消费端或者重启RMQ才能恢复。



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (ROCKETMQ-226) Remove the code that is not useful in the loop

2017-07-05 Thread yukon (JIRA)

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

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

> Remove the code that is not useful in the loop
> --
>
> Key: ROCKETMQ-226
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-226
> Project: Apache RocketMQ
>  Issue Type: Wish
>  Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
>Reporter: huangyiminghappy
>Assignee: Xiaorui Wang
>Priority: Minor
> Fix For: 4.2.0-incubating
>
> Attachments: 555.png, 666.png
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> in the clientComponent 
> ,org.apache.rocketmq.client.impl.factory.MQClientInstance class has the 
> method like this:
> {code:java}
>  public FindBrokerResult findBrokerAddressInAdmin(final String brokerName) {
> String brokerAddr = null;
> boolean slave = false;
> boolean found = false;
> HashMap map = 
> this.brokerAddrTable.get(brokerName);
> if (map != null && !map.isEmpty()) {
> FOR_SEG:
> for (Map.Entry entry : map.entrySet()) {
> Long id = entry.getKey();
> brokerAddr = entry.getValue();
> if (brokerAddr != null) {
> found = true;
> if (MixAll.MASTER_ID == id) {
> slave = false;
> break FOR_SEG;
> } else {
> slave = true;
> }
> break;
> }
> } // end of for
> }
> if (found) {
> return new FindBrokerResult(brokerAddr, slave);
> }
> return null;
> }
> {code}
> the code {color:red}{color:red}FOR_SEG{color} {color} is not useful,It is not 
> multiple loop,You do not need to jump to the specified loop,so i suggest 
> remove the FOR_SEQ code like this:
>  
> {code:java}
> public FindBrokerResult findBrokerAddressInAdmin(final String brokerName) 
> {
> String brokerAddr = null;
> boolean slave = false;
> boolean found = false;
> HashMap map = 
> this.brokerAddrTable.get(brokerName);
> if (map != null && !map.isEmpty()) {
> for (Map.Entry entry : map.entrySet()) {
> Long id = entry.getKey();
> brokerAddr = entry.getValue();
> if (brokerAddr != null) {
> found = true;
> if (MixAll.MASTER_ID == id) {
> slave = false;
> } else {
> slave = true;
> }
> break;
> }
> } // end of for
> }
> if (found) {
> return new FindBrokerResult(brokerAddr, slave);
> }
> return null;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-238) Subsequent executions are suppressed when some key periodic tasks encounter an exception

2017-07-05 Thread yukon (JIRA)
yukon created ROCKETMQ-238:
--

 Summary: Subsequent executions are suppressed when some key 
periodic tasks encounter an exception 
 Key: ROCKETMQ-238
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-238
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: rocketmq-broker, rocketmq-remoting, rocketmq-store
Affects Versions: 4.0.0-incubating, 4.1.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.2.0-incubating


There are many scheduled tasks delegated to ScheduledExecutorService or Timer 
in broker.

When the scheduled task encounters an exception, subsequent executions are 
suppressed, see:
{code}
/**
 * Creates and executes a periodic action that becomes enabled first
 * after the given initial delay, and subsequently with the given
 * period; that is executions will commence after
 * {@code initialDelay} then {@code initialDelay+period}, then
 * {@code initialDelay + 2 * period}, and so on.
 * If any execution of the task
 * encounters an exception, subsequent executions are suppressed.
 * Otherwise, the task will only terminate via cancellation or
 * termination of the executor.  If any execution of this task
 * takes longer than its period, then subsequent executions
 * may start late, but will not concurrently execute.
 *
 * @param command the task to execute
 * @param initialDelay the time to delay first execution
 * @param period the period between successive executions
 * @param unit the time unit of the initialDelay and period parameters
 * @return a ScheduledFuture representing pending completion of
 * the task, and whose {@code get()} method will throw an
 * exception upon cancellation
 * @throws RejectedExecutionException if the task cannot be
 * scheduled for execution
 * @throws NullPointerException if command is null
 * @throws IllegalArgumentException if period less than or equal to zero
 */
public ScheduledFuture scheduleAtFixedRate(Runnable command,
  long initialDelay,
  long period,
  TimeUnit unit);
{code}

So catch Throwable to avoid error canceled our key scheduled tasks.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-236) Script to merge github pull request

2017-06-29 Thread yukon (JIRA)
yukon created ROCKETMQ-236:
--

 Summary: Script to merge github pull request
 Key: ROCKETMQ-236
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-236
 Project: Apache RocketMQ
  Issue Type: Improvement
  Components: build
Affects Versions: 4.2.0-incubating
Reporter: yukon
Assignee: yukon


Utility for creating well-formed pull request merges and pushing them to 
Apache. Provide a modified version of 
https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (ROCKETMQ-206) Load JSON config file error if non-1byte character exists

2017-05-24 Thread yukon (JIRA)
yukon created ROCKETMQ-206:
--

 Summary: Load JSON config file error if non-1byte character exists
 Key: ROCKETMQ-206
 URL: https://issues.apache.org/jira/browse/ROCKETMQ-206
 Project: Apache RocketMQ
  Issue Type: Bug
  Components: rocketmq-commons
Affects Versions: 4.0.0-incubating
Reporter: yukon
Assignee: yukon
 Fix For: 4.1.0-incubating


If there are some non-1byte character in consumeroffset.json or other config 
files, when Broker restarted, the file contents will be ignored.

See this method, when file.length() != character number, bug triggered.
{code}
public static String file2String(final File file) {
if (file.exists()) {
char[] data = new char[(int) file.length()];
boolean result = false;

FileReader fileReader = null;
try {
fileReader = new FileReader(file);
int len = fileReader.read(data);
result = len == data.length;
} catch (IOException e) {
// e.printStackTrace();
} finally {
if (fileReader != null) {
try {
fileReader.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}

if (result) {
return new String(data);
}
}
return null;
}
{code}



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


[jira] [Commented] (ROCKETMQ-41) Streaming data to Apache Ignite (integration)

2017-04-26 Thread yukon (JIRA)

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

yukon commented on ROCKETMQ-41:
---

Cool~ 
Thanks Roman, for your efforts.

> Streaming data to Apache Ignite (integration)
> -
>
> Key: ROCKETMQ-41
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-41
> Project: Apache RocketMQ
>  Issue Type: New Feature
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.1.0-incubating
>
>
> Source code of the streamer is to be under Apache Ignite.



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


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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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()

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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.

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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] [Closed] (ROCKETMQ-95) The config files of client log have been damaged

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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()

2017-04-20 Thread 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

2017-04-20 Thread 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()

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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 ??

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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/

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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 ??

2017-04-20 Thread 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

2017-04-20 Thread 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 ??

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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

2017-04-20 Thread 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)


  1   2   3   >