[
https://issues.apache.org/jira/browse/FLUME-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814280#comment-13814280
]
Roshan Naik commented on FLUME-2233:
------------------------------------
Yes, kind of.. i was thinking byteCapacityBufferPercentage can be used to
account for the uncommitted events also. Today it seems to be used to account
for header size only.
Whether users need to tweak the setting or not would depend on the situation.
For many use cases the current default value may already be generous enough
since the transaction batch size is typically not very large. Use cases where
lots of headers are applied to events, very large batch sizes on source, lots
of sources are hooked up to a single mem channel, or event body size is
relatively large are situations where user may need to tweak
byteCapacityBufferPercentage.
> 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, 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)
