[jira] [Resolved] (ROCKETMQ-255) Offset store is null after consumer clients start()
[ https://issues.apache.org/jira/browse/ROCKETMQ-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever resolved ROCKETMQ-255. --- Resolution: Fixed > Offset store is null after consumer clients start() > --- > > Key: ROCKETMQ-255 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-255 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client >Affects Versions: 4.1.0-incubating >Reporter: Zhanhui Li >Assignee: Zhanhui Li > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-73) Do something with jmenv.tbsite.net
[
https://issues.apache.org/jira/browse/ROCKETMQ-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-73:
-
Fix Version/s: (was: 4.2.0-incubating)
4.3.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.3.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.4.14#64029)
[jira] [Updated] (ROCKETMQ-72) DefaultMessageStore cannot be properly shutdown when failed in the middle of start()
[
https://issues.apache.org/jira/browse/ROCKETMQ-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-72:
-
Fix Version/s: (was: 4.2.0-incubating)
4.3.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.3.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.4.14#64029)
[jira] [Updated] (ROCKETMQ-63) Integrate spark plugin
[ https://issues.apache.org/jira/browse/ROCKETMQ-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-63: - Fix Version/s: (was: 4.2.0-incubating) 4.3.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: John Fang >Assignee: vongosling > Fix For: 4.3.0-incubating > > > 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.4.14#64029)
[jira] [Commented] (ROCKETMQ-66) Manage the %DLQ% Queue
[ https://issues.apache.org/jira/browse/ROCKETMQ-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171062#comment-16171062 ] dongeforever commented on ROCKETMQ-66: -- any guy want to do this? [~lindzh] > Manage the %DLQ% Queue > -- > > Key: ROCKETMQ-66 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-66 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker >Reporter: Jie.Tang >Assignee: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > I have a problem whether we need to change the %DLQ% Queue perm or not(from 2 > to 6.) > In 3.5.8 the %DLQ% Queue perm is 2,only writable,but I want to read it > because I want to know how many message is in the %DLQ% queue, which message > has problem and why it can't be consume . > I want to query the problem message(%DLQ% Queue Message) in > rocketMq-console,but because of the perm,I can't. > I need to change the perm from 2 to 6 before I query it. > Could you help me to solvle this? Thank you. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-49) we want to query producer info
[ https://issues.apache.org/jira/browse/ROCKETMQ-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-49: - Fix Version/s: (was: 4.2.0-incubating) 4.3.0-incubating > we want to query producer info > -- > > Key: ROCKETMQ-49 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-49 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-tools >Reporter: Jie.Tang >Assignee: vongosling >Priority: Minor > Labels: features > Fix For: 4.3.0-incubating > > > We deploy the rocketmq-console and want to improve the producer page. > We want to see all of the online producer(or query a producer only by > topic).But we can't. > We can only query a online producer use topic and groupName. (Use > GET_PRODUCER_CONNECTION_LIST) > I think it is not easy to use.So I wish you can add the feature for us. > For example: > 1.Get all producers > 2.Query producer only by topic (don't need groupName) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-44) Duplicated codes in DefaultMessageStore.getEarliestMessageTime and DefaultMessageStore.getMessageStoreTimeStamp
[ https://issues.apache.org/jira/browse/ROCKETMQ-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-44: - Fix Version/s: (was: 4.2.0-incubating) 4.3.0-incubating > Duplicated codes in DefaultMessageStore.getEarliestMessageTime and > DefaultMessageStore.getMessageStoreTimeStamp > --- > > Key: ROCKETMQ-44 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-44 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Wu Sheng >Assignee: vongosling >Priority: Minor > Fix For: 4.3.0-incubating > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (ROCKETMQ-28) Transportation Layer Security
[ https://issues.apache.org/jira/browse/ROCKETMQ-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever resolved ROCKETMQ-28. -- Resolution: Fixed > Transportation Layer Security > - > > Key: ROCKETMQ-28 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-28 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-remoting >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.2.0-incubating > > > RocketMQ delivers data in clear text for now, which requires internal network > environment. As use scenarios expand, end-to-end security is in bad need. > This issue is to introduce features making RocketMQ security for various use > cases and sacrificing as few as possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-24) rocketmq jmx metric for monitor
[ https://issues.apache.org/jira/browse/ROCKETMQ-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-24: - Fix Version/s: (was: 4.2.0-incubating) 4.3.0-incubating > rocketmq jmx metric for monitor > > > Key: ROCKETMQ-24 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-24 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-broker >Reporter: zhaoziyan >Assignee: yukon >Priority: Minor > Fix For: 4.3.0-incubating > > > rocketmq need some metric for monitor . > for example . Broker in/out tps , in/out data bytes,topic consume behind num > for the best ,it can ues jmx port . -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-21) Explore using DistributedLog as the storage for Rocketmq
[ https://issues.apache.org/jira/browse/ROCKETMQ-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-21: - Fix Version/s: (was: 4.2.0-incubating) 4.3.0-incubating > Explore using DistributedLog as the storage for Rocketmq > > > Key: ROCKETMQ-21 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-21 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-store >Reporter: Sijie Guo >Assignee: vongosling > Labels: performance, storage > Fix For: 4.3.0-incubating > > > As discussed with [~vongosling] before, create a jira for exploring using > DistributedLog as the storage for rocketmq. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ROCKETMQ-4) Extract all RocketMQ constants from MixAll to RocketMQProperties class
[
https://issues.apache.org/jira/browse/ROCKETMQ-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-4:
Fix Version/s: (was: 4.2.0-incubating)
4.3.0-incubating
> Extract all RocketMQ constants from MixAll to RocketMQProperties class
> --
>
> Key: ROCKETMQ-4
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-4
> Project: Apache RocketMQ
> Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.3.0-incubating
>
>
> {{MixAll}} contains helper methods and constants that are mostly not used by
> those methods, but used through all the code base.
> I propose to gather all constants into {{RocketMQProperties}} class in the
> same directory, and move helper methods to {{UtilAll}}.
> Any objections?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ROCKETMQ-232) Optimize ConsumeMessageOrderlyService by attaching MessageQueue to thread
dongeforever created ROCKETMQ-232: - Summary: Optimize ConsumeMessageOrderlyService by attaching MessageQueue to thread Key: ROCKETMQ-232 URL: https://issues.apache.org/jira/browse/ROCKETMQ-232 Project: Apache RocketMQ Issue Type: Bug Reporter: dongeforever Assignee: vongosling Fix For: 4.2.0-incubating The current logic of ConsumeMessageOrderlyService is using lock for each MessageQueue. It may block the thread pool. If the ConsumeRequest queue is as follows: q1, q1, q1, q1, q2, q2, q2 the thread pool will block on q1, and q2 is waiting. If attach q1 to thread1, q2 to thread2, then q1 and q2 is consuming at the same time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ROCKETMQ-232) Optimize ConsumeMessageOrderlyService by attaching MessageQueue to thread
[ https://issues.apache.org/jira/browse/ROCKETMQ-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-232: - Assignee: dongeforever (was: vongosling) > Optimize ConsumeMessageOrderlyService by attaching MessageQueue to thread > - > > Key: ROCKETMQ-232 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-232 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.2.0-incubating > > > The current logic of ConsumeMessageOrderlyService is using lock for each > MessageQueue. > It may block the thread pool. > If the ConsumeRequest queue is as follows: > q1, q1, q1, q1, q2, q2, q2 > the thread pool will block on q1, and q2 is waiting. > If attach q1 to thread1, q2 to thread2, then q1 and q2 is consuming at the > same time. > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ROCKETMQ-230) Refactor the tests: move IT-related tests to test module and disable useless error log in test module
[ https://issues.apache.org/jira/browse/ROCKETMQ-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-230: - Assignee: dongeforever (was: vongosling) > Refactor the tests: move IT-related tests to test module and disable useless > error log in test module > - > > Key: ROCKETMQ-230 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-230 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.2.0-incubating > > > Refactor the tests: > 1. move IT-related tests (which need to start broker or namesrv controller) > to test module > 2. disable useless output in the Test module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ROCKETMQ-230) Refactor the tests: move IT-related tests to test module and disable useless error log in test module
[ https://issues.apache.org/jira/browse/ROCKETMQ-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-230: - Assignee: vongosling (was: dongeforever) > Refactor the tests: move IT-related tests to test module and disable useless > error log in test module > - > > Key: ROCKETMQ-230 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-230 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: dongeforever >Assignee: vongosling > Fix For: 4.2.0-incubating > > > Refactor the tests: > 1. move IT-related tests (which need to start broker or namesrv controller) > to test module > 2. disable useless output in the Test module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ROCKETMQ-230) Refactor the tests: move IT-related tests to test module and disable useless error log in test module
dongeforever created ROCKETMQ-230: - Summary: Refactor the tests: move IT-related tests to test module and disable useless error log in test module Key: ROCKETMQ-230 URL: https://issues.apache.org/jira/browse/ROCKETMQ-230 Project: Apache RocketMQ Issue Type: Bug Reporter: dongeforever Assignee: vongosling Fix For: 4.2.0-incubating Refactor the tests: 1. move IT-related tests (which need to start broker or namesrv controller) to test module 2. disable useless output in the Test module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ROCKETMQ-230) Refactor the tests: move IT-related tests to test module and disable useless error log in test module
[ https://issues.apache.org/jira/browse/ROCKETMQ-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-230: - Assignee: dongeforever (was: vongosling) > Refactor the tests: move IT-related tests to test module and disable useless > error log in test module > - > > Key: ROCKETMQ-230 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-230 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.2.0-incubating > > > Refactor the tests: > 1. move IT-related tests (which need to start broker or namesrv controller) > to test module > 2. disable useless output in the Test module -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (ROCKETMQ-145) Hit ConcurrentModificationException in doWaitTransfer which happens very offen
[ https://issues.apache.org/jira/browse/ROCKETMQ-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-145. - Resolution: Fixed Fix Version/s: (was: 4.0.0-incubating) 4.1.0-incubating > Hit ConcurrentModificationException in doWaitTransfer which happens very offen > -- > > Key: ROCKETMQ-145 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-145 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-store >Affects Versions: 4.0.0-incubating >Reporter: Eason Chen >Assignee: yukon > Fix For: 4.1.0-incubating > > > we use master and slave , sync transfer and asyn flush, happens this very > offen: > 2017-03-17 20:12:38 WARN GroupTransferService - GroupTransferService service > has exception. > java.util.ConcurrentModificationException: null > at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901) > ~[na:1.8.0_121] > at java.util.ArrayList$Itr.next(ArrayList.java:851) ~[na:1.8.0_121] > at > org.apache.rocketmq.store.ha.HAService$GroupTransferService.doWaitTransfer(HAService.java:277) > ~[rocketmq-store-4.0.0-incubating.jar:4.0.0-incubating] > at > org.apache.rocketmq.store.ha.HAService$GroupTransferService.run(HAService.java:301) > ~[rocketmq-store-4.0.0-incubating.jar:4.0.0-incubating] > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (ROCKETMQ-208) incompatibility problem found in enviroment of JDK 1.7 when running client
[ https://issues.apache.org/jira/browse/ROCKETMQ-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-208. - Resolution: Fixed > incompatibility problem found in enviroment of JDK 1.7 when running client > -- > > Key: ROCKETMQ-208 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-208 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client > Environment: jdk 1.7 >Reporter: laiyiyu >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > when I start the application which dependencies on rmq client 3.5.8 in > java7, the application throw the exception no such method, causing by the > ConcurrentHashMap inner class KeySetView of the java8incompatible with > the java7; > so , I think the official use the java8 packing the rmq source code -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-208) incompatibility problem found in enviroment of JDK 1.7 when running client
[ https://issues.apache.org/jira/browse/ROCKETMQ-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-208: -- Fix Version/s: 4.1.0-incubating > incompatibility problem found in enviroment of JDK 1.7 when running client > -- > > Key: ROCKETMQ-208 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-208 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client > Environment: jdk 1.7 >Reporter: laiyiyu >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > when I start the application which dependencies on rmq client 3.5.8 in > java7, the application throw the exception no such method, causing by the > ConcurrentHashMap inner class KeySetView of the java8incompatible with > the java7; > so , I think the official use the java8 packing the rmq source code -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-220) Add IT test for Filter By SQL 92
[ https://issues.apache.org/jira/browse/ROCKETMQ-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-220. - Resolution: Fixed > Add IT test for Filter By SQL 92 > > > Key: ROCKETMQ-220 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-220 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-218) README.md update, remove some github links
[ https://issues.apache.org/jira/browse/ROCKETMQ-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-218. - Resolution: Fixed > README.md update, remove some github links > -- > > Key: ROCKETMQ-218 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-218 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Diqiu Zhou >Assignee: vongosling > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-219) Add Batch Example
[ https://issues.apache.org/jira/browse/ROCKETMQ-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-219. - Resolution: Fixed > Add Batch Example > - > > Key: ROCKETMQ-219 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-219 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.1.0-incubating > > > Add batch example -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-218) README.md update, remove some github links
[ https://issues.apache.org/jira/browse/ROCKETMQ-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-218: -- Summary: README.md update, remove some github links (was: README.md update) > README.md update, remove some github links > -- > > Key: ROCKETMQ-218 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-218 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Diqiu Zhou >Assignee: vongosling > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-220) Add IT test for Filter By SQL 92
[ https://issues.apache.org/jira/browse/ROCKETMQ-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-220: -- Fix Version/s: 4.1.0-incubating > Add IT test for Filter By SQL 92 > > > Key: ROCKETMQ-220 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-220 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ROCKETMQ-220) Add IT test for Filter By SQL 92
dongeforever created ROCKETMQ-220: - Summary: Add IT test for Filter By SQL 92 Key: ROCKETMQ-220 URL: https://issues.apache.org/jira/browse/ROCKETMQ-220 Project: Apache RocketMQ Issue Type: Improvement Reporter: dongeforever Assignee: dongeforever -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ROCKETMQ-219) Add Batch Example
dongeforever created ROCKETMQ-219: - Summary: Add Batch Example Key: ROCKETMQ-219 URL: https://issues.apache.org/jira/browse/ROCKETMQ-219 Project: Apache RocketMQ Issue Type: Bug Reporter: dongeforever Assignee: dongeforever Fix For: 4.1.0-incubating Add batch example -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-216) Website polish
[ https://issues.apache.org/jira/browse/ROCKETMQ-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-216. - Resolution: Fixed > Website polish > -- > > Key: ROCKETMQ-216 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-216 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: Diqiu Zhou >Assignee: vongosling > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-86) Polish the release file format
[ https://issues.apache.org/jira/browse/ROCKETMQ-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-86. Resolution: Fixed > 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-6) Use logger for exceptions instead of e.printStackTrace()
[
https://issues.apache.org/jira/browse/ROCKETMQ-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-6:
Fix Version/s: (was: 4.1.0-incubating)
4.2.0-incubating
> Use logger for exceptions instead of e.printStackTrace()
>
>
> Key: ROCKETMQ-6
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-6
> Project: Apache RocketMQ
> Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.2.0-incubating
>
>
> Replace {{e.printStackTrace()}} with {{log.error(...)}} in all core modules,
> except tests, tools and examples.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-21) Explore using DistributedLog as the storage for Rocketmq
[ https://issues.apache.org/jira/browse/ROCKETMQ-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-21: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Explore using DistributedLog as the storage for Rocketmq > > > Key: ROCKETMQ-21 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-21 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-store >Reporter: Sijie Guo >Assignee: vongosling > Labels: performance, storage > Fix For: 4.2.0-incubating > > > As discussed with [~vongosling] before, create a jira for exploring using > DistributedLog as the storage for rocketmq. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-4) Extract all RocketMQ constants from MixAll to RocketMQProperties class
[
https://issues.apache.org/jira/browse/ROCKETMQ-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-4:
Fix Version/s: (was: 4.1.0-incubating)
4.2.0-incubating
> Extract all RocketMQ constants from MixAll to RocketMQProperties class
> --
>
> Key: ROCKETMQ-4
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-4
> Project: Apache RocketMQ
> Issue Type: Improvement
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.2.0-incubating
>
>
> {{MixAll}} contains helper methods and constants that are mostly not used by
> those methods, but used through all the code base.
> I propose to gather all constants into {{RocketMQProperties}} class in the
> same directory, and move helper methods to {{UtilAll}}.
> Any objections?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-40) AUTO_CLIENT_ACKNOWNLEDGE & CLIENT_ACKNOWLEDGE support
[ https://issues.apache.org/jira/browse/ROCKETMQ-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-40: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > AUTO_CLIENT_ACKNOWNLEDGE & CLIENT_ACKNOWLEDGE support > -- > > Key: ROCKETMQ-40 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-40 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: Jaskey Lam >Assignee: Xiaorui Wang > Fix For: 4.2.0-incubating > > > For now, push consumer only supports DUPS_OK_ACKNOWLEDGE . > If user wants to AUTO_CLIENT_ACKNOWNLEDGE or CLIENT_ACKNOWLEDGE , he or she > must use pull consumer which is not easy enough to use. > push consumer should support AUTO_CLIENT_ACKNOWNLEDGE and CLIENT_ACKNOWLEDGE > . > AUTO_CLIENT_ACKNOWNLEDGE : auto ack after consume and persist to broker > CLIENT_ACKNOWLEDGE : user should ack by itself, consumer will not ack even > after handle. > ref: https://docs.oracle.com/cd/E19587-01/821-0029/aeqbk/index.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-24) rocketmq jmx metric for monitor
[ https://issues.apache.org/jira/browse/ROCKETMQ-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-24: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > rocketmq jmx metric for monitor > > > Key: ROCKETMQ-24 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-24 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-broker >Reporter: zhaoziyan >Assignee: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > rocketmq need some metric for monitor . > for example . Broker in/out tps , in/out data bytes,topic consume behind num > for the best ,it can ues jmx port . -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-23) MappedFileQueue#flush should return true when flushing is successful
[
https://issues.apache.org/jira/browse/ROCKETMQ-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-23:
-
Fix Version/s: (was: 4.1.0-incubating)
4.2.0-incubating
> MappedFileQueue#flush should return true when flushing is successful
>
>
> Key: ROCKETMQ-23
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-23
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-store
>Affects Versions: 4.0.0-incubating
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
> Fix For: 4.2.0-incubating
>
>
> In the current implementation, MappedFileQueue#flush returns {{false}} when
> flushing is successful.
> This is not intuitive and error prone.
> For instance, in {{CommitLog#run line:915-918}}
> {code}
> for (int i = 0; i < RETRY_TIMES_OVER && !result; i++) {
>result = CommitLog.this.mappedFileQueue.flush(0);
>// ...
> }
> {code}
> I believe retries has to be done when flushing is not successful. But with
> the code above, it can try to flush only once on CommitLog termination and
> not continue retrying.
> The same is for {{DefaultMessageStore#doFlush line:1551}}
> Or is this not retry on failure, but the number of times flushing has to be
> done? Then, {{RETRY_TIMES_OVER}} should be renamed to something like
> {{FLUSH_NUM}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-44) Duplicated codes in DefaultMessageStore.getEarliestMessageTime and DefaultMessageStore.getMessageStoreTimeStamp
[ https://issues.apache.org/jira/browse/ROCKETMQ-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-44: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Duplicated codes in DefaultMessageStore.getEarliestMessageTime and > DefaultMessageStore.getMessageStoreTimeStamp > --- > > Key: ROCKETMQ-44 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-44 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Wu Sheng >Assignee: vongosling >Priority: Minor > Fix For: 4.2.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-91) 4.2
[ https://issues.apache.org/jira/browse/ROCKETMQ-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-91: - Summary: 4.2 (was: Reduce lock granularity for putMessage) > 4.2 > --- > > Key: ROCKETMQ-91 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-91 > Project: Apache RocketMQ > Issue Type: Improvement >Affects Versions: 4.1.0-incubating >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.2.0-incubating > > > CommitLog putMessage has a lock as: > lockForPutMessage() > > releasePutMessageLock() > The logic inside the lock includes two main operations: > 1 encode the message > 2 write to the PageCache. > However, we can take the first operation(encode message) out from the lock to > achieve better performance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-78) Prepare and place Dockerfile under incubator-rocketmq/
[
https://issues.apache.org/jira/browse/ROCKETMQ-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-78:
-
Fix Version/s: (was: 4.1.0-incubating)
4.2.0-incubating
> 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
> Fix For: 4.2.0-incubating
>
>
> {{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-48) Link to docker image not accessable . It lead to hub.docker.com
[ https://issues.apache.org/jira/browse/ROCKETMQ-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-48: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Link to docker image not accessable . It lead to hub.docker.com > --- > > Key: ROCKETMQ-48 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-48 > Project: Apache RocketMQ > Issue Type: Bug > Components: build >Reporter: netroby >Assignee: Stevens Chew > Fix For: 4.2.0-incubating > > > https://registry.hub.docker.com/u/vongosl...@apache.org/rocketmq/ > The link on the project readme.md, not working. > it just lead to redirect to https://hub.docker.com > Please check -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-91) 4.2
[ https://issues.apache.org/jira/browse/ROCKETMQ-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-91: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > 4.2 > --- > > Key: ROCKETMQ-91 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-91 > Project: Apache RocketMQ > Issue Type: Improvement >Affects Versions: 4.1.0-incubating >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.2.0-incubating > > > CommitLog putMessage has a lock as: > lockForPutMessage() > > releasePutMessageLock() > The logic inside the lock includes two main operations: > 1 encode the message > 2 write to the PageCache. > However, we can take the first operation(encode message) out from the lock to > achieve better performance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-49) we want to query producer info
[ https://issues.apache.org/jira/browse/ROCKETMQ-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-49: - Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > we want to query producer info > -- > > Key: ROCKETMQ-49 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-49 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-tools >Reporter: Jie.Tang >Assignee: vongosling >Priority: Minor > Labels: features > Fix For: 4.2.0-incubating > > > We deploy the rocketmq-console and want to improve the producer page. > We want to see all of the online producer(or query a producer only by > topic).But we can't. > We can only query a online producer use topic and groupName. (Use > GET_PRODUCER_CONNECTION_LIST) > I think it is not easy to use.So I wish you can add the feature for us. > For example: > 1.Get all producers > 2.Query producer only by topic (don't need groupName) -- 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
[ https://issues.apache.org/jira/browse/ROCKETMQ-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-102: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.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.2.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] [Updated] (ROCKETMQ-106) Add flow control on topic level
[ https://issues.apache.org/jira/browse/ROCKETMQ-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-106: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.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.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.3.15#6346)
[jira] [Updated] (ROCKETMQ-109) View BrokerStats may result in ClassCastException when using store plugin
[
https://issues.apache.org/jira/browse/ROCKETMQ-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-109:
--
Fix Version/s: (was: 4.1.0-incubating)
4.2.0-incubating
> View BrokerStats may result in ClassCastException when using store plugin
> -
>
> Key: ROCKETMQ-109
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-109
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-broker
>Reporter: Jaskey Lam
>Assignee: yukon
> Fix For: 4.2.0-incubating
>
>
> {code}
> private RemotingCommand ViewBrokerStatsData(ChannelHandlerContext ctx,
> RemotingCommand request) throws RemotingCommandException {
> ..//others
> DefaultMessageStore messageStore = (DefaultMessageStore)
> this.brokerController.getMessageStore();//will result in ClassCastException
> when using plugin because plugin is not type of "DefaultMessageStore "
>..//others
> {code}
> I suggest adding a interface "getStatsItem" to MessageStore to avoid type
> cast.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-120) Provide a adapter for spring and spring-boot
[ https://issues.apache.org/jira/browse/ROCKETMQ-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-120: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Provide a adapter for spring and spring-boot > > > Key: ROCKETMQ-120 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-120 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: yukon >Assignee: dongeforever >Priority: Minor > Fix For: 4.2.0-incubating > > > Provider a rocketmq-spring adapter for the convenience of the spring user. -- 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
[ https://issues.apache.org/jira/browse/ROCKETMQ-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-117: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.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.2.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] [Updated] (ROCKETMQ-126) Provide a docker image for RocketMQ
[ https://issues.apache.org/jira/browse/ROCKETMQ-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-126: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > 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 > Fix For: 4.2.0-incubating > > > 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-116) Add Operation Guide
[ https://issues.apache.org/jira/browse/ROCKETMQ-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-116: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Add Operation Guide > --- > > Key: ROCKETMQ-116 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-116 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.2.0-incubating > > > When deploying Apache RocketMQ into production environment, there are a bunch > of parameters to set and options to choose from. We need documentation to > analyze each choice and parameter and benchmark data to support the analysis > in order to achieve various goals. -- 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
[ https://issues.apache.org/jira/browse/ROCKETMQ-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-134: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.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.2.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-166) onException callback may capture compressed message body
[ https://issues.apache.org/jira/browse/ROCKETMQ-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-166: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > onException callback may capture compressed message body > > > Key: ROCKETMQ-166 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-166 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client >Affects Versions: 4.0.0-incubating, 4.1.0-incubating >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.2.0-incubating > > > If message body size exceeds specified threshold, client would try to > compress the message body. > Here there are two issues: 1) current implementation changes message body > directly, which is not a good practice; 2) if asynchronous send method is > employed to deliver message, when onException is invoked, the callback may > capture the compressed message body before the finally block restores it. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-141) Make producers establish connection eagerly to new joined brokers
[ https://issues.apache.org/jira/browse/ROCKETMQ-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-141: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.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.2.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-158) Remove logback dependency for rocketmq-tools
[ https://issues.apache.org/jira/browse/ROCKETMQ-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-158: -- Fix Version/s: (was: 4.1.0-incubating) 4.2.0-incubating > Remove logback dependency for rocketmq-tools > > > Key: ROCKETMQ-158 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-158 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-tools >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > Fix For: 4.2.0-incubating > > > Since user may need to use some admin interfaces to maintain something like > create topic, manage queues. > They will need to use rocketmq-tools which contains DefaultMQAdminExt. > But rocketmq-tools has explicitly depend on logback-classic and logback-core, > which may be conflict with the logging framework of the user's application. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-67) Consistent Hash allocate strategy support
[ https://issues.apache.org/jira/browse/ROCKETMQ-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16030572#comment-16030572 ] dongeforever commented on ROCKETMQ-67: -- [~Jaskey] yeah, it had been merged. you could check the comment upstairs > Consistent Hash allocate strategy support > - > > Key: ROCKETMQ-67 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-67 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: Jaskey Lam >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > For now, the average allocate strategy is very sensitive when clients > register and unrigister. > A Consistent Hash allocate strategy option is valueable for the developers > who care more about latency stabilization and messages duplication. > Intentions: > The default AllocateMessageQueueStrategy is averaging strategy which allocate > queue to consumer as evenly as possible. Whenever queues numbers or consumer > numbers changed, say a new consumer starts or an old consumer shutdowns, a > rehashing will be triggered then almost all consumer suffered from this that > they will rebalance to drop old queues and get new queues. > And that will cause > message latency from producer to consumer increases at the moment when > consumer/queue numbers change, even when they scale up. > messages will be duplicated significantly since the offset may not be > persisted to broker and that queue is assigned to another consumer to pull > messages from. > This is especially significant when they have tens of consumer instances and > scale-up or deployment is often. > Consistent Hash strategy to allocate queue is a good choice for these users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (ROCKETMQ-201) broker-x.properties's attribute which has Space before and after it will get unpredictable values
[ https://issues.apache.org/jira/browse/ROCKETMQ-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reopened ROCKETMQ-201: --- > broker-x.properties's attribute which has Space before and after it will > get unpredictable values > > > Key: ROCKETMQ-201 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-201 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-commons >Affects Versions: 4.1.0-incubating, 4.2.0-incubating, 4.3.0-incubating > Environment: all jdk version >Reporter: huangyiminghappy >Assignee: Jixiang Jin >Priority: Minor > Labels: features > Fix For: 4.1.0-incubating > > Attachments: 1.png, 2.png, 3.png, 4.png > > Original Estimate: 1h > Remaining Estimate: 1h > > the properties's attributes have spaces before and after ,it will get an Not > expected value, Numeric possible type conversion error，but The string may get > a bug that is not expected,Very difficult to troubleshoot,so need to resolve > it -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-88) Polish the developer list in pom.xml
[ https://issues.apache.org/jira/browse/ROCKETMQ-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-88. > 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] [Resolved] (ROCKETMQ-88) Polish the developer list in pom.xml
[ https://issues.apache.org/jira/browse/ROCKETMQ-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever resolved ROCKETMQ-88. -- Resolution: Fixed > 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-160) SendHeartBeart log may not be triggered in the same expected period
[
https://issues.apache.org/jira/browse/ROCKETMQ-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-160.
-
> SendHeartBeart log may not be triggered in the same expected period
> ---
>
> Key: ROCKETMQ-160
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-160
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-client
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> {code}
> private void sendHeartbeatToAllBroker() {
> final HeartbeatData heartbeatData = this.prepareHeartbeatData();
> final boolean producerEmpty =
> heartbeatData.getProducerDataSet().isEmpty();
> final boolean consumerEmpty =
> heartbeatData.getConsumerDataSet().isEmpty();
> if (producerEmpty && consumerEmpty) {
> log.warn("sending heartbeat, but no consumer and no producer");
> return;
> }
> long times = this.storeTimesTotal.getAndIncrement();//here every time
> when the method is call, the times will increase even though acatully no
> heartbeat is sent
> Iterator>> it =
> this.brokerAddrTable.entrySet().iterator();
> while (it.hasNext()) {
> Entry> entry = it.next();
> String brokerName = entry.getKey();
> HashMap oneTable = entry.getValue();
> if (oneTable != null) {
> for (Map.Entry entry1 : oneTable.entrySet()) {
> Long id = entry1.getKey();
> String addr = entry1.getValue();
> if (addr != null) {
> if (consumerEmpty) {
> if (id != MixAll.MASTER_ID)
> continue;
> }
> try {
> this.mQClientAPIImpl.sendHearbeat(addr,
> heartbeatData, 3000);
> if (times % 20 == 0) {//since the first call is
> times !=1, the heart beat log for the first heart beat could be missed
> log.info("send heart beat to broker[{} {} {}]
> success", brokerName, id, addr);
> log.info(heartbeatData.toString());
> }
> } catch (Exception e) {
> if (this.isBrokerInNameServer(addr)) {
> log.error("send heart beat to broker
> exception", e);
> } else {
> log.info("send heart beat to broker[{} {} {}]
> exception, because the broker not up, forget it", brokerName,
> id, addr);
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-98) Risk of unable to release putMessage Lock forever
[
https://issues.apache.org/jira/browse/ROCKETMQ-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-98.
> Risk of unable to release putMessage Lock forever
> -
>
> Key: ROCKETMQ-98
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-98
> Project: Apache RocketMQ
> Issue Type: Bug
>Affects Versions: 4.1.0-incubating
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
> Fix For: 4.1.0-incubating
>
>
> In current implemenation, there are two kind of locks dev can choose. If I
> choose reentrantLock, and lock it then put message, in this time I change the
> config through admin interface to use spin lock. When trying to unlock,
> rocketmq will try to unlock the spin lock though actually the reentrantlock
> is locked, this will cause the reentrantlock not able to release forever and
> trying to release the wrong spin lock but actully it is not locked!
> /**
> * 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);
> }
> }
> private void releasePutMessageLock() {
> if
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
> {
> putMessageNormalLock.unlock();
> } else {
> this.putMessageSpinLock.compareAndSet(false, true);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-67) Consistent Hash allocate strategy support
[ https://issues.apache.org/jira/browse/ROCKETMQ-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-67. > Consistent Hash allocate strategy support > - > > Key: ROCKETMQ-67 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-67 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: Jaskey Lam >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > For now, the average allocate strategy is very sensitive when clients > register and unrigister. > A Consistent Hash allocate strategy option is valueable for the developers > who care more about latency stabilization and messages duplication. > Intentions: > The default AllocateMessageQueueStrategy is averaging strategy which allocate > queue to consumer as evenly as possible. Whenever queues numbers or consumer > numbers changed, say a new consumer starts or an old consumer shutdowns, a > rehashing will be triggered then almost all consumer suffered from this that > they will rebalance to drop old queues and get new queues. > And that will cause > message latency from producer to consumer increases at the moment when > consumer/queue numbers change, even when they scale up. > messages will be duplicated significantly since the offset may not be > persisted to broker and that queue is assigned to another consumer to pull > messages from. > This is especially significant when they have tens of consumer instances and > scale-up or deployment is often. > Consistent Hash strategy to allocate queue is a good choice for these users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ROCKETMQ-67) Consistent Hash allocate strategy support
[ https://issues.apache.org/jira/browse/ROCKETMQ-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever resolved ROCKETMQ-67. -- Resolution: Fixed > Consistent Hash allocate strategy support > - > > Key: ROCKETMQ-67 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-67 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: Jaskey Lam >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > For now, the average allocate strategy is very sensitive when clients > register and unrigister. > A Consistent Hash allocate strategy option is valueable for the developers > who care more about latency stabilization and messages duplication. > Intentions: > The default AllocateMessageQueueStrategy is averaging strategy which allocate > queue to consumer as evenly as possible. Whenever queues numbers or consumer > numbers changed, say a new consumer starts or an old consumer shutdowns, a > rehashing will be triggered then almost all consumer suffered from this that > they will rebalance to drop old queues and get new queues. > And that will cause > message latency from producer to consumer increases at the moment when > consumer/queue numbers change, even when they scale up. > messages will be duplicated significantly since the offset may not be > persisted to broker and that queue is assigned to another consumer to pull > messages from. > This is especially significant when they have tens of consumer instances and > scale-up or deployment is often. > Consistent Hash strategy to allocate queue is a good choice for these users. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ROCKETMQ-98) Risk of unable to release putMessage Lock forever
[
https://issues.apache.org/jira/browse/ROCKETMQ-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever resolved ROCKETMQ-98.
--
Resolution: Fixed
> Risk of unable to release putMessage Lock forever
> -
>
> Key: ROCKETMQ-98
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-98
> Project: Apache RocketMQ
> Issue Type: Bug
>Affects Versions: 4.1.0-incubating
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
> Fix For: 4.1.0-incubating
>
>
> In current implemenation, there are two kind of locks dev can choose. If I
> choose reentrantLock, and lock it then put message, in this time I change the
> config through admin interface to use spin lock. When trying to unlock,
> rocketmq will try to unlock the spin lock though actually the reentrantlock
> is locked, this will cause the reentrantlock not able to release forever and
> trying to release the wrong spin lock but actully it is not locked!
> /**
> * 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);
> }
> }
> private void releasePutMessageLock() {
> if
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
> {
> putMessageNormalLock.unlock();
> } else {
> this.putMessageSpinLock.compareAndSet(false, true);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ROCKETMQ-160) SendHeartBeart log may not be triggered in the same expected period
[
https://issues.apache.org/jira/browse/ROCKETMQ-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever resolved ROCKETMQ-160.
---
Resolution: Fixed
> SendHeartBeart log may not be triggered in the same expected period
> ---
>
> Key: ROCKETMQ-160
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-160
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-client
>Reporter: Jaskey Lam
>Assignee: Jaskey Lam
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> {code}
> private void sendHeartbeatToAllBroker() {
> final HeartbeatData heartbeatData = this.prepareHeartbeatData();
> final boolean producerEmpty =
> heartbeatData.getProducerDataSet().isEmpty();
> final boolean consumerEmpty =
> heartbeatData.getConsumerDataSet().isEmpty();
> if (producerEmpty && consumerEmpty) {
> log.warn("sending heartbeat, but no consumer and no producer");
> return;
> }
> long times = this.storeTimesTotal.getAndIncrement();//here every time
> when the method is call, the times will increase even though acatully no
> heartbeat is sent
> Iterator>> it =
> this.brokerAddrTable.entrySet().iterator();
> while (it.hasNext()) {
> Entry> entry = it.next();
> String brokerName = entry.getKey();
> HashMap oneTable = entry.getValue();
> if (oneTable != null) {
> for (Map.Entry entry1 : oneTable.entrySet()) {
> Long id = entry1.getKey();
> String addr = entry1.getValue();
> if (addr != null) {
> if (consumerEmpty) {
> if (id != MixAll.MASTER_ID)
> continue;
> }
> try {
> this.mQClientAPIImpl.sendHearbeat(addr,
> heartbeatData, 3000);
> if (times % 20 == 0) {//since the first call is
> times !=1, the heart beat log for the first heart beat could be missed
> log.info("send heart beat to broker[{} {} {}]
> success", brokerName, id, addr);
> log.info(heartbeatData.toString());
> }
> } catch (Exception e) {
> if (this.isBrokerInNameServer(addr)) {
> log.error("send heart beat to broker
> exception", e);
> } else {
> log.info("send heart beat to broker[{} {} {}]
> exception, because the broker not up, forget it", brokerName,
> id, addr);
> }
> }
> }
> }
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-200) Cluster name is always missing when fetch ClusterInfo from name server
[ https://issues.apache.org/jira/browse/ROCKETMQ-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-200. - Resolution: Fixed > Cluster name is always missing when fetch ClusterInfo from name server > -- > > Key: ROCKETMQ-200 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-200 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-namesrv >Affects Versions: 4.1.0-incubating >Reporter: Jaskey Lam >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > There are some BrokerData in the ClusterInfo, while the clsuter in the > BrokerData is always null since the cluster info is never set when create > this instance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-188) RemotingExecption is not consistent between invoke async and invoke oneway
[ https://issues.apache.org/jira/browse/ROCKETMQ-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-188. - Resolution: Fixed > RemotingExecption is not consistent between invoke async and invoke oneway > -- > > Key: ROCKETMQ-188 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-188 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-remoting >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > Fix For: 4.1.0-incubating > > > For existing invoke oneway code base, RemotingTooMuchRequestException will be > thrown only when timeout millis <0, otherwise, RemotingTimeoutException will > be thrown. > But in invokeAsync, RemotingTooMuchRequestException is always thrown no > matter what value the timeout millis , which is inconsistent. Besides, the > RemotingTimeoutException is declared in the signature but it will be never > thrown. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-206) Load JSON config file error if non-1byte character exists
[
https://issues.apache.org/jira/browse/ROCKETMQ-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-206.
-
Resolution: Fixed
this has been merged from branch ROCKETMQ-206
> 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] [Closed] (ROCKETMQ-189) Misleading tip on consumeTimestamp and wrong consumeTimestamp exception message
[
https://issues.apache.org/jira/browse/ROCKETMQ-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-189.
-
Resolution: Fixed
> Misleading tip on consumeTimestamp and wrong consumeTimestamp exception
> message
> ---
>
> Key: ROCKETMQ-189
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-189
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-client
>Affects Versions: 4.0.0-incubating
> Environment: macos,jdk8
>Reporter: lindzh
>Assignee: Xiaorui Wang
> Labels: easyfix
> Fix For: 4.1.0-incubating
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> When I want to consume message,I use the following code,
> {quote}
> consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
> consumer.setConsumeTimestamp("2017_0422_235500");
> {quote}
> and I got the tip as following:
> {quote}
> Exception in thread "main"
> org.apache.rocketmq.client.exception.MQClientException: consumeTimestamp is
> invalid, _MMDD_HHMMSS
> See http://rocketmq.apache.org/docs/faq/ for further details.
> at
> org.apache.rocketmq.client.impl.consumer.DefaultMQPushConsumerImpl.checkConfig(DefaultMQPushConsumerImpl.java:661)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-194) log appender useing rocketmq
[ https://issues.apache.org/jira/browse/ROCKETMQ-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-194. - Resolution: Fixed > log appender useing rocketmq > > > Key: ROCKETMQ-194 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-194 > Project: Apache RocketMQ > Issue Type: New Feature >Affects Versions: 4.1.0-incubating > Environment: jdk7 >Reporter: lindzh >Assignee: vongosling > Labels: features > Fix For: 4.1.0-incubating > > Original Estimate: 72h > Remaining Estimate: 72h > > As Rocketmq is widely used,A log appender is also necessary. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-175) Consumer may miss messages because of inconsistent subscription
[ https://issues.apache.org/jira/browse/ROCKETMQ-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-175. - Resolution: Fixed > Consumer may miss messages because of inconsistent subscription > --- > > Key: ROCKETMQ-175 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-175 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-broker >Affects Versions: 4.0.0-incubating >Reporter: Eric Liu >Assignee: Eric Liu > Fix For: 4.1.0-incubating > > > When consumers in one group have different subscriptions(with tag), broker > will select the one has latest client version. Although when this consumer > shutdown, broker would not update the subscription until someone in group > restart, so other consumers will miss messages by the dead consumer's tag. > Broker should refresh the group's subscriptions when someone was off-line. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-178) Broker -m -p options are broken
[ https://issues.apache.org/jira/browse/ROCKETMQ-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-178. - Resolution: Fixed > Broker -m -p options are broken > --- > > Key: ROCKETMQ-178 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-178 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-broker >Affects Versions: 4.1.0-incubating >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.1.0-incubating > > > Broker command line are supposed to support -m -p options to print out > important settings. Now the logger is set as null, thus, no output at all. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-39) Duplicated codes in both filtersrv and namesrv modules
[
https://issues.apache.org/jira/browse/ROCKETMQ-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-39.
> Duplicated codes in both filtersrv and namesrv modules
> --
>
> Key: ROCKETMQ-39
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-39
> Project: Apache RocketMQ
> Issue Type: Improvement
> Components: rocketmq-namesrv
>Reporter: Wu Sheng
>Assignee: Xiaorui Wang
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> In FiltersrvStartup.class and NamesrvStartup.class, exist the exact same code
> about add jvm shutdown hook, and execute somthing on shutting down.
> Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
> private volatile boolean hasShutdown = false;
> private AtomicInteger shutdownTimes = new AtomicInteger(0);
> @Override
> public void run() {
> synchronized (this) {
> log.info("shutdown hook was invoked, " +
> this.shutdownTimes.incrementAndGet());
> if (!this.hasShutdown) {
> this.hasShutdown = true;
> long begineTime = System.currentTimeMillis();
> controller.shutdown();
> long consumingTimeTotal =
> System.currentTimeMillis() - begineTime;
> log.info("shutdown hook over, consuming time
> total(ms): " + consumingTimeTotal);
> }
> }
> }
> }, "ShutdownHook"));
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-41) Streaming data to Apache Ignite (integration)
[ https://issues.apache.org/jira/browse/ROCKETMQ-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-41. > 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-121) Support message filtering based on SQL92
[ https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-121: -- Issue Type: New Feature (was: Wish) > Support message filtering based on SQL92 > > > Key: ROCKETMQ-121 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-121 > Project: Apache RocketMQ > Issue Type: New Feature > 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] [Closed] (ROCKETMQ-121) Support message filtering based on SQL92
[ https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-121. - Resolution: Fixed > Support message filtering based on SQL92 > > > Key: ROCKETMQ-121 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-121 > Project: Apache RocketMQ > Issue Type: New Feature > 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] [Reopened] (ROCKETMQ-121) Support message filtering based on SQL92
[ https://issues.apache.org/jira/browse/ROCKETMQ-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reopened ROCKETMQ-121: --- > 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] [Closed] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-17.
Resolution: Won't Fix
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-17.
Resolution: Fixed
has been removed to another repository
https://github.com/openmessaging/openmessaging
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever reopened ROCKETMQ-17:
--
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-114) Add javadoc to codebase
[ https://issues.apache.org/jira/browse/ROCKETMQ-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-114. - Resolution: Fixed Github user lizhanhui closed the pull request at: https://github.com/apache/incubator-rocketmq/pull/80 > 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] [Closed] (ROCKETMQ-168) Duplicated calls of life cycle in Maven.
[
https://issues.apache.org/jira/browse/ROCKETMQ-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-168.
-
Resolution: Fixed
This issue has been resolved in `develop` branch, the quick start[1] guide
should be adjusted when develop branch merged to master.
[1]. http://rocketmq.apache.org/docs/quick-start/
> Duplicated calls of life cycle in Maven.
>
>
> Key: ROCKETMQ-168
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-168
> Project: Apache RocketMQ
> Issue Type: Improvement
>Affects Versions: 4.0.0-incubating
>Reporter: Karl Heinz Marbaise
>Assignee: yukon
>Priority: Minor
> Fix For: 4.1.0-incubating
>
>
> Current the [build
> documentation|http://rocketmq.incubator.apache.org/docs/quick-start/] states
> to build via:
> {code}
> mvn clean package install -Prelease-all assembly:assembly -U
> {code}
> Only the following is neccessary:
> {code}
> mvn clean install -Prelease-all assembly:assembly -U
> {code}
> otherwise several parts of the build life cycle are repeated...furthermore
> the questions is why you use a call to {{assembly:assembly}} which is
> deprecated and best it should be done simply by using:
> {code}
> mvn clean deploy -Prelease-all
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-78) Prepare and place Dockerfile under incubator-rocketmq/
[
https://issues.apache.org/jira/browse/ROCKETMQ-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-78:
-
Fix Version/s: (was: 4.2.0-incubating)
4.1.0-incubating
> 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
> Fix For: 4.1.0-incubating
>
>
> {{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] [Closed] (ROCKETMQ-161) Update runbroker.sh and runserver.sh to support user defined jvm memory flag
[
https://issues.apache.org/jira/browse/ROCKETMQ-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-161.
-
Resolution: Fixed
Github user dongeforever closed the pull request at:
https://github.com/apache/incubator-rocketmq/pull/87
> Update runbroker.sh and runserver.sh to support user defined jvm memory flag
>
>
> Key: ROCKETMQ-161
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-161
> Project: Apache RocketMQ
> Issue Type: Improvement
>Reporter: dongeforever
>Assignee: dongeforever
> Fix For: 4.1.0-incubating
>
>
> JVM mem flag is hard coded in runbroker.sh as follows:
> JAVA_OPT="${JAVA_OPT} -server -Xms8g -Xmx8g -Xmn4g"
> If one want to change such flag, he has to change the script, this is not
> friendly, especially in docker environment.
> Instead, it is able to use an environment variable to handle user defined
> flag, like:
> if [ -z $BROKER_MEM_OPS ]; then
> BROKER_MEM_OPS = "-Xms8g -Xmx8g -Xmn4g"
> fi
> JAVA_OPT="${JAVA_OPT} -server $BROKER_MEM_OPS"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-172) log improvement for rocketmq client
[ https://issues.apache.org/jira/browse/ROCKETMQ-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-172. - Resolution: Fixed Github user Jaskey closed the pull request at: https://github.com/apache/incubator-rocketmq/pull/90 > log improvement for rocketmq client > --- > > Key: ROCKETMQ-172 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-172 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-client >Reporter: Jaskey Lam >Assignee: Jaskey Lam > Fix For: 4.1.0-incubating > > > For some exception scenario, the log is not abundant enough to diagnose the > problem. > Some works should be done to improve the log messages -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-179) Fix errors of test cases
[ https://issues.apache.org/jira/browse/ROCKETMQ-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-179. - Resolution: Fixed Github user vsair closed the pull request at: https://github.com/apache/incubator-rocketmq/pull/94 > Fix errors of test cases > > > Key: ROCKETMQ-179 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-179 > Project: Apache RocketMQ > Issue Type: Bug >Reporter: Eric Liu >Assignee: Eric Liu >Priority: Minor > Fix For: 4.1.0-incubating > > > Some TC may not pass because of code mistakes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-186) Implement the OpenMessaging specification 0.1.0-alpha version
[ https://issues.apache.org/jira/browse/ROCKETMQ-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever closed ROCKETMQ-186. - Resolution: Fixed has merged in: https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=1d966b5 > Implement the OpenMessaging specification 0.1.0-alpha version > - > > Key: ROCKETMQ-186 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-186 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: yukon >Assignee: yukon > Fix For: 4.1.0-incubating > > > Open-Messaging, which includes the establishment of industry guidelines and > messaging, streaming specifications to provide a common framework for > finance, e-commerce, IoT and big-data area. The design principles are the > cloud-oriented, simplicity, flexibility, and language independent in > distributed heterogeneous environments. Conformance to these specifications > will make it possible to develop a heterogeneous messaging applications > across all major platforms and operating systems. > And OMS has released the 0.1.0 alpha version recently, rocketmq will > implement it soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-186) Implement the OpenMessaging specification 0.1.0-alpha version
[ https://issues.apache.org/jira/browse/ROCKETMQ-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16024397#comment-16024397 ] dongeforever commented on ROCKETMQ-186: --- has merged in: https://git-wip-us.apache.org/repos/asf?p=incubator-rocketmq.git;h=1d966b5 > Implement the OpenMessaging specification 0.1.0-alpha version > - > > Key: ROCKETMQ-186 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-186 > Project: Apache RocketMQ > Issue Type: New Feature > Components: rocketmq-client >Reporter: yukon >Assignee: yukon > Fix For: 4.1.0-incubating > > > Open-Messaging, which includes the establishment of industry guidelines and > messaging, streaming specifications to provide a common framework for > finance, e-commerce, IoT and big-data area. The design principles are the > cloud-oriented, simplicity, flexibility, and language independent in > distributed heterogeneous environments. Conformance to these specifications > will make it possible to develop a heterogeneous messaging applications > across all major platforms and operating systems. > And OMS has released the 0.1.0 alpha version recently, rocketmq will > implement it soon. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ROCKETMQ-36) Improve broker's GC logs storing
[
https://issues.apache.org/jira/browse/ROCKETMQ-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever closed ROCKETMQ-36.
Resolution: Fixed
solved with PR: https://github.com/apache/incubator-rocketmq/pull/87
> 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] [Assigned] (ROCKETMQ-120) Provide a adapter for spring and spring-boot
[ https://issues.apache.org/jira/browse/ROCKETMQ-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever reassigned ROCKETMQ-120: - Assignee: dongeforever Fix Version/s: 4.1.0-incubating > Provide a adapter for spring and spring-boot > > > Key: ROCKETMQ-120 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-120 > Project: Apache RocketMQ > Issue Type: Wish >Reporter: yukon >Assignee: dongeforever >Priority: Minor > Fix For: 4.1.0-incubating > > > Provider a rocketmq-spring adapter for the convenience of the spring user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-81) Add the RocketMq plugin for the Apache Spark
[ https://issues.apache.org/jira/browse/ROCKETMQ-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-81: - Fix Version/s: 4.2.0-incubating > Add the RocketMq plugin for the Apache Spark > > > Key: ROCKETMQ-81 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-81 > Project: Apache RocketMQ > Issue Type: Task > Components: rocketmq-externals >Affects Versions: 4.1.0-incubating >Reporter: Longda Feng >Assignee: Xin Wang >Priority: Minor > Fix For: 4.2.0-incubating > > > Since the Apache RocketMq 4.0 will be released in the next few days, we can > start the job of adding the RocketMq plugin for the Apache Spark. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-202) Using native transport
[ https://issues.apache.org/jira/browse/ROCKETMQ-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-202: -- Fix Version/s: 4.1.0-incubating > Using native transport > -- > > Key: ROCKETMQ-202 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-202 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-remoting >Reporter: Zhanhui Li >Assignee: Zhanhui Li >Priority: Minor > Fix For: 4.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-193) Develop rocketmq-redis-replicator component
[ https://issues.apache.org/jira/browse/ROCKETMQ-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-193: -- Fix Version/s: 4.2.0-incubating > Develop rocketmq-redis-replicator component > --- > > Key: ROCKETMQ-193 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-193 > Project: Apache RocketMQ > Issue Type: Task >Reporter: Rich Zhang >Assignee: Rich Zhang >Priority: Minor > Fix For: 4.2.0-incubating > > > Design: > Redis supplies an official replication mechanism , and slave communicates > to master with RESP protocol, so a natural way to design the > rocketmq-redis-replicator component is simulating itself as a slave, sending > commands to master and receiving datas from master timely, and then resending > to rocketmq broker. > If you are not familiar with redis replication mechanism, please learn this > section first [1]. After that, I will illustrate some key points ahead. > 1. To make slave start from the point where it left off when it reconnects, > slave and master should agree on a master runId and a replication offset. > Slave acknowledges this offset to master periodically. In other words，slave > may received duplicate commands. Along with, the rocketmq-redis-replicator > component may send duplicate messages too. A good way to minimize the > duplicate time window is reducing the "ack period" to a smaller one, such as > 100ms. > 2. If slave keeps offline for some time, it’s easy to use up backlog whose > default value is just 1M, especially for a high-traffic redis instance. > Unfortunatelly,if slave replication offset has already been covered in master > backlog, a full synchronization will have to execute, which is unacceptable > for rocketmq-redis-replicator component as a large number of messages will be > sent out intensively. > 3. When synchronizing from master fully, master will generate a new rdb > file(the rdb file format [2])，and slave will receive this file,store in disk, > and last apply to memory. This strategy makes slave reaches a consistent > state with master as soon as possible, and hardly fail. For > rocketmq-redis-replicator component, it’s also a good way to prevent > synchronizing initial rdb file from failure in halfway. > There already an open source project [3] which focuses on replicating redis > data, and provides api to handle data received [4]. The principal thoughts > are simulating itself as a slave , following official replication procedure, > communicating with master by RESP, and acking master with replication offset. > Base on this project to develop is a good idea, meanwhile some aspects should > also be enhanced and considered more robust. Here is some points: > [High Available] >Keeping the replication component's high availability is not difficult but > important, not only for providing an uninterruptible service. If component > leaves off for some time, a unacceptable full synchronization may be > triggered. >It’s also easy to reach high availability, including adopting master/slave > module, using zookeeper to coordinate and switch master/slave, storing data > onto zookeeper to keep component stateless. > [Data Loss] >Generally, data loss should be tried best to avoid. The key point is that > slave only acks replication offset to master after sending command to > rocketmq broker successfully. > [Data Stale] >It also happened when slave reconnect. Consider case below: >`time1` `time2` `time3` >set k=a set k=b set k=c >If slave left off at time3, but the latest replication offset reported to > master is only at time1, when slave reconnected, it re-apply commands “set > k=b… set k=c”. In a small time window, “k” will equal the stale “b” until > “set k=c” command is applied. So the slave offline time shorter, the better. >[Message Order] >Redis uses single thread model to keep command execute in order, because > of its high performance. Replicating data with a single thread in slave is > also fine, as it is also totally memory operation. But sending all data to > rocketmq in a global order is a good choose? Producer should have no > performance issue, but consumer may not be able to consume messages in time, > especially redis was in a high load. >Hashing “KEY” to different rocketmq queue is a good strategy. Guarantee > the same key operation route to a unique queue, to keep partial ordered, and > the downstream consumer could consume messages concurrently. Of course, some > dependency “KEY”s may need hash to a unique queue too. We should supply > configuration or api to support this individuation. >[Transaction] > Redis supports simple transaction. A transaction starts with a
[jira] [Updated] (ROCKETMQ-126) Provide a docker image for RocketMQ
[ https://issues.apache.org/jira/browse/ROCKETMQ-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-126: -- Fix Version/s: 4.1.0-incubating > 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 > Fix For: 4.1.0-incubating > > > 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-122) Support global order messaging mechanism without hot-points problem
[ https://issues.apache.org/jira/browse/ROCKETMQ-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-122: -- Fix Version/s: 4.2.0-incubating > Support global order messaging mechanism without hot-points problem > --- > > Key: ROCKETMQ-122 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-122 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker, rocketmq-client, rocketmq-store >Reporter: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > As we know, messages in the same queue can be consumed sequentially. So we > always send the congeneric messages to the same queue to guarantee ordering, > which will cause hot-point issue. > So It's cool if we support a new global order messaging mechanism, without > hot-points problem. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-188) RemotingExecption is not consistent between invoke async and invoke oneway
[ https://issues.apache.org/jira/browse/ROCKETMQ-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-188: -- Fix Version/s: 4.2.0-incubating > RemotingExecption is not consistent between invoke async and invoke oneway > -- > > Key: ROCKETMQ-188 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-188 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-remoting >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > Fix For: 4.2.0-incubating > > > For existing invoke oneway code base, RemotingTooMuchRequestException will be > thrown only when timeout millis <0, otherwise, RemotingTimeoutException will > be thrown. > But in invokeAsync, RemotingTooMuchRequestException is always thrown no > matter what value the timeout millis , which is inconsistent. Besides, the > RemotingTimeoutException is declared in the signature but it will be never > thrown. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-66) Manage the %DLQ% Queue
[ https://issues.apache.org/jira/browse/ROCKETMQ-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-66: - Fix Version/s: 4.2.0-incubating > Manage the %DLQ% Queue > -- > > Key: ROCKETMQ-66 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-66 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker >Reporter: Jie.Tang >Assignee: yukon >Priority: Minor > Fix For: 4.2.0-incubating > > > I have a problem whether we need to change the %DLQ% Queue perm or not(from 2 > to 6.) > In 3.5.8 the %DLQ% Queue perm is 2,only writable,but I want to read it > because I want to know how many message is in the %DLQ% queue, which message > has problem and why it can't be consume . > I want to query the problem message(%DLQ% Queue Message) in > rocketMq-console,but because of the perm,I can't. > I need to change the perm from 2 to 6 before I query it. > Could you help me to solvle this? Thank you. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-79) Add one RocketMQ plugin for the Apache Storm
[ https://issues.apache.org/jira/browse/ROCKETMQ-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-79: - Fix Version/s: 4.2.0-incubating > Add one RocketMQ plugin for the Apache Storm > > > Key: ROCKETMQ-79 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-79 > Project: Apache RocketMQ > Issue Type: Task > Components: rocketmq-externals >Affects Versions: 4.1.0-incubating >Reporter: Longda Feng >Assignee: Xin Wang >Priority: Minor > Fix For: 4.2.0-incubating > > > Since the Apache RocketMq 4.0 will be released in the next few days, we can > start the job that adding the RocketMq plugin for the Apache Storm. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-82) Add the RocketMQ plugin for the Apache Flink
[ https://issues.apache.org/jira/browse/ROCKETMQ-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-82: - Fix Version/s: 4.2.0-incubating > 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 > Fix For: 4.2.0-incubating > > > 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] [Updated] (ROCKETMQ-105) Implementation of consumerOffset and maxOffset are counter-intuitive
[ https://issues.apache.org/jira/browse/ROCKETMQ-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-105: -- Fix Version/s: 4.1.0-incubating > Implementation of consumerOffset and maxOffset are counter-intuitive > > > Key: ROCKETMQ-105 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-105 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-broker, rocketmq-client, rocketmq-store >Affects Versions: 4.0.0-incubating >Reporter: Jaskey Lam >Assignee: yukon >Priority: Minor > Fix For: 4.1.0-incubating > > > This issue does not affect any functionalites, but it indeed is a problem for > user to understand the principle of RocketMQ. > - ConsumerOffset: > User might consider `ConsumerOffset` is the offset where consumer has > consumed. for example if CG1 have a consumer offset 100 of topicA-q1, I may > propabaly consider message with offset 100 has been cosumed. But actully, it > is not. The message with offset 100 is the next target offset to pull from. > - Max Offset > User might consider this is the offset of the latest message in a queue. But > it is not, it is indicating that next offset when new message arrived. > > If possible , any of the below two things should be taken into consideration > 1. the implementation should be changed to be closer to presentative judgment > of human > 2. rename the concept to clarify how it really implemented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-187) Measure the code coverage for Integration Tests
[ https://issues.apache.org/jira/browse/ROCKETMQ-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-187: -- Fix Version/s: 4.1.0-incubating > Measure the code coverage for Integration Tests > --- > > Key: ROCKETMQ-187 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-187 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: dongeforever >Assignee: dongeforever > Fix For: 4.1.0-incubating > > > Now we could browse the Unit Tests and IT Tests at > https://builds.apache.org/analysis/component_measures/?id=org.apache.rocketmq%3Arocketmq-all > But the IT Test coverage is not correct. It should cover the original sources > instead of the the classes in test module. > As for as I known, the coverage report is generated by matching the > collected data(often using java agent) against a set of classes (the module > classes compiled from src/main/). you could refer to: > http://olafsblog.sysbsb.de/measuring-test-coverage-of-integration-tests-for-separated-modules-with-jacoco/ > So we could match the jacoco-it.exec to each module's source classes to get > the correct IT coverage report. > By the way, we'd better exclude the classes in the test module. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-17) Develop a client api open standard for distributed messaging service
[
https://issues.apache.org/jira/browse/ROCKETMQ-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dongeforever updated ROCKETMQ-17:
-
Fix Version/s: 4.1.0-incubating
> Develop a client api open standard for distributed messaging service
>
>
> Key: ROCKETMQ-17
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-17
> Project: Apache RocketMQ
> Issue Type: New Feature
>Affects Versions: 4.1.0-incubating
>Reporter: Xiaorui Wang
>Assignee: Xiaorui Wang
> Fix For: 4.1.0-incubating
>
>
> *Openmessaging*
> Openmessaging is a redefinition of the application of the access message
> service programming API standard. It is only API, non wire-level protocol.
> Openmessaging covers large data message processing, stream computing message
> processing, the traditional transaction model of message processing.
> Openmessaging provides API for all major programming languages, such as Java,
> dotnet, CPP, go, python, nodejs, PHP, etc..
> *openrelay*
> openrelay is a messaging service call through to simulate a API programming
> standard, because it's service provider is more like a message consumer, so
> there is no need to listen port, communication with the broker via the
> reverse proxy mode, therefore it can make two pass through the network not to
> penetrate the news network, and the use of and like the most simple service
> call.
> Openrelay only defines the programming API standard, which is also cross
> language, including Java, dotnet, CPP, go, python, nodejs, PHP, etc., which
> does not contain wire level protocols.
> *Why should provide the set of openmessaging programming API
> standard?*
> We hope to have more users to use rocketmq, these users including CPP,
> dotnet, Java and other programmers, we know that the programmer in the
> selection of a basic middleware, especially concerns one day in the future if
> there is a better product or the selected product is not good enough, how can
> not change the cable has a large number of applications on the code next,
> moving to new products. With openmessaging, at least to provide users with a
> way to regret, so there may be more users choose to use openmessaging to
> access rocketmq. Because openmessaging is a product of independent
> programming of API, we believe that the open source community there will be
> more people involved, through to other products, such as ActiveMQ, Kafka,
> RabbitMQ with openmessaging implementation, even through openmessaging and
> HBase, Hadoop, storm, integration, as long as the realization of time, may be
> able to run at all news product.
> {color:red}
> This is our original intention to design openmessaging and openrelay.
> {color}
> *RocketMQ will be the first to support openmessaging and openrelay standards*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-116) Add Operation Guide
[ https://issues.apache.org/jira/browse/ROCKETMQ-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dongeforever updated ROCKETMQ-116: -- Fix Version/s: 4.1.0-incubating > Add Operation Guide > --- > > Key: ROCKETMQ-116 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-116 > Project: Apache RocketMQ > Issue Type: Improvement >Reporter: Zhanhui Li >Assignee: Zhanhui Li > Fix For: 4.1.0-incubating > > > When deploying Apache RocketMQ into production environment, there are a bunch > of parameters to set and options to choose from. We need documentation to > analyze each choice and parameter and benchmark data to support the analysis > in order to achieve various goals. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
