kennknowles commented on pull request #14718: URL: https://github.com/apache/beam/pull/14718#issuecomment-847247195
To be clear, I do not think that a "hold" is part of the user conceptual model and I do not think it should be added. It can be up to each runner how it wants to manage it. The purpose of the method is actually to control the event timestamp of outputs, and watermarks should be managed by the runner. But, yes, in practice they all use shared hold code. I would say this: 1. setting timer with the scope of window => `timer.set(X)` callback produces outputs with timestamp `X` as a default. 2. setting timer out of the scope of window (within lateness) => user needs to specify output timestamp since the default does not make sense. The runner, or runners-core can decide based on many things. For example in GBK the runners-core actually uses the current watermark value to decide how to set the hold. If the time of the hold has already passed, then we do some things to avoid pausing the watermark, just making sure the window does not expire. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
