Thanks Julian!
> 1. Do you prefer stripes or no stripes?
+1 for no stripes.
I like the design even the early Sketches. Great work!
Best,
Jincheng
Jan Lukavský 于2020年3月31日周二 下午4:33写道：
> On 3/31/20 4:06 AM, Julian Bruno wrote:
>
> Hello Apache Beam Community,
>
> We need a third input from th
Hi all,
I would like to drop the flink 1.7 support soon, as flink 1.10 already
supported in this commit.
https://github.com/apache/beam/commit/f91b390c8bbab4afe14734c1266da51dcc7558c9
Best,
Jincheng
jincheng sun 于2020年2月24日周一 上午11:22写道：
> Thanks for all of your feedback. Will dropping
>>>>>>>> On Mon, Feb 24, 2020 at 1:39 PM Gleb Kanterov
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Congratulations!
>>>>>>>>>>>
>>>>>>>>>>> On
Congratulations Chad!
Best,
Jincheng
Jan Lukavský 于2020年2月25日周二 下午5:05写道：
> Congrats Chad!
> On 2/25/20 9:48 AM, Gleb Kanterov wrote:
>
> Congratulations!
>
> On Tue, Feb 25, 2020 at 9:44 AM Ismaël Mejía wrote:
>
>> Congratulations, so well deserved for the lots of amazing work and new
>> per
rsions and adding new version should be
>> atomic, otherwise we risk we release beam version with less than three
>> supprted flink versions.
>> I'd suggest to start with the 1.10 branch support, include the drop of
>> 1.7 into that branch. Once 1.10 gets merged, we
+1
Best,
Jincheng
Kai Jiang 于2020年2月23日周日 上午2:26写道：
> +1
>
> On Sat, Feb 22, 2020 at 09:50 Alex Van Boxel wrote:
>
>> +1
>>
>> _/
>>
>> _/ Alex Van Boxel
>>
>>
>> On Sat, Feb 22, 2020 at 5:45 PM Jean-Baptiste Onofré
>> wrote:
>>
>>> +1
>>>
>>> Regards
>>> JB
>>>
>>> Le sam. 22 f?vr. 2020 ?
+1(non-binding)
Best,
Jincheng
Kai Jiang 于2020年2月22日周六 下午2:58写道：
> +1 (non-binding)
>
> On Fri, Feb 21, 2020 at 5:03 PM Robin Qiu wrote:
>
>> +1 (verified)
>>
>> On Fri, Feb 21, 2020 at 4:55 PM Robert Bradshaw
>> wrote:
>>
>>> +1 (binding)
>>>
>>>
>>> On Fri, Feb 21, 2020 at 4:48 PM Ahmet Al
Congratulations！
Best，
Jincheng
Robin Qiu 于2020年2月19日 周三05:52写道：
> Congratulations, Alex!
>
> On Tue, Feb 18, 2020 at 1:48 PM Valentyn Tymofieiev
> wrote:
>
>> Congratulations!
>>
>> On Tue, Feb 18, 2020 at 10:38 AM Alex Van Boxel wrote:
>>
>>> Thank you everyone!
>>>
>>> _/
>>> _/ Alex Van B
Hi folks,
Apache Flink 1.10 has completed the release announcement [1]. Then we would
like to add Flink 1.10 build target and make Flink Runner compatible with
Flink 1.10 [2]. So, I would suggest that at most three versions of Flink
runner for Apache Beam community according to the update Policy o
t;>>
>>> Regards,
>>>
>>> *Shoaib Zafar*
>>> Software Engineering Lead
>>> Mobile: +92 333 274 6242
>>> Skype: live:shoaibzafar_1
>>>
>>> <http://venturedive.com/>
>>>
>>>
>>> On Tue, Feb 11, 2020 at 1
I have verified that this issue could be reproduced in my local environment
(MacOS) and the solution suggested by Udi could work!
Best,
Jincheng
Udi Meiri 于2020年2月11日周二 上午8:51写道：
> I don't have those issues (running on Linux), but a possible workaround
> could be to remove the "-j 8" flags (2 l
x Van Boxel 于2020年2月11日周二 下午3:11写道：
> I've opened a PR and a ticket with INFRA.
>
> PR: https://github.com/apache/beam/pull/10824
>
> _/
> _/ Alex Van Boxel
>
>
> On Tue, Feb 11, 2020 at 6:57 AM jincheng sun
> wrote:
>
>> +1. Autolabeler seems really c
+1. Autolabeler seems really cool and it seems that it's simple to
configure and set up.
Best,
Jincheng
Udi Meiri 于2020年2月11日周二 上午2:01写道：
> Cool!
>
> On Mon, Feb 10, 2020 at 9:27 AM Robert Burke wrote:
>
>> +1 to autolabeling
>>
>> On Mon, Feb 10, 2020, 9:21 AM Luke Cwik wrote:
>>
>>> Nice
Congrats Michał ！
Hannah Jiang 于2020年1月29日 周三01:43写道：
> Congrats you Michal!
>
>
>
> On Tue, Jan 28, 2020 at 9:11 AM Gleb Kanterov wrote:
>
>> Congratulations!
>>
>> On Tue, Jan 28, 2020 at 6:03 PM Łukasz Gajowy wrote:
>>
>>> Congratulations Michał! 😎👍
>>>
>>> wt., 28 sty 2020 o 16:33 Ryan Skr
Congrats Hannah!
Ankur Goenka 于2020年1月29日 周三11:35写道：
> Congrats Hannah!
>
> On Tue, Jan 28, 2020 at 7:30 PM Reza Rokni wrote:
>
>> Congratz!
>>
>> On Wed, 29 Jan 2020 at 09:52, Valentyn Tymofieiev
>> wrote:
>>
>>> Congratulations, Hannah!
>>>
>>> On Tue, Jan 28, 2020 at 5:46 PM Udi Meiri wrote
encies around gRPC. This Avro-problem is
> interesting to me.
> I'll study BEAM-8388 more tomorrow.
>
> On Wed, Jan 15, 2020 at 10:51 PM Luke Cwik wrote:
> >
> > +Tomo Suzuki +jincheng sun
> > There have been a few contributors upgrading the dependencies and
> valid
Thanks Luke, and good to saw that the vendored Dependencies already
Released.
Best,
Jincheng
Luke Cwik 于2020年1月10日周五 上午2:09写道：
> Thanks for the work, I'll nominate myself as the release manager for
> beam-vendor-grpc-1_26_0.
>
> On Wed, Jan 8, 2020 at 5:38 PM jincheng sun
Thank you Mikhail!
Yichi Zhang 于2020年1月11日 周六09:09写道：
> Thank you Mikahil!
>
> On Fri, Jan 10, 2020 at 12:52 PM Ahmet Altay wrote:
>
>> Thank you Mikhail!
>>
>> On Fri, Jan 10, 2020 at 12:40 PM Kyle Weaver wrote:
>>
>>> Hooray! Thanks to Mikhail and everyone else who contributed.
>>>
>>> On Fri
+1，checked list as follows：
- verified the hash and signature
- verified that there is no linkage errors
- verified that the content of the pom is expected: the shaded
dependencies are not exposed, the scope of the logging dependencies are
runtime, etc.
Best，
Jincheng
Kenneth Knowles 于2020年1月1
/apache/beam/pull/10463
jincheng sun 于2019年12月26日周四 下午3:53写道：
> Correct the PR link, PR[3] is https://github.com/apache/beam/pull/10463
>
>
> jincheng sun 于2019年12月26日周四 下午3:49写道：
>
>> Hi folks,
>>
>> As the problem in [1] mentioned, more detail can be found in
：
> Probably best to take one of these existing update bugs:
> https://issues.apache.org/jira/browse/BEAM-4938
> There's no discussion on these bugs, so I'd go with 1.26.0 unless someone
> else has an objection.
>
> On Mon, Dec 23, 2019 at 10:04 PM jincheng sun
> w
Correct the PR link, PR[3] is https://github.com/apache/beam/pull/10463
jincheng sun 于2019年12月26日周四 下午3:49写道：
> Hi folks,
>
> As the problem in [1] mentioned, more detail can be found in the
> discussion [2]. We should make a gRPC vendor dependencies release process
> separate
Hi folks,
As the problem in [1] mentioned, more detail can be found in the discussion
[2]. We should make a gRPC vendor dependencies release process separately
after the PR [3] be merged.
I would like to propose a vendor release for gRPC. According the vendor
release guide [4], we need a favor fr
Hi folks,
When submitting a Python word count job to a Flink session/standalone
cluster repeatedly, the meta space usage of the task manager of the Flink
cluster will continuously increase (about 40MB each time). The reason is
that the Beam classes are loaded with the user class loader(child-first
Congrats Kasia!
Best,
Jincheng
Ankur Goenka 于2019年12月24日周二 上午7:48写道：
> Congratulations Kasia!
>
> On Mon, Dec 23, 2019 at 2:57 PM Chamikara Jayalath
> wrote:
>
>> Congrats!
>>
>> On Mon, Dec 23, 2019 at 2:15 PM Yichi Zhang wrote:
>>
>>> Congrats Kasia!
>>>
>>> On Mon, Dec 23, 2019 at 2:07 PM
Big +1 on it.
Thanks a lot for the improvement Udi !
It also make sense to have this timeout for other tests like Max said. I'm
thinking whether there are any timeout configurations for Jenkins, in this
case, the timeout config could be applied to all tests if necessary.
Best,
Jincheng
Robert
Thanks for drive this release Mikhail !
I have found there is an incorrect release version for release notes in
PR[1], also left a question in PR[2].
But I do not think it's the blocker of the release :)
Best,
Jincheng
[1] https://github.com/apache/beam/pull/10401
[2] https://github.com/apache/
+1 （non-binding）
Alex Van Boxel 于2019年12月13日 周五16:21写道：
> +1
>
> On Fri, Dec 13, 2019, 05:58 Kenneth Knowles wrote:
>
>> Please vote on the proposal for Beam's mascot to be the Firefly. This
>> encompasses the Lampyridae family of insects, without specifying a genus or
>> species.
>>
>> [ ] +1,
+1 for using {{site.release_latest}}, which is make more sense to me.
Best,
Jincheng
Kenneth Knowles 于2019年12月11日周三 下午1:12写道：
> +1 to site.release_latest
>
> We do have a dead link checker in the website tests. Does it not catch
> moved classes, etc?
>
> On Tue, Dec 10, 2019 at 1:49 PM Pablo Es
Thanks for bring up this discussion Kenn!
Definitely +1 for the proposal.
I have left some questions in the documentation :)
Best,
Jincheng
Rui Wang 于2019年12月11日周三 上午5:23写道：
> Until now as I am not seeing more people are commenting on this proposal,
> can we consider this proposal is already
Thanks for bring up this discussion Jan!
+1 for cearly define BIP for beam.
And I think would be nice to initialize a concept document for BIP. Just a
reminder: the document may contains:
- How many kinds of improvement in beam.
- What kind of improvement should to create a BIP.
- What should be
Thanks for the Tracking Udi!
I have updated the status of some release blockers issues as follows:
- BEAM-8733 closed
- BEAM-8620 reset the fix version to 2.19
- BEAM-8618 reset the fix version to 2.19
Best,
Jincheng
Colm O hEigeartaigh 于2019年12月5日周四 下午5:38写道：
> Could we get this one in 2.18
+1
Thank you Udi！
Best，
Jincheng
Valentyn Tymofieiev 于2019年11月28日 周四08:09写道：
> +1. Thanks, Udi!
>
> On Wed, Nov 27, 2019 at 12:58 PM Ahmet Altay wrote:
>
>> Thank you Udi for keeping the release cadence. +1 to cutting 2.18.0
>> branch on time.
>>
>> On Thu, Nov 21, 2019 at 10:07 AM Udi Meiri
Congrats, Daniel!
Best,
Jincheng
Alexey Romanenko 于2019年11月22日周五 下午5:47写道：
> Congratulations, Daniel!
>
> On 22 Nov 2019, at 09:18, Jan Lukavský wrote:
>
> Congrats Daniel!
> On 11/21/19 10:11 AM, Gleb Kanterov wrote:
>
> Congratulations!
>
> On Thu, Nov 21, 2019 at 6:24 AM Thomas Weise wrote:
Congratulation Brian!
Best,
Jincheng
Kyle Weaver 于2019年11月15日周五 上午7:19写道：
> Thanks for your contributions and congrats Brian!
>
> On Thu, Nov 14, 2019 at 3:14 PM Kenneth Knowles wrote:
>
>> Hi all,
>>
>> Please join me and the rest of the Beam PMC in welcoming a new committer:
>> Brian Hulette
Thanks for bringing up this discussion @Luke.
As @Kenn mentioned, in Beam we have defined the constants value for the
min/max/end of global window. I noticed that
google.protobuf.Timestamp/Duration is only used in window definitions, such
as FixedWindowsPayload, SlidingWindowsPayload, SessionsPayl
Thanks for sharing your thoughts which give me more help to deep
understanding the design of FnAPI, and It make more sense to me.
Great thanks Robert !
Best,
Jincheng
Robert Bradshaw 于2019年11月12日周二 上午2:10写道：
> On Fri, Nov 8, 2019 at 10:04 PM jincheng sun
> wrote:
> >
> &
Congratulate Beam community, Very amazing numbers, very active community!
Best,
Jincheng
Maximilian Michels 于2019年11月8日周五 上午1:39写道：
> Yes! Keep the committer pipeline filled ;)
>
> Reviewing PRs probably remains one of the toughest problems in active
> open-source projects.
>
> On 07.11.19 18:
>>>> NewValueOnlyWindowedValueCoder(GlobalWindow, MIN_TIMESTAMP,
>>>>> PaneInfo.NO_FIRING). Note in particular that using the existing
>>>>> ValueOnlyWindowedValueCoder would give the wrong timestamp and pane
>>>>> info if it is use for t
fined in the Java ModerCoders, not the coders defined in the
proto file.
jincheng sun 于2019年11月9日 周六12:26写道：
> Hi Robert Bradshaw,
>
> Thanks a lot for the explanation. Very interesting topic!
>
> Let us first define what are "standard coders". Usually it should be the
github.com/apache/beam/blob/4364a214dfe6d8d5dd84b1bb91d579f466492ca5/sdks/go/pkg/beam/core/runtime/graphx/coder.go#L348
>> [2]
>> https://github.com/apache/beam/blob/4364a214dfe6d8d5dd84b1bb91d579f466492ca5/sdks/go/pkg/beam/core/runtime/graphx/coder.go#L219
>>
>>
>> On Fr
+1 for extend the discussion to the user mailing list?
Maximilian Michels 于2019年11月8日周五 下午6:32写道：
> The dates sounds good to me. I agree that the bay area has an advantage
> because of its large tech community. On the other hand, it is a question
> of how we run the event. For Berlin we managed
Hi,
Sorry for my late reply. It seems the conclusion has been reached. I just
want to share my personal thoughts.
Generally, both option 1 and 3 make sense to me.
>> The key concept here is not "standard coder" but "coder that the
>> runner does not understand." This knowledge is only in the run
y
> >
> > Approach 1: what are all the details?
> > option a: if the SDK harness has to understand "values without
> windows" then very large changes and high risk of introducing inconsistency
> (I eliminated many of these inconsistencies)
> >
Hi all,
I am trying to make some improvements of portability framework to make it
usable in other projects. However, we find that the coder between runner
and harness can only be FullWindowedValueCoder. This means each time when
sending a WindowedValue, we have to encode/decode timestamp, windows
thing.
>
> On Sun, Oct 27, 2019 at 9:27 PM jincheng sun
> wrote:
>
>> Hi all,
>>
>> Thanks a lot for your feedback. It seems that we have reached consensus
>> that both "Approach 2" and "Approach 3" are needed. "Approach 3" is a go
idea to trigger this logic when the SDK
>>> > Harness evicts process bundle descriptors is more elegant.
>>> >
>>> > Thanks,
>>> > Max
>>> >
>>> > On 25.10.19 17:23, Luke Cwik wrote:
>>> > > I like approach 3 sin
ent/d/1sCgy9VQPf9zVXKRquK8P6N4x7aB62GEO8ozkujRSHZg/edit?usp=sharing
jincheng sun 于2019年10月25日周五 上午10:40写道：
> Hi,
>
> Functionally capable of `abort`, but it will be called at the end of
> operator. So, I prefer `dispose` semantics. i.e., all normal logic has been
> executed.
>
> Best,
> Jincheng
>
9 at 8:01 PM jincheng sun
> wrote:
>
>> Hi Luke,
>>
>> Thanks a lot for your reply. Since it allows to share one SDK harness
>> between multiple executable stages, the control service termination may
>> occur much later than the completion of an executable stage
they want and
> start new instances anytime as well.
>
> Why do you want to expose this logic so that Runners could control it?
>
> 1:
> https://docs.google.com/document/d/1n6s3BOxOPct3uF4UgbbI9O9rpdiKWFH9R6mtVmR7xp0/edit#
>
> On Mon, Oct 21, 2019 at 4:27 AM jincheng sun
> w
Hi,
I found that in `SdkHarness` do not stop the `SdkWorker` when finish. We
should add the logic for stop the `SdkWorker` in `SdkHarness`. More detail
can be found [1].
There are two approaches to solve this issue:
Approach 1: We can add a Fn API for teardown purpose and the runner will
tear
Hi Thomas,
Thank you for granting access, I have updated the `Python Tips`.
Best,
Jincheng
Thomas Weise 于2019年10月10日周四 下午9:38写道：
> Thanks for spotting this.
>
> Access granted (for user "jincheng").
>
>
> On Thu, Oct 10, 2019 at 12:01 AM jincheng sun
> wrote
Hi all,
The docker config has been removed with the latest python3 docker related
commit [1], So the command:
> ./gradlew :sdks:python:container:docker
in `Python Tips`[2] can not work well, we should correct it, something like:
> ./gradlew :sdks:python:container:py35:docker
The flink 1.5 and
king locally:
>>>
>>> maven { url "https://repo1.maven.org/maven2/"; } => maven { url "
>>> https://oss.sonatype.org/content/repositories/staging/"; }
>>>
>>> When sonatype is up again you should be fine without this
Hi all,
I got the 500 error, when do the PreCommit. We can run the following
command to see the detail:
./gradlew :sdks:python:test-suites:portable:py2:flinkValidatesRunner
>>
Task :model:pipeline:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for
Congrats Valentyn !
Cheers,
Jincheng
Katarzyna Kucharczyk 于2019年9月2日周一 下午5:20写道：
> Congratulations Valentyn! 🎉
>
> On Wed, Aug 28, 2019 at 3:49 PM Frederik Bode
> wrote:
>
>> Congrats Valentyn!!
>>
>>
>> On Wed, 28 Aug 2019 at 15:28, Tanay Tummalapalli
>> wrote:
>>
>>> Congratulations Valenty
Hi Mark,
+1 and thank you for keeping the cadence!
BTW I have mark the Fix Version for some of issues to 2.17, which can not
be merged into 2.16.
Best,
Jincheng
Mark Liu 于2019年8月29日周四 上午6:14写道：
> Hi all,
>
> Beam 2.16 release branch cut is scheduled on Sep 11 according to the
> release calend
Cheers!! Thanks for driving the release, Yifan!
Thanks a lot to everyone who helped making this release possible!
Best,
Jincheng
Thomas Weise 于2019年8月27日周二 下午12:54写道：
> Yifan, thanks for managing this release. It went smoothly!
>
>
> On Fri, Aug 23, 2019 at 2:32 PM Kenneth Knowles wrote:
>
>>
Congrats Valentyn!
Best,
Jincheng
Ankur Goenka 于2019年8月27日周二 上午10:37写道：
> Congratulations Valentyn!
>
> On Mon, Aug 26, 2019, 5:02 PM Yifan Zou wrote:
>
>> Congratulations, Valentyn! Well deserved!
>>
>> On Mon, Aug 26, 2019 at 3:31 PM Aizhamal Nurmamat kyzy <
>> aizha...@google.com> wrote:
>>
; The list looks good to me. Thanks for summarizing. Feel free to dive
>> into any of these issues yourself :).
>>
>> On Fri, Aug 2, 2019 at 6:24 PM jincheng sun
>> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > Thanks a lot for sharing y
github.com/apache/beam/blob/master/sdks/python/apache_beam/runners/worker/sdk_worker_main.py#L113
Best,
Jincheng
jincheng sun 于2019年8月2日周五 下午4:14写道：
> Thanks for share the detail of the current StandardCoders Max!
> That's true, Flink may should defined some of coders, And I will s
tly we are preparing the design of how to support Python UDF in
> Flink based on the Beam portability framework and we will bring up the
> discussion in Flink community. We may propose more changes for Beam during
> that time and may need more support from Beam community.
> >
> >
Congratulations Jan!
Best, Jincheng
Gleb Kanterov 于2019年8月1日周四 下午5:09写道：
> Congratulations!
>
> On Thu, Aug 1, 2019 at 3:11 PM Reza Rokni wrote:
>
>> Congratulations , awesome stuff !
>>
>> On Thu, 1 Aug 2019, 12:11 Maximilian Michels, wrote:
>>
>>> Congrats, Jan! Good to see you become a comm
30, 2019 at 11:52 AM jincheng sun
> wrote:
>
>>
>>>> Is it possible to add an interface such as `isSelfContained()` to the
>>>> `Coder`? This interface indicates
>>>> whether the serialized bytes are self contained. If it returns true,
>>>&g
Hi Rakesh,
Glad to see you pointer this problem out!
+1 for add this implementation. Manage State by write-through-cache is
pretty important for Streaming job!
Best, Jincheng
Thomas Weise 于2019年7月29日周一 下午8:54写道：
> FYI a basic test appears to confirm the importance of the cross-bundle
> caching
Hi Robert,
Thanks for your detail comments, I would have added a few pointers inline.
Best,
Jincheng
Robert Bradshaw 于2019年7月29日周一 下午12:35写道：
> On Sun, Jul 28, 2019 at 6:51 AM jincheng sun
> wrote:
> >
> > Hi, Thomas & Robert, Thanks for your comments and providing rele
the current state and that there is the intention to join
> forces on the portability effort!
> >
> > I have added a few pointers inline.
> >
> > Several of the issues you identified affect our usage of Beam as well.
> These present an opportunity for collaboration.
&g
elated code to be useful as well for the
> interaction with the SDK Harness. There are some fundamental differences
> in the model, e.g. how windowing works, which might be challenging to
> work around.
>
> Thanks,
> Max
>
> On 24.04.19 12:03, jincheng sun wrote:
> >
>
Hi Pablo, Congratulations!
Best,
Jincheng
Rakesh Kumar 于2019年6月12日周三 上午6:00写道：
> Congratulations Pablo!!!
>
> On Mon, Jun 10, 2019 at 6:03 AM Gleb Kanterov wrote:
>
>> Congratulations!
>>
>> On Fri, May 24, 2019 at 9:50 PM Joana Filipa Bernardo Carrasqueira <
>> joanafil...@google.com> wrote:
Hi all,
I'm happy to announce that we have unanimously approved this release.
There are 6 approving votes, 3 of which are binding:
* Chesnay
* Timo
* Hequn
* Till
* Nico
* Jincheng
There are no disapproving votes.
Thanks, everyone!
Cheers,
Jincheng
Congrats Yifan!
Griselda Cuevas 于2019年4月26日周五 上午1:56写道：
> Congrats Yifan!
>
>
>
>
> On Mon, 22 Apr 2019 at 08:26, Kenneth Knowles wrote:
>
>> Hi all,
>>
>> Please join me and the rest of the Beam PMC in welcoming a new committer:
>> Yifan Zou.
>>
>> Yifan has been contributing to Beam since ear
Hi Robert,
In addition to the questions described by Dian, I also want to know what
difficult problems Py4j's solution will encounter in add UDF support, which
you mentioned as follows:
Using something like Py4j is an easy way to get up an running, especially
> for a very faithful API, but the in
portability in the context of
>> Flink, do you think it would make sense to setup a document where we
>> collect ideas and challenges?
>>
>> Thanks,
>> Max
>>
>> On 23.04.19 13:00, jincheng sun wrote:
>> > Hi Reuven,
>> >
>> > I think you
rt-term approach in Flink*
>
> - Goal is to not block Flink's Python effort on the long term approach
> and the necessary design and evolution of the language-independent DAG.
> - Depending on what the outcome of above investigation is, Flink may
> initially go with a simp
link, it would be safer to copy the code IMO rather than to directly
> depend on it.
>
> On Mon, Apr 22, 2019 at 12:08 AM jincheng sun
> wrote:
>
>> Hi Kenn,
>>
>> Thanks for your reply, and explained the design of WindowValue clearly!
>>
>> At present, the d
imitives in the subgraph will ever observe the metadata. So you want
> to not even have a tiny
> "WindowedValueWithNoMetadata". Is that accurate?
>
> Kenn
>
> On Fri, Apr 19, 2019 at 10:17 AM jincheng sun
> wrote:
>
>> Thank you! And have a nice weekend
Thank you! And have a nice weekend!
Lukasz Cwik 于2019年4月20日周六 上午1:14写道：
> I have added you as a contributor.
>
> On Fri, Apr 19, 2019 at 9:56 AM jincheng sun
> wrote:
>
>> Hi Lukasz,
>>
>> Thanks for your affirmation and provide more contextual information.
JIRA about this and start working on a change towards
>> this.
>>
>> 1:
>> https://lists.apache.org/thread.html/221b06e81bba335d0ea8d770212cc7ee047dba65bec7978368a51473@%3Cdev.beam.apache.org%3E
>>
>> On Fri, Apr 19, 2019 at 3:18 AM jincheng sun
>> w
Hi Beam devs,
I read some of the docs about `Communicating over the Fn API` in Beam. I
feel that Beam has a very good design for Control Plane/Data Plane/State
Plane/Logging services, and it is described in document. When communicating between Runner and SDK Harness, the
DataPlane API will be Win
79 matches
Mail list logo
