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

ASF GitHub Bot commented on ROCKETMQ-106:
-----------------------------------------

Github user Jaskey commented on the issue:

    https://github.com/apache/incubator-rocketmq/pull/66
  
    @lizhanhui 
    
    > Can we maintain semantics of the original config and name this specific 
config something like flowControlThresholdByTopic?
    
    This already done in my current pr.
    
    
    What I suggest is one of the following:
    
    1. Separate two config in two config field , pullThresholdForQueue  and 
pullThresholdForTopic, they both take effect. 
    2.Separate two config in a boolean config, by default , it is control on 
queue level.
    
    
    Introduce one more boolean config and a topic level config is not clean 
enough since user must under stand the inner logic and we will find it hard to 
not easy to make them understood.


> 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)

Reply via email to