[
https://issues.apache.org/jira/browse/TUBEMQ-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17195344#comment-17195344
]
Guocheng Zhang commented on TUBEMQ-345:
---------------------------------------
In fact, in the API pullSelect(), the delayed waiting operation when the
consumption status of the current partition is not satisfied has been
considered, but the sleep interval of 6 times is only about 2 seconds,
!screenshot-1.png!
but the current client is likely to be idle because the number of clients is
greater than the total number of partitions, or has been allocated to the
partition, but the number of threads started is greater than the number of
partitions allocated, which causes the pull thread to idle for a long time.
In order to achieve this control effect and simplify the call of getMessage(),
I plan to control it through the following 3 new parameters of the
ConsumerConfig class:
private long msgNotFoundWaitPeriodMs
private long pullConsumeReadyWaitPeriodMs
private long pullConsumeReadyChkSliceMs
!screenshot-2.png!
If the partition data is consumed to the maximum position,
msgNotFoundWaitPeriodMs will control the partition to enter the delay waiting
queue for consumption, pullConsumeReadyWaitPeriodMs will control how long
getMessage() stays until the timeout or the partition status is satisfied, the
pull attempt is made, pullConsumeReadyChkSliceMs controls the call to
getMessage() How long does the thread sleep when the condition is not met
before repeating the status check operation; if you want to close this check,
set pullConsumeReadyWaitPeriodMs to 0, if you need to pull the thread to wait
indefinitely, set pullConsumeReadyWaitPeriodMs to -1.
> Optimize the call logic of getMessage() in Pull mode
> ----------------------------------------------------
>
> Key: TUBEMQ-345
> URL: https://issues.apache.org/jira/browse/TUBEMQ-345
> Project: Apache TubeMQ
> Issue Type: Improvement
> Reporter: Guocheng Zhang
> Assignee: Guocheng Zhang
> Priority: Major
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> When the business thread calls getMessage() in the pull mode, if the current
> client does not have a free partition, the function will return immediately.
> At this time, the thread needs to control the sleep time by itself to avoid
> frequent calls to the function but no free partition consumption, causing the
> CPU to surge. This call logic can be optimized, that is, we can check in
> getMessage and let the business control check how long it has not met the
> requirements before returning, reducing the complexity of the business use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
