Re: Multiple stream operator watermark handling

Great to hear that this worked out for you :) Progression of watermarks on an empty stream is a known issue, that we are working on to resolve in the future. Usually recommended workarounds are to send a custom blank event (which should be ignored) once a while. I have expanded the

Re: Multiple stream operator watermark handling

On Thu, May 24, 2018 at 9:20 AM, Elias Levy wrote: > On Thu, May 24, 2018 at 7:26 AM, Piotr Nowojski > wrote: > >> From top of my head I can imagine two solutions: >> >> 1. Override the default behaviour of the operator via for example >>

Re: Multiple stream operator watermark handling

On Thu, May 24, 2018 at 7:26 AM, Piotr Nowojski wrote: > From top of my head I can imagine two solutions: > > 1. Override the default behaviour of the operator via for example > org.apache.flink.streaming.api.datastream.ConnectedStreams#transform > That seems the safer,

Re: Multiple stream operator watermark handling

Hi, From top of my head I can imagine two solutions: 1. Override the default behaviour of the operator via for example org.apache.flink.streaming.api.datastream.ConnectedStreams#transform 2. Can you set control stream’s watermark to Watermark#MAX_WATERMARK or maybe Watermark#MAX_WATERMARK - 1

Multiple stream operator watermark handling

Is there mechanism for a multiple stream operator to ignore watermarks from one of the streams? The use case is a multiple stream operator that consumes a primary stream and a secondary control stream. The control stream may only receive messages in rare occasion, and possibly never. The