[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904636#comment-15904636
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user vongosling commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
cool~
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-130) Support depth control by topic level
[ https://issues.apache.org/jira/browse/ROCKETMQ-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eason Chen updated ROCKETMQ-130: Component/s: rocketmq-broker > Support depth control by topic level > > > Key: ROCKETMQ-130 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-130 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-broker >Reporter: Eason Chen >Assignee: vongosling > > Faster producer topic will impact slower producer topic when they are in the > same broker, so we need depth control to limit the faster guy. -- 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=15904410#comment-15904410 ] ASF GitHub Bot commented on ROCKETMQ-67: Github user Jaskey commented on the issue: https://github.com/apache/incubator-rocketmq/pull/67 @shroman The detail descriptions has been updated to JIRA. I will try described as detail as possible when I create an issue in JIRA in the future. > 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] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904398#comment-15904398
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user lizhanhui commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
@shroman client/common/remoting
Frankly speaking, it's kind of dilemma. pom.xml has already defined Java
language version to 1.7 and JREs under 1.7 are no longer maintained by Oracle
and other vendors; But the reality is many application developers are stilling
working on legacy systems which requires Java 1.5, 1.6.
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904393#comment-15904393
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user shroman commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
@lizhanhui which modules in RocketMQ are 'client-related'? to be aware when
changing the code.
Ideally, it would be nice to split the client-related code with what we are
doing at Apache. Just my thoughts.
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904385#comment-15904385
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user lizhanhui commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
Agree, for the client related module, I think it's best to have maximum
compatibility as many application developers are still working on legacy
systems.
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904384#comment-15904384
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user shroman commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
@vongosling Is it for `rocketmq-remoting` only or for the whole project?
It doesn't sound exciting to go back to old JDKs, but ok :)
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
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=15904358#comment-15904358 ] ASF GitHub Bot commented on ROCKETMQ-67: Github user shroman commented on the issue: https://github.com/apache/incubator-rocketmq/pull/67 @Jaskey This is a very good description, and now reviewers will understand well your intentions :) If you clearly state your intentions in JIRA, or discuss in the ml, it saves much time, and good for the record. Sorry, it's not a code review yet, just wanted understand your intentions. > 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 is valueable for the developer who cares > more about stabilization than averaging. > This option should be supported. And averaging should be meet as much as > possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904350#comment-15904350
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user vongosling commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
@shroman Recently, some our customer resort to us to degrade JDK version to
1.6. IMO, we can keep the pace with netty for our SDK. So, if we polish code
associating with SDK, we'd better use JDK 1.6 semantic :-)
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
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=15904341#comment-15904341 ] ASF GitHub Bot commented on ROCKETMQ-67: Github user Jaskey commented on the issue: https://github.com/apache/incubator-rocketmq/pull/67 @shroman This is feature to give choice to users who cares more about latency stabilization and messages duplication. As you know, the default `AllocateMessageQueueStrategy` is averaging strategy which allocate queue to consumer as evenly as possible. But as you states whenever queues numbers or consumer numbers changed, say a new consumer starts or an old consumer shutdown, a rehashing will be triggered and almost all consumer suffered from this and they rebalance to drop old queues and get new queue. This will cause 1. message latency from producer to consumer increases at that moment 2. 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. > 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 is valueable for the developer who cares > more about stabilization than averaging. > This option should be supported. And averaging should be meet as much as > possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-75) RemotingCommand header decoding swallows exceptions
[
https://issues.apache.org/jira/browse/ROCKETMQ-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15904328#comment-15904328
]
ASF GitHub Bot commented on ROCKETMQ-75:
Github user shroman commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/51
@vongosling @lizhanhui are you ok with this fix? If yes, I will merge.
> RemotingCommand header decoding swallows exceptions
> ---
>
> Key: ROCKETMQ-75
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-75
> Project: Apache RocketMQ
> Issue Type: Bug
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> {{RemotingCommand}} header decoding swallows exceptions, which is ok if you
> want to skip unparseable fields, but then logging is needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ROCKETMQ-135) Broker cannot be properly finalized on failure to load a storage plugin
[
https://issues.apache.org/jira/browse/ROCKETMQ-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh resolved ROCKETMQ-135.
---
Resolution: Fixed
> Broker cannot be properly finalized on failure to load a storage plugin
> ---
>
> Key: ROCKETMQ-135
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-135
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-broker
>Affects Versions: 4.0.0-incubating
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> When a storage plugin fails (
> {{org.apache.rocketmq.broker.plugin.MessageStoreFactory#build}} ), it
> terminates the broker without proper finalization.
> This is because {{RuntimeException}} is thrown by the above-mentioned method
> and it is never properly handled.
> I propose creating a {{BrokerException}}, throw it and properly handle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-135) Broker cannot be properly finalized on failure to load a storage plugin
[
https://issues.apache.org/jira/browse/ROCKETMQ-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903975#comment-15903975
]
ASF GitHub Bot commented on ROCKETMQ-135:
-
Github user coveralls commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/73
[](https://coveralls.io/builds/10519936)
Coverage increased (+0.1%) to 31.087% when pulling
**dde713c5d9ee0269a10befb32057363248ba70c1 on shroman:ROCKETMQ-135** into
**e3f4251c91a73f4e51732bcb1690554ac5fb3096 on apache:develop**.
> Broker cannot be properly finalized on failure to load a storage plugin
> ---
>
> Key: ROCKETMQ-135
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-135
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-broker
>Affects Versions: 4.0.0-incubating
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> When a storage plugin fails (
> {{org.apache.rocketmq.broker.plugin.MessageStoreFactory#build}} ), it
> terminates the broker without proper finalization.
> This is because {{RuntimeException}} is thrown by the above-mentioned method
> and it is never properly handled.
> I propose creating a {{BrokerException}}, throw it and properly handle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-135) Broker cannot be properly finalized on failure to load a storage plugin
[
https://issues.apache.org/jira/browse/ROCKETMQ-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903369#comment-15903369
]
ASF GitHub Bot commented on ROCKETMQ-135:
-
Github user coveralls commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/73
[](https://coveralls.io/builds/10513484)
Coverage increased (+0.04%) to 31.027% when pulling
**dde713c5d9ee0269a10befb32057363248ba70c1 on shroman:ROCKETMQ-135** into
**e3f4251c91a73f4e51732bcb1690554ac5fb3096 on apache:develop**.
> Broker cannot be properly finalized on failure to load a storage plugin
> ---
>
> Key: ROCKETMQ-135
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-135
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-broker
>Affects Versions: 4.0.0-incubating
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>
> When a storage plugin fails (
> {{org.apache.rocketmq.broker.plugin.MessageStoreFactory#build}} ), it
> terminates the broker without proper finalization.
> This is because {{RuntimeException}} is thrown by the above-mentioned method
> and it is never properly handled.
> I propose creating a {{BrokerException}}, throw it and properly handle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-111) fix possible MQClientException when query message before today
[ https://issues.apache.org/jira/browse/ROCKETMQ-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903251#comment-15903251 ] ASF GitHub Bot commented on ROCKETMQ-111: - Github user coveralls commented on the issue: https://github.com/apache/incubator-rocketmq/pull/69 [](https://coveralls.io/builds/10512144) Changes Unknown when pulling **e91b85072365df42afa7854305663bfb645714d2 on yilingfeng:master** into ** on apache:master**. > fix possible MQClientException when query message before today > -- > > Key: ROCKETMQ-111 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-111 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-commons >Affects Versions: 4.0.0-incubating >Reporter: Yiling Feng >Assignee: Jixiang Jin > Labels: build > Fix For: 4.0.0-incubating > > > Using "cal.set(Calendar.HOUR,0);" when query message before today which may > result in : > "org.apache.rocketmq.client.exception.MQClientException: CODE: 208 DESC: > query message by key finished, but no message. " > "HOUR" is used for the 12-hour clock.This will cause the start time of the > query message to be greater than the creation time of the message. > Implemenations: > Using "HOUR_OF_DAY" instead of "HOUR"."HOUR_OF_DAY" is used for the 24-hour > clock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-111) fix possible MQClientException when query message before today
[ https://issues.apache.org/jira/browse/ROCKETMQ-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903250#comment-15903250 ] ASF GitHub Bot commented on ROCKETMQ-111: - Github user coveralls commented on the issue: https://github.com/apache/incubator-rocketmq/pull/69 [](https://coveralls.io/builds/10512144) Changes Unknown when pulling **e91b85072365df42afa7854305663bfb645714d2 on yilingfeng:master** into ** on apache:master**. > fix possible MQClientException when query message before today > -- > > Key: ROCKETMQ-111 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-111 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-commons >Affects Versions: 4.0.0-incubating >Reporter: Yiling Feng >Assignee: Jixiang Jin > Labels: build > Fix For: 4.0.0-incubating > > > Using "cal.set(Calendar.HOUR,0);" when query message before today which may > result in : > "org.apache.rocketmq.client.exception.MQClientException: CODE: 208 DESC: > query message by key finished, but no message. " > "HOUR" is used for the 12-hour clock.This will cause the start time of the > query message to be greater than the creation time of the message. > Implemenations: > Using "HOUR_OF_DAY" instead of "HOUR"."HOUR_OF_DAY" is used for the 24-hour > clock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-111) fix possible MQClientException when query message before today
[ https://issues.apache.org/jira/browse/ROCKETMQ-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903249#comment-15903249 ] ASF GitHub Bot commented on ROCKETMQ-111: - Github user coveralls commented on the issue: https://github.com/apache/incubator-rocketmq/pull/69 [](https://coveralls.io/builds/10512144) Changes Unknown when pulling **e91b85072365df42afa7854305663bfb645714d2 on yilingfeng:master** into ** on apache:master**. > fix possible MQClientException when query message before today > -- > > Key: ROCKETMQ-111 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-111 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-commons >Affects Versions: 4.0.0-incubating >Reporter: Yiling Feng >Assignee: Jixiang Jin > Labels: build > Fix For: 4.0.0-incubating > > > Using "cal.set(Calendar.HOUR,0);" when query message before today which may > result in : > "org.apache.rocketmq.client.exception.MQClientException: CODE: 208 DESC: > query message by key finished, but no message. " > "HOUR" is used for the 12-hour clock.This will cause the start time of the > query message to be greater than the creation time of the message. > Implemenations: > Using "HOUR_OF_DAY" instead of "HOUR"."HOUR_OF_DAY" is used for the 24-hour > clock. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-123) Support distributed transaction messaging
[ https://issues.apache.org/jira/browse/ROCKETMQ-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15903000#comment-15903000 ] ZhangKe commented on ROCKETMQ-123: -- Is this distributed transaction still "producer transaction"(guarantee produce message and local transaction are atomic, not include consume operation)? > Support distributed transaction messaging > - > > Key: ROCKETMQ-123 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-123 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-client, rocketmq-store >Reporter: yukon >Priority: Minor > > Undoubtedly, transaction messaging is very frequently-used in most business. > But it is unfortunate that users must implement transaction mechanism by > themselves until now, may be they need DataBase to implement it. > It's time to support distributed transaction messaging to make it convenient > for the user, help them handle complex business with skill and ease. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-137) no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control
[ https://issues.apache.org/jira/browse/ROCKETMQ-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eason Chen updated ROCKETMQ-137: Attachment: QQ截图20170309181305.png QQ截图20170309181223.png > no longer pull message when clean expired message earlier than callback > return CONSUME_SUCCESS because of flow control > -- > > Key: ROCKETMQ-137 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-137 > Project: Apache RocketMQ > Issue Type: Bug > Components: rocketmq-client >Affects Versions: 4.1.0-incubating >Reporter: Eason Chen >Assignee: Xiaorui Wang > Attachments: QQ截图20170309181223.png, QQ截图20170309181305.png > > > no longer pull message when clean expired message earlier than callback > return CONSUME_SUCCESS because of flow control -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ROCKETMQ-137) no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control
Eason Chen created ROCKETMQ-137: --- Summary: no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control Key: ROCKETMQ-137 URL: https://issues.apache.org/jira/browse/ROCKETMQ-137 Project: Apache RocketMQ Issue Type: Bug Components: rocketmq-client Affects Versions: 4.1.0-incubating Reporter: Eason Chen Assignee: Xiaorui Wang no longer pull message when clean expired message earlier than callback return CONSUME_SUCCESS because of flow control -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [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=15902815#comment-15902815 ] ASF GitHub Bot commented on ROCKETMQ-67: Github user Jaskey commented on the issue: https://github.com/apache/incubator-rocketmq/pull/67 @zhouxinyu @lizhanhui @shroman @vongosling any advice on this pr? Since I think consistent hash can be also applied to order message shading, the classes in this pr can be reused. I will submit a new pr for that sharding message queue selector after this pr is merged : https://issues.apache.org/jira/browse/ROCKETMQ-136?jql=project%20%3D%20ROCKETMQ > 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 is valueable for the developer who cares > more about stabilization than averaging. > This option should be supported. And averaging should be meet as much as > possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-136) Provide a handy message queue selector for order message sharding
[ https://issues.apache.org/jira/browse/ROCKETMQ-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaskey Lam updated ROCKETMQ-136: Description: When order message is needed, users need to provide a message queue selector to make sure that the messages which has the same shading key should be sent to the same message queue. Actually this is a very common scenario with a common solutions, say consistent hashing. We should provide a handy selector for them to easily do that, what they only need to provide is a sharding key. A consistent hash selector will meet most of the user's need. was: When order message is needed, users need to provide a message queue selector to make sure that the messages which has the same shading key should be sent to the same message queue. Actually this is a very common scenario with a common solutions, say consistent hashing. We should provide a handy selector for them to easily do that, what they only need to provide is a shading key. A consistent hash selector will meet most of the user's need. > Provide a handy message queue selector for order message sharding > - > > Key: ROCKETMQ-136 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-136 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-client >Affects Versions: 4.1.0-incubating >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > > When order message is needed, users need to provide a message queue selector > to make sure that the messages which has the same shading key should be sent > to the same message queue. > Actually this is a very common scenario with a common solutions, say > consistent hashing. > We should provide a handy selector for them to easily do that, what they only > need to provide is a sharding key. > A consistent hash selector will meet most of the user's need. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ROCKETMQ-136) Provide a handy message queue selector for order message shading
[ https://issues.apache.org/jira/browse/ROCKETMQ-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaskey Lam updated ROCKETMQ-136: Summary: Provide a handy message queue selector for order message shading (was: Provide a handy message queue selector for order message sharding) > Provide a handy message queue selector for order message shading > > > Key: ROCKETMQ-136 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-136 > Project: Apache RocketMQ > Issue Type: Improvement > Components: rocketmq-client >Affects Versions: 4.1.0-incubating >Reporter: Jaskey Lam >Assignee: Jaskey Lam >Priority: Minor > > When order message is needed, users need to provide a message queue selector > to make sure that the messages which has the same shading key should be sent > to the same message queue. > Actually this is a very common scenario with a common solutions, say > consistent hashing. > We should provide a handy selector for them to easily do that, what they only > need to provide is a shading key. > A consistent hash selector will meet most of the user's need. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ROCKETMQ-106) Add flow control on topic level
[ https://issues.apache.org/jira/browse/ROCKETMQ-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902794#comment-15902794 ] ASF GitHub Bot commented on ROCKETMQ-106: - Github user Jaskey commented on the issue: https://github.com/apache/incubator-rocketmq/pull/66 @zhouxinyu @lizhanhui what about i new a config call flowControlTreadholds and a boolean config flowControlForTopic =false(default). If they set flowControlForTopic = true, then control on topic, or remains the same logic. But we need to deprecated the old config `pullThresholdForQueue` > 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 > > *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] [Commented] (ROCKETMQ-123) Support distributed transaction messaging
[ https://issues.apache.org/jira/browse/ROCKETMQ-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15902706#comment-15902706 ] Jaskey Lam commented on ROCKETMQ-123: - An old issue has been created for this: https://issues.apache.org/jira/browse/ROCKETMQ-100 Actually, implementing checkTransactionState will provide a full functionality of transaction messaging > Support distributed transaction messaging > - > > Key: ROCKETMQ-123 > URL: https://issues.apache.org/jira/browse/ROCKETMQ-123 > Project: Apache RocketMQ > Issue Type: Wish > Components: rocketmq-client, rocketmq-store >Reporter: yukon >Priority: Minor > > Undoubtedly, transaction messaging is very frequently-used in most business. > But it is unfortunate that users must implement transaction mechanism by > themselves until now, may be they need DataBase to implement it. > It's time to support distributed transaction messaging to make it convenient > for the user, help them handle complex business with skill and ease. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
