[
https://issues.apache.org/jira/browse/FLUME-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585137#comment-15585137
]
Attila Simon commented on FLUME-2997:
-------------------------------------
I think I missed some description of this change so let me provide it now:
Originally this test case aimed to verify behaviour about having multiple
mocked sources putting events on the same SpillableMemoryChannel while multiple
mocked sinks drains those events. Given the mock implementation didn't do retry
if sources are faster than the sinks the channel will get full. Since full
channel doesn't accept new events the mocked sources fail their task by raising
a runtime exception. This edge case should be avoided thus the increased
capacity (which makes sure that channel cannot be full). The "channel is full"
edge case is already covered by another test.
Those System.out.println-s were replaced by asserts to make the function to
became a test. It wasn't testing anything before. It only ran to the end
without checking anything. (The flakiness was caused by a
ChannelFullException). I guess the original author used those
System.out.println-s for manual testing (purely looking at the numbers). This
change also made that manual step automatic.
> Fix flaky junit test in SpillableMemoryChannel
> ----------------------------------------------
>
> Key: FLUME-2997
> URL: https://issues.apache.org/jira/browse/FLUME-2997
> Project: Flume
> Issue Type: Test
> Affects Versions: v1.7.0
> Reporter: Attila Simon
> Assignee: Attila Simon
> Fix For: v1.8.0
>
> Attachments: FLUME-2997-1.patch, FLUME-2997.patch
>
>
> testParallelSingleSourceAndSink sometimes trigger an edge case scenario if
> sinks are slower than sources. In such situations the channel can get full
> thus uncaught ChannelFullException breaks the test. Since
> testCapacityWithOverflow was designed to cover such edge-case scenario
> already we can safely fix the test by increasing the channel capacity to make
> sure it won't get full.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
