[ 
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)

Reply via email to