[
https://issues.apache.org/jira/browse/GEODE-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868660#comment-16868660
]
Darrel Schneider commented on GEODE-6891:
-----------------------------------------
It is possible that this throttling code should be removed. It is not used by
threads that are "precious" and in another place it is not used if we can send
the message "inline" (i.e. doing it directly instead of handing it off to
another thread). So it is probably worth figuring out under what conditions it
will be used and if those conditions need to have a throttle.
Otherwise we could just remove this throttling code.
> ClusterDistributionManager.SerialQueuedExecutorPool.getThrottledSerialExecutor
> has some problems
> ------------------------------------------------------------------------------------------------
>
> Key: GEODE-6891
> URL: https://issues.apache.org/jira/browse/GEODE-6891
> Project: Geode
> Issue Type: Bug
> Components: messaging
> Reporter: Darrel Schneider
> Priority: Major
>
> The getThrottledSerialExecutor has the following issues:
> 1. It reads that stat: DistributionStats.getSerialQueueBytes(). If stats are
> disabled then the throttling would be disabled. Someone needs to maintain
> this value in a local atomic.
> 2. It reads the stat in three different places. One of those is outside the
> loop but that seems wrong. Each time it is used inside the loop to calculate
> how long to sleep it should be using the current value.
> 3. It is compared against two different constants. To get in the loop it must
> be greater than TOTAL_SERIAL_QUEUE_THROTTLE. To exit the loop it must be >=
> to TOTAL_SERIAL_QUEUE_BYTE_LIMIT. This seems wrong but it might be correct.
> 4. The constant TOTAL_SERIAL_QUEUE_THROTTLE is calculated from
> SERIAL_QUEUE_BYTE_LIMIT. This looks like a copy and past mistake. I think it
> should be TOTAL_SERIAL_QUEUE_BYTE_LIMIT
> 5. It looks like the intent of this code is to block message senders if we
> currently have more than TOTAL_SERIAL_QUEUE_BYTE_LIMIT message bytes queued
> up for sending. But the whole sleep calculation is scary. If we want this
> throttling then it seems like instead of sleeping we should wait until we see
> the value go below a threshold. We can make this event driven since it is our
> code that will decrement the value as messages are removed from the queue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
