[jira] [Resolved] (FLUME-238) Add more details in source/sink/decorator semantics

["Ashish Paliwal (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FLUME-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ashish Paliwal resolved FLUME-238.
----------------------------------
       Resolution: Won't Fix
    Fix Version/s: v0.9.5

Won't fix. 0.X branch not maintained anymore

> Add more details in source/sink/decorator semantics
> ---------------------------------------------------
>
>                 Key: FLUME-238
>                 URL: https://issues.apache.org/jira/browse/FLUME-238
>             Project: Flume
>          Issue Type: Improvement
>    Affects Versions: v0.9.2
>            Reporter: Jonathan Hsieh
>             Fix For: v0.9.5
>
>
> FLUME-155 is a good first cut but more improvements can be done.  This jira is the place holder for some of these issues.
> Feedback from Vibhor on first cut. (FLUME-155)
> """"
> Most of it looks good and very interesting. I'll give the high level comments here, gave minor comments on paper to Jon.
> 1) Missing the main Threading detail, it should be explained that there is a main driver thread, and different decorators can create their own threads too.
> 2) In the section talking about the sinks with buffered memories it says close() from a closing state "should blocks until resources are freed, it should attempt to flush its buffers before returning. For example, so if a network source has some buffered data, the network connection should be closed to prevent new data from entering, and then the buferred data should be flushed",
> but at the same time it is said that the next() should keep on pulling data from the buffer even in the closing state. As both these methods (close() and next()) can be from different threads, it should be clearly mentioned how are we handling the race conditions while operating on the same data.
> 3) In both Source/Sink descriptions, it is said that if a timeout happens in a closing state, then we move to a close state. But do we ensure that we have given up all the resources before it? Else there will be an issue when someone later will try to open this decorator.
> 4) It should be clearly explained why and how we handle the Thread-Interrupted-Exception when a append() on sink gets interrupted while it is blocked.
> """



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)