All, the discussion list for this proposed change has been quiet for a few
days.
If there are no changes or other proposals, I'll start a voting thread
later today.
Thanks,
Bill
On Wed, Jun 13, 2018 at 12:31 PM Guozhang Wang wrote:
> Thanks for the explanation Bill. Makes sense to me.
>
> On
Thanks for the explanation Bill. Makes sense to me.
On Tue, Jun 12, 2018 at 9:21 AM, Bill Bejeck wrote:
> > Since there're only two values for the optional optimization config
> > introduced by KAFKA-6935, I wonder the overloaded build method (with
> Properties
> > instance) would make the
> Since there're only two values for the optional optimization config
> introduced by KAFKA-6935, I wonder the overloaded build method (with
Properties
> instance) would make the config unnecessary.
Hi Ted, thanks for commenting. You raise a good point. Buy IMHO, yes we
still need the config as
Thanks Matthias,
I buy this reasoning.
-John
On Mon, Jun 11, 2018 at 12:48 PM, Matthias J. Sax
wrote:
> @John: I don't think this is a good idea. `KafkaStreams` executes a
> `Topology` and should be agnostic if the topology was build manually or
> via `StreamsBuilder` (at least from my point
@John: I don't think this is a good idea. `KafkaStreams` executes a
`Topology` and should be agnostic if the topology was build manually or
via `StreamsBuilder` (at least from my point of view).
-Matthias
On 6/11/18 9:53 AM, Guozhang Wang wrote:
> Another implementation detail that we can
Another implementation detail that we can consider: currently the
InternalTopologyBuilder#setApplicationId() is used because we do not have
such a mechanism to pass in configs to the topology building process. Once
we add such mechanism we should consider removing this function as well.
Guozhang
Hello Bill,
While working on https://github.com/apache/kafka/pull/5163 I am wondering
if we can hide this from the public API, to e.g. add an additional function
in InternalTopologyBuilder of InternalStreamsBuilder (since in your current
working PR we're reusing InternalStreamsBuilder for the
Hi Bill,
Thanks for the KIP.
Just a small thought. This new API will result in calls that look like this:
new KafkaStreams(builder.build(props), props);
Do you think that's a significant enough eyesore to warrant adding a new
KafkaStreams constructor taking a KStreamsBuilder like this:
new
Since there're only two values for the optional optimization config
introduced by KAFKA-6935, I wonder the overloaded build method (with Properties
instance) would make the config unnecessary.
nit:
* @return @return the {@link Topology} that represents the specified
processing logic
Double
