> "It should behave as if the upstream operator does not emit anything on the port."
But as per your earlier description the upstream operator "..for any reason decides that it will not emit tuples on the output port, it may close it..." . So this is not just the case where the upstream operator is not emitting tuples because there is no data but it has implicitly changed the DAG by closing the stream. As an example, a port could be receiving events marking "window" boundaries for aggregating data received from the other port. It will be useful for the operator to know these events will not be received any more so it can stop aggregating data from the other port. In any case your idea of the "EOS" control tuple addresses this. >> operator needs to behave differently because it's a different DAG now. >> Will >> a control tuple inform it that the input port is closing? >> > Again, the details will need to be flushed out. It may be an eos (end of > stream) control tuple. An operator with 2 input ports may not even care > that one of the input ports is connected to inactive stream. It should > behave as if the upstream operator does not emit anything on the port.
