On Tue, Feb 27, 2024 at 10:22 AM Robert Bradshaw via dev <
dev@beam.apache.org> wrote:
> On Mon, Feb 26, 2024 at 11:45 AM Kenneth Knowles wrote:
> >
> > Pulling out focus points:
> >
> > On Fri, Feb 23, 2024 at 7:21 PM Robert Bradshaw via dev <
> dev@beam.apache.org> wrote:
> > > I can't act on
On Tue, Feb 27, 2024 at 10:39 AM Jan Lukavský wrote:
>
> On 2/27/24 19:22, Robert Bradshaw via dev wrote:
> > On Mon, Feb 26, 2024 at 11:45 AM Kenneth Knowles wrote:
> >> Pulling out focus points:
> >>
> >> On Fri, Feb 23, 2024 at 7:21 PM Robert Bradshaw via dev
> >> wrote:
> >>> I can't act
On 2/27/24 19:30, Robert Bradshaw via dev wrote:
On Tue, Feb 27, 2024 at 7:44 AM Robert Burke wrote:
An "as fast as it can runner" with dynamic splits, would ultimately split to the systems
maximum available parallelism (for stateful DoFns, this is the number of keys; for SplittableDoFns,
On 2/27/24 19:22, Robert Bradshaw via dev wrote:
On Mon, Feb 26, 2024 at 11:45 AM Kenneth Knowles wrote:
Pulling out focus points:
On Fri, Feb 23, 2024 at 7:21 PM Robert Bradshaw via dev
wrote:
I can't act on something yet [...] but I expect to be able to [...] at some
time in the
On Tue, Feb 27, 2024 at 7:44 AM Robert Burke wrote:
>
> An "as fast as it can runner" with dynamic splits, would ultimately split to
> the systems maximum available parallelism (for stateful DoFns, this is the
> number of keys; for SplittableDoFns, this is the maximum sharding of each
> input
On Mon, Feb 26, 2024 at 11:45 AM Kenneth Knowles wrote:
>
> Pulling out focus points:
>
> On Fri, Feb 23, 2024 at 7:21 PM Robert Bradshaw via dev
> wrote:
> > I can't act on something yet [...] but I expect to be able to [...] at some
> > time in the processing-time future.
>
> I like this as
On 2/27/24 16:36, Robert Burke wrote:
An "as fast as it can runner" with dynamic splits, would ultimately
split to the systems maximum available parallelism (for stateful
DoFns, this is the number of keys; for SplittableDoFns, this is the
maximum sharding of each input element's restriction.
An "as fast as it can runner" with dynamic splits, would ultimately split
to the systems maximum available parallelism (for stateful DoFns, this is
the number of keys; for SplittableDoFns, this is the maximum sharding of
each input element's restriction. That's what would happen with a "normal"
On 2/27/24 14:51, Kenneth Knowles wrote:
I very much like the idea of processing time clock as a parameter
to @ProcessElement. That will be obviously useful and remove a source
of inconsistency, in addition to letting the runner/SDK harness
control it. I also like the idea of passing a Sleeper
I very much like the idea of processing time clock as a parameter
to @ProcessElement. That will be obviously useful and remove a source of
inconsistency, in addition to letting the runner/SDK harness control it. I
also like the idea of passing a Sleeper or to @ProcessElement. These are
both good
This is your daily summary of Beam's current high priority issues that may need
attention.
See https://beam.apache.org/contribute/issue-priorities for the meaning and
expectations around issue priorities.
Unassigned P0 Issues:
https://github.com/apache/beam/issues/30377 [Failing Test]:
11 matches
Mail list logo
