Re: Thread access and broadcast state initialization in BroadcastProcessFunction

2019-12-17 Thread KristoffSC
Thank you for your reply Timo. Regarding point 2. I'm sorry for the delay. I rerun my test and everything seems to be in order. Open method was called as first. I guess it was a false alarm. Sorry for that. Regards, Krzysztof -- Sent from: http://apache-flink-user-mailing-list-archive.2336050.

Re: Thread access and broadcast state initialization in BroadcastProcessFunction

2019-12-11 Thread Timo Walther
1. Yes, methods will only be called by one thread. The FLink API aims to abstract all concurrency topics away when using the provided methods and state. 2. The open() method should always be the first method being called. If this is not the case, this is definitely a bug. Which Flink version a

Re: Thread access and broadcast state initialization in BroadcastProcessFunction

2019-12-11 Thread KristoffSC
Hi Vino, Thank you for your response and provided links. So just to clarify and small follow up. 1. Methods will be called only by one thread right? 2. The links you provided are tackling a case when we got a "fast stream" element before we received broadcast stream element. In my case we had Br

Re: Thread access and broadcast state initialization in BroadcastProcessFunction

2019-12-10 Thread vino yang
Hi kristoffSC, >> I've noticed that all methods are called by the same thread. Would it be always the case, or could those methods be called by different threads? No, open/processXXX/close methods are called in the different stages of a task thread's life cycle. The framework must keep the call o

Thread access and broadcast state initialization in BroadcastProcessFunction

2019-12-10 Thread KristoffSC
Hi, I was playing around with BroadcastProcessFunction and I've observe a specific behavior. My setup: MapStateDescriptor ruleStateDescriptor = new MapStateDescriptor<>( "RulesBroadcastState", Types.VOID, TypeInformation.of(new TypeHint() {