Hi Andrew, at the moment, the ProcessingTimeService cannot be exposed via the RuntimeContext, because it is stream specific and the RuntimeContext is also used in the batch context.
Many streaming operators use the same casting pattern in order to get access to the streaming specific fields. Thus, you should be relatively safe that the implementation won't change that fast. However, the StreamingRuntimeContext is not marked as public and, thus, it could change theoretically in the future. Cheers, Till On Tue, Apr 10, 2018 at 11:32 AM, Andrew Roberts <arobe...@fuze.com> wrote: > Hello, > > We have some custom Flink sinks that need to use a batching approach, and > we use timers to facilitate flushing. Currently, we’re casting the > `RuntimeContext` provided by `RichFunction.getRuntimeContext()` to a > `StreamingRuntimeContext` (which it always seems to be?), which then gives > us access to `ProcessingTimeService` as a scheduler. Is there any chance of > either `getProcessingTimeService` being added to `RuntimeContext`, or some > other scheduling facility being exposed? With the runtime cast, if the > implementation changes during an upgrade, our jobs can be completely broken > without any compiler errors, which is a big source of exposure in our > project. > > Thanks, > > Andrew > -- > *Confidentiality Notice: The information contained in this e-mail and any > > attachments may be confidential. If you are not an intended recipient, you > > are hereby notified that any dissemination, distribution or copying of this > > e-mail is strictly prohibited. If you have received this e-mail in error, > > please notify the sender and permanently delete the e-mail and any > > attachments immediately. You should not retain, copy or use this e-mail or > > any attachment for any purpose, nor disclose all or any part of the > > contents to any other person. Thank you.* >
