[
https://issues.apache.org/jira/browse/APEXCORE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15236623#comment-15236623
]
ASF GitHub Bot commented on APEXCORE-413:
-----------------------------------------
Github user vrozov commented on the pull request:
https://github.com/apache/incubator-apex-core/pull/301#issuecomment-208715497
There is no benefit of AbstractReservoir implementing BlockingQueue other
than reusing already defined interface currently. As CircularBuffer implements
BlockingQueue and DefaultReservoir extended CircularBuffer, I made
AbstractReservoir implement BlockingQueue interface as well. As
AbstractReservoir implementations delegate BlockingQueue implementation to
CircularBuffer, SpscArrayQueue or ArrayBlockingQueue, and both CircularBuffer
and ArrayBlockingQueue implement BlockingQueue, if SpscArrayQueue adds support
for BlockingQueue, it may be possible to use other methods from BlockingQueue
in AbstractReservoirs.
> Collision between Sink.getCount() and SweepableReservoir.getCount()
> -------------------------------------------------------------------
>
> Key: APEXCORE-413
> URL: https://issues.apache.org/jira/browse/APEXCORE-413
> Project: Apache Apex Core
> Issue Type: Bug
> Affects Versions: 3.2.0, 3.3.0
> Reporter: Vlad Rozov
> Assignee: Vlad Rozov
> Fix For: 3.4.0
>
>
> SweepableReservoir.getCount() and Sink.getCount() are two distinct counts as
> SweepableReservoir.getCount() returns number of tuples consumed/poll from the
> reservoir by an operator since the last reset, while Sink.getCount() returns
> number of tuples pushed into the sink since the last reset. For InlineStream
> that implements both interfaces, it causes a conflict as a count of tuples
> pushed into InlineStream is not necessarily equal to a count of tuples poll
> from it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
