Hi Nirmalya, please find my answers in line.
2015-12-02 3:26 GMT+01:00 Nirmalya Sengupta <sengupta.nirma...@gmail.com>: > Hello Fabian (<fhue...@gmail.com>), > > Many thanks for your encouraging words about the blogs. I want to make a > sincere attempt. > > To summarise my understanding of the rule of removal of the elements from > the window (after going through your last mail), here are two corollaries: > > 1) If my workflow has no triggers (and hence, no evictors), my application > will run out of memory, perhaps sooner than I expect. > > No, not necessarily. If you define a regular TimeWindow or CountWindow, Flink will use default triggers and evictors to ensure that data is not unnecessarily accumulated. > 2) If I am using CountTriggers only (and no Evictors), then I too my > application will run out of memory, eventually. > > Yes, that's right. However, you can wrap the CountTrigger in a PurgingTrigger to purge windows after they have been evaluated. > Could you please strike them with Yes/No? > > I understand why removal of elements from the window is essential. In fact > if older elements are not removed, new elements cannot come in and > therefore, the conceptual proposition of a **flowing Stream** is not > realized in the right manner. > > > -- Nirmalya > > > Custom triggers and evictors should only be used, if you have special windowing semantics that cannot be addressed by Flink's build-in window strategies. As soon as you call .tringger() (and .evictor) on a window, you have to be *very* careful and knowledgeable about the internals to get these things right. The docs is currently insufficient for these situations but we are working on improving them. > -- > Software Technologist > http://www.linkedin.com/in/nirmalyasengupta > "If you have built castles in the air, your work need not be lost. That is > where they should be. > Now put the foundation under them." >
