[
https://issues.apache.org/jira/browse/FLUME-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818053#comment-13818053
]
Hudson commented on FLUME-2233:
-------------------------------
FAILURE: Integrated in flume-trunk #522 (See
[https://builds.apache.org/job/flume-trunk/522/])
FLUME-2233. MemoryChannel lock contention on every put due to bytesRemaining
Semaphore (roshan:
http://git-wip-us.apache.org/repos/asf/flume/repo?p=flume.git&a=commit&h=d3f5123c4d6cdbe4e5cca6e7e141e507bb1103a7)
* flume-ng-core/src/main/java/org/apache/flume/channel/MemoryChannel.java
* flume-ng-core/src/test/java/org/apache/flume/channel/TestMemoryChannel.java
> 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
> Fix For: v1.5.0
>
> Attachments: FLUME-2233.patch, 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)