[
https://issues.apache.org/jira/browse/FLUME-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814217#comment-13814217
]
Hari Shreedharan commented on FLUME-2233:
-----------------------------------------
That was my initial thought - to do what we do with the queueRemaining
semaphore, but a long running transaction could essentially hold up heap space
- and the heap space used by the channel is not just the committed
transactions. Even though there is a performance penalty, this actually is more
of the intended meaning of the original patch. Also, I have rarely seen this
enabled in prod. Most users with memory channels generally tend to keep smaller
channels and don't really hit memory issues a lot.
> MemoryChannel lock contention on every put due to bytesRemaining Semaphore
> --------------------------------------------------------------------------
>
> Key: FLUME-2233
> URL: https://issues.apache.org/jira/browse/FLUME-2233
> Project: Flume
> Issue Type: Bug
> Reporter: Hari Shreedharan
> Assignee: Hari Shreedharan
> Attachments: FLUME-2233.patch, FLUME-2233.patch
>
>
> This semaphore is checked every time there is a put (unlike the
> queueRemaining semaphore which is checked only on transaction commits),
> causing the channel to slow down, even when the user does not care about
> memory usage.
> We must add a new parameter to make sure that we look at bytesRemaining only
> when required which the user can disable if memory is not something they
> worry about because they know the channel size will be sufficiently small. By
> default, we will need to still check bytesRemaining to avoid breaking
> existing configurations.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
