Thanks, Leah,
This sounds good!
-John
On Wed, Sep 2, 2020, at 19:23, Matthias J. Sax wrote:
> Thanks for the KIP and the detailed discussion. I guess this all makes
> sense.
>
> -Matthias
>
> On 9/2/20 1:28 PM, Leah Thomas wrote:
> > Hey John,
> >
> > I see what you say about the console
Thanks for the KIP and the detailed discussion. I guess this all makes
sense.
-Matthias
On 9/2/20 1:28 PM, Leah Thomas wrote:
> Hey John,
>
> I see what you say about the console consumer in particular. I don't think
> that adding the extra config would *hurt* at all, so I'm good with keeping
>
Hey John,
I see what you say about the console consumer in particular. I don't think
that adding the extra config would *hurt* at all, so I'm good with keeping
that in the KIP. I re-updated the KIP proposal to include the configs.
The serde resolution sounds good to me as well, I added a few
Hi Leah and Sophie,
Sorry for the delayed response.
You can pass in pre-instantiated (and therefore arbirarily
constructed) deserializers to the KafkaConsumer. However,
this doesn't mean we should drop the configs. The same
argument for dropping the configs implies that the consumer
shouldn't
Hey Sophie,
Thanks for the catch! It makes sense that the consumer would accept a
deserializer somewhere, so we can definitely skip the additional configs. I
updated the KIP to reflect that.
John seems to know Scala better than I do as well, but I think we need to
keep the current implicit that
Ok I'm definitely feeling pretty dumb now, but I was just thinking how
ridiculous
it is that the Consumer forces you to configure your Deserializer through
actual
config maps instead of just taking the ones you pass in directly. So I
thought
"why not just fix the Consumer to allow passing in an
Hey John,
Thanks for pointing this out, I wasn't sure how to handle the Scala changes.
I'm not fully versed in the Scala version of Streams, so feel free to
correct me if any of my assumptions are wrong. I think logging an error
message and then calling the constructor that requires a windowSize
Hi Leah,
I was just reviewing the PR for KIP-616 and realized that we
forgot to mention the Scala API in your KIP. We should
consider it because `scala.Serdes.timeWindowedSerde` is
implicitly using the exact constructor you're deprecating.
I had some ideas in the code review:
Thanks for the typo catch, John.
Let me know if anyone else has thoughts or ideas.
Cheers,
Leah
On Fri, Aug 21, 2020 at 2:50 PM John Roesler wrote:
> Thanks, all,
>
> Based on my reading of the conversation, it sounds like I
> have some legwork to do in KIP-645, but our collective
> instinct
Thanks, all,
Based on my reading of the conversation, it sounds like I
have some legwork to do in KIP-645, but our collective
instinct is that Leah's proposal doesn't need to change to
account for whatever we might decide to do in KIP-645.
I have no further concerns about KIP-645, and I think
Just want to make a quick comment on the question that John raised about
whether we
should introduce a separate config for "key" and "value" window sizes:
My short answer is No, I don't think that's necessary. First of all, as you
said, there is no
first-class concept of a "Windowed value" in the
Thanks John and Walker for your thoughts.
I agree with your two scenarios John, that you configure fully in the
constructor, or you don't need to call `init()`. IIUC, if we pass the
deserializer to the consumer, we want to make sure it has the window size
is set using the newly required
Hi Leah,
Thanks for the KIP! This has been a real pain for some use
cases, so it's really good to see a proposal to fix it.
We do need a default constructor so that it can be
dynamically instantiated by the consumer (or any other
component). But I'm +1 on deprecating the constructor you're
Hi Leah,
Could you explain a bit more why we do not wish to
let TimeWindowedDeserializer and WindowedSerdes be created without a
specified time as a parameter?
I understand the long.MAX_VALUE could cause problems but would it not be a
good idea to have a usable default or fetch from the config
Hi all,
I'd like to start a discussion for KIP-659:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-659%3A+Improve+TimeWindowedDeserializer+and+TimeWindowedSerde+to+handle+window+size
The goal of the KIP is to ensure that window size is passed to the consumer
when needed, which will
15 matches
Mail list logo
