Yeah I took a look too...I guess that even if both work the clearer
(winner) option would be the Keyed(Co)ProcessFunction.
Anyway, thanks a lot!
Salva
On Fri, Dec 2, 2022, 12:23 Gen Luo wrote:
> Hi Salva,
>
> I mistook the idea, and yes both will work well.
> `stream.keyBy(...).process(new MyC
Hi Salva,
I mistook the idea, and yes both will work well.
`stream.keyBy(...).process(new MyCoProcessFunction());` uses
LegacyKeyedCoProcessOperator, and stream.keyBy(...).process(new
MyKeyedCoProcessFunction());` uses KeyedCoProcessOperator. Comparing the
two operators you'll find they are almos
Hi Gen,
Yeah but AFAIK keyed state is accessible as long as you are working with a
keyed state, so these two options:
```
stream.keyBy(...).process(new MyCoProcessFunction());`
stream.keyBy(...).process(new MyKeyedCoProcessFunction());`
```
will just work well with keyed state & timers if I'm no
Hi Salva,
I suppose what you are missing is that, the timers are stored in the keyed
state, so you may only register timers when using KeyedCoProcessFunction.
If you try to register a timer in the CoProcessFunction, you'll get an
UnsupportedOperationException with the message "Setting timers is on
The current docs claim [1]:
"KeyedProcessFunction, as an extension of ProcessFunction, gives access to
the key of timers in its onTimer(...) method."
So, from what it's worth, it seems that if one does not need to query the
current key, wich within a `Keyed(Co)ProcessFunction` can be done like th
