[
https://issues.apache.org/jira/browse/BOOKKEEPER-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011535#comment-16011535
]
ASF GitHub Bot commented on BOOKKEEPER-1066:
--------------------------------------------
Github user merlimat commented on the issue:
https://github.com/apache/bookkeeper/pull/153
@jvrao I don't have a benchmark for this specific change, though I agree it
might make sense to add one.
The points here are:
* In some places we are using `LinkedBlockingQueue` which uses the same
head/tail mutex schema but with a linked list instead of the array
* I don't expect the throughput / cpu utilization to be different between
the 2
* This implementation doesn't require to create a LinkedList node for each
value, so it creates no garbage. This can be significant since we are enqueuing
quite a bit of items (Journal thread, force-sync thread, OrderedSafeExcutor).
For each BK request there were several of these (cannot remember exact number,
though I believe ~3 in Bookie and another ~3 in client)
> Introduce GrowableArrayBlockingQueue
> ------------------------------------
>
> Key: BOOKKEEPER-1066
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1066
> Project: Bookkeeper
> Issue Type: Improvement
> Reporter: Matteo Merli
> Assignee: Matteo Merli
> Priority: Minor
> Fix For: 4.5.0
>
>
> In multiple places, (eg: journal, ordered executor, etc..), we are using
> {{LinkedBlockingQueue}} instances to pass objects between threads.
> The {{LinkedBlockingQueue}} differs from the {{ArrayBlockingQueue}} in that
> it doesn't require to define a max queue size, though, being implemented with
> a linked list, it requires to allocates list nodes each time an item is added.
> We can use a {{GrowableArrayBlockingQueue}} that behaves in the same way as
> the {{LinkedBlockingQueue}}, but it's implemented with an array that can be
> resized when the queue reaches the capacity.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
