+1, makes sense. BTW, we probably need a FLIP as this is a public API
change.
On Sat, Aug 24, 2019 at 8:11 AM SHI Xiaogang wrote:
> +1 to replace Flink's time with Java's Duration.
>
> Besides, i also suggest to use Java's Instant for "point-in-time".
> It can take care of time units when we cal
Hi Piotr,
Thanks for the explanation.
Agreed that the broadcastEmit(record) is a better choice for broadcasting
for the iterations.
As broadcasting for the iterations is the first motivation, let's support
it first.
Thanks,
Zhu Zhu
Yun Gao 于2019年8月23日周五 下午11:56写道：
> Hi Piotr,
>
> Ve
Congratulations and thanks!
At 2019-08-22 20:03:26, "Tzu-Li (Gordon) Tai" wrote:
The Apache Flink community is very happy to announce the release of Apache
Flink 1.9.0, which is the latest major release.
Apache Flink® is an open-source stream processing framework for distributed,
high-perform
Congratulations and thanks!
At 2019-08-22 20:03:26, "Tzu-Li (Gordon) Tai" wrote:
>The Apache Flink community is very happy to announce the release of Apache
>Flink 1.9.0, which is the latest major release.
>
>Apache Flink® is an open-source stream processing framework for
>distributed, high-perfor
+1 since Java Duration is more common and powerful than Flink Time.
For whether to drop scala Duration for parsing duration OptionConfig, I
think it's another question and should be discussed in another thread.
Thanks,
Zhu Zhu
Becket Qin 于2019年8月24日周六 下午4:16写道：
> +1, makes sense. BTW, we proba
Gyula Fora created FLINK-13842:
--
Summary: Improve Javadocs and web documentation of the
StreamingFileSink
Key: FLINK-13842
URL: https://issues.apache.org/jira/browse/FLINK-13842
Project: Flink
Hi Kailash,
Any update on this?
Thanks,
Thomas
On Wed, Aug 7, 2019 at 7:54 AM Fabian Hueske wrote:
> Hi Kailash,
>
> Yes, I think creating another Jira and PR would be the right thing to do.
>
> Thank you,
> Fabian
>
> Am Fr., 2. Aug. 2019 um 10:29 Uhr schrieb Kailash Dayanand <
> kailash...@
Hi all,
Sorry for joining this thread late. Basically, I think enabling multicast
pattern could be the right direction, but more detailed implementation policies
need to be discussed.
Two years ago, I filed an issue [1] about the multicast API. However, due to
some reasons, it was laid aside.
