Hi all,
The PMC for Apache Kafka has invited Manikumar Reddy as a committer and we
are
pleased to announce that he has accepted!
Manikumar has contributed 134 commits including significant work to add
support for delegation tokens in Kafka:
KIP-48:
https://cwiki.apache.org/confluence/display/KAF
Hi Alex,
Thanks for the KIP. I think it makes sense, especially since most of the
group apis are intended for batching anyway.
The only questions I have are about compatibility. For example, the csv
format for resetting offsets is changed, so will we continue to support the
old format? Also, if o
manually without waiting the entire
> > > registration timeout on shrink down. What do you think?
> > > >
> > > > Mike
> > > >
> > > > On 10/30/18, 1:55 AM, "Boyang Chen" wrote:
> > > >
> > > > Btw, I upda
> while using admin tool to switch between static and dynamic membership and
> set the two corresponding timeouts. Do you think this approach makes sense?
> The version one implementation will be much more clean if we handle
> membership change through user intervention.
>
>
>
er is never back), we could continue discussing the
> new approaches to have basic guarantee of consumer group liveness.
>
>
> The discussion so far is to make sure that all the design approaches we
> have taken are pointing to real scenarios. Once we clarify the scenarios,
> we wou
+1
I verified the release and upgrade notes. I also went through the basic
quickstart.
Great job running the release, Dong! Thanks for all the effort.
-Jason
On Mon, Nov 19, 2018 at 10:50 AM, Dong Lin wrote:
> Hey Ismael,
>
> I checked out a clean copy of Kafka and reuploaded artifacts for 2.
Hi All,
I've posted a KIP to add the often-requested support for fetching from
followers:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-392%3A+Allow+consumers+to+fetch+from+closest+replica.
Please take a look and let me know what you think.
Thanks,
Jason
Hi Stanislav,
Thanks for the KIP. Can you clarify the compatibility impact here? What
will happen to groups that are already larger than the max size? Also, just
to be clear, the resource we are trying to conserve here is what? Memory?
-Jason
On Mon, Nov 26, 2018 at 2:44 AM Boyang Chen wrote:
Hi Boyang,
Thanks for the updates. Looks like we're headed in the right direction and
clearly the interest that this KIP is receiving shows how strong the
motivation is!
I have a few questions:
1. This may be the same thing that Mayuresh is asking about. I think the
suggestion in the KIP is that
Another wrinkle to consider is KIP-320. If you are planning to replicate
__consumer_offsets directly, then you will have to account for leader epoch
information which is stored with the committed offsets. But I cannot think
how it would be possible to replicate the leader epoch information in
messa
t; state is still unknown.": not sure why we have to validate? If the metadata
> returned from the txn-coordinator can always be considered the
> source-of-truth, can't we just bindly use it to update the cache?
>
>
> Guozhang
>
>
>
> On Thu, Sep 6, 2018 at 9:10 PM
lps Kafka become a
> more self-serving system. Admin/Ops teams can better control the impact
> application developers can have on a Kafka cluster with this change
>
> Best,
> Stanislav
>
>
> On Mon, Nov 26, 2018 at 8:00 PM Jason Gustafson
> wrote:
>
> > Hi
Hi Boyang,
Thanks for the KIP. Looks good overall. I think we will need to bump the
version of the JoinGroup protocol in order to indicate compatibility with
the new behavior. The coordinator needs to know when it is safe to assume
the client will handle the error code.
Also, I was wondering if w
nt output format.
> Also,
> >>> starting with a GROUP column makes more sense to me.
> >>>
> >>> Also, and for my own info, is there a valid scenario where we would
> want to
> >>> delete all consumer groups? It sounds to me like a potentially
>
ansactional.id.timeout (default is
> 7 days), I feel comfortable leaving it as is.
>
> Guozhang
>
> On Mon, Nov 26, 2018 at 6:09 PM Jason Gustafson
> wrote:
>
> > Hey Guozhang,
> >
> > Thanks for the comments. Responses below:
> >
> > 0. The new API
le to join and the max
> size invariant will be satisfied.
>
> I updated the KIP with a migration plan, rejected alternatives and the new
> default value.
>
> Thanks,
> Stanislav
>
> On Tue, Nov 27, 2018 at 5:25 PM Jason Gustafson
> wrote:
>
> > Hey Stan
half
> round-trips
> >>>> needed to join in a rebalance (1 full RT addition), is it worth it to
> >>>> consider increasing the default value of `
> >> group.initial.rebalance.delay.ms`?
> >>> I guess we could keep it for now. After KIP-345
+1 Thanks for the KIP!
-Jason
On Wed, Nov 28, 2018 at 5:26 PM Kevin Lu wrote:
> @Manikumar I have updated the Compatibility section to note that this
> option is not supported with the deprecated "--zookeeper" option.
>
> We still need 1 more binding vote for this to be accepted.
>
> Thanks~
>
+1 Thanks for the KIP, Boyang!
-Jason
On Mon, Dec 10, 2018 at 10:07 AM Boyang Chen wrote:
> Thanks for voting my friends. Could someone give one more binding vote
> here?
>
> Best,
> Boyang
>
> From: Bill Bejeck
> Sent: Thursday, December 6, 2018 2:45 AM
> To:
t; > requests before the offset commit req has been handled. i.e consmer
> sends
> > > fetchReq A, offsetCommit B, fetchReq C - we may receive A,C,B in the
> > > broker. Meaning we could have saved the offsets for B but rebalance
> > before
> > > the offsetComm
; > > >
> > > > 3. Could ReplicaSelector be closable?
> > > >
> > > > 4. Currently, the ISR propagation from the leader to the controller
> > can be
> > > > delayed up to 60 secs through
> > ReplicaManager.IsrChangePropagationInterval
ta about the
replication state, but nothing stops users from leveraging other
information to make better decisions. Does that seem reasonable?
Thanks,
Jason
On Mon, Dec 10, 2018 at 11:41 AM Jason Gustafson wrote:
> Hey Eno,
>
> Thanks for the comments. However, I'm a bit confused. I
2 the same application seeks to the beginning of the topic and attempts to
> consume again. Is there a scenario where this second attempt fails because
> the fetching happens from a replica that does not have the record yet? At
> time t3 all replicas have the record.
>
> Thanks
> Eno
Hi Alex,
I think WADL support was likely unintentional, so this could be treated as
more of a bug. Unless we think it's a good idea to support it going
forward, I'd suggest going with the rejected alternative of just turning it
off. What do you think?
Thanks,
Jason
On Fri, Dec 14, 2018 at 3:06 P
Hi Boyang,
Thanks, the KIP looks good. Just one comment.
The new schema for the LeaveGroup request is slightly odd since it is
handling both the single consumer use case and the administrative use case.
I wonder we could make it consistent from a batching perspective.
In other words, instead of
t
some more thought. I think in the common case, these concerns can be
treated orthogonally, but it is a bit irritating if you need two separate
plugins to make the benefit more general.
Thanks,
Jason
On Tue, Dec 11, 2018 at 11:04 AM Jason Gustafson wrote:
> Hi Eno,
>
> Thanks for the
system
> > stability and we need to get things rolling right at the start of 2019.
> >
> > Thank you for your time!
> > Boyang
> >
> >
> > From: Jason Gustafson
> > Sent: Tuesday, December 18, 2018 7:40 AM
> > To:
stream-fail-to-produce-data-after-a-long-time/54029181#54029181
>
> Guozhang
>
>
>
> On Thu, Nov 29, 2018 at 2:25 PM Jason Gustafson
> wrote:
>
> > Hey Guozhang,
> >
> > To clarify, the broker does not actually use the ApiVersion API
+1 Thanks for the KIP!
-Jason
On Mon, Jan 14, 2019 at 5:15 PM Gwen Shapira wrote:
> I was also wondering about that. I think its for compatibility with
> the existing output.
>
> We can have a separate KIP to add JSON output.
>
> On Mon, Jan 14, 2019 at 7:55 AM M. Manna wrote:
> >
> > Hi,
> >
+1 Thanks for the KIP!
-Jason
On Mon, Jan 14, 2019 at 12:54 AM Andrew Schofield
wrote:
> +1 (non-binding)
>
> Looks like a good improvement.
>
> Andrew Schofield
> IBM Event Streams
>
> On 11/01/2019, 17:33, "Boyang Chen" wrote:
>
> +1 (non-binding)
>
> Thanks for the great work!
>
>
Hi All,
The PMC for Apache Kafka has invited Vahid Hashemian as a project committer and
we are
pleased to announce that he has accepted!
Vahid has made numerous contributions to the Kafka community over the past
few years. He has authored 13 KIPs with core improvements to the consumer
and the too
Hi Dhruvil,
Thanks for the KIP. +1 from me. Just a minor nitpick on the name of the new
config. I would suggest "record.downconversion.enable". The "record" prefix
emphasizes what is being down-converted and similar existing configs use
"enable" rather than "enabled."
-Jason
On Wed, May 2, 2018
>>>> Thanks, Sasaki.
>>>>>
>>>>> Colin
>>>>>
>>>>> On Sat, Apr 28, 2018, at 00:55, Sasaki Toru wrote:
>>>>>
>>>>>> Hi Colin, Jason,
>>>>>>
>>>>>> Thank you
Thanks for the KIP, +1 (binding).
One small correction: the KIP mentions that close() will be deprecated, but
we do not want to do this because it is needed by the Closeable interface.
We only want to deprecate close(long, TimeUnit) in favor of close(Duration).
-Jason
On Tue, May 8, 2018 at 12:4
Hi All,
We found one more gap in this KIP. It is useful for the
describeConsumerGroups API to expose the group state so that users can tell
when a group is rebalancing. Colin submitted a PR with the proposed changes
here: https://github.com/apache/kafka/pull/4980. Please review and let us
know if
Thanks for the KIP! +1 (binding)
On Fri, May 11, 2018 at 12:35 AM, Manikumar
wrote:
> +1 (non-binding)
>
> Thanks for the KIP.
>
> On Fri, May 11, 2018 at 12:56 PM, zhenya Sun wrote:
>
> > +1 building
> > > 在 2018年5月11日，上午9:51，Ted Yu 写道：
> > >
> > > +1
> > >
> > > On Thu, May 10, 2018 at 6:42
Hi Magesh,
Thanks for the KIP. It's definitely useful to have a pluggable auth layer,
as we have for the kafka brokers. I was a bit unclear why we needed to
expose all this health information in the context though. Since it is the
bigger part of the API, I was hoping to see a little more motivatio
Hi Arjun,
Thanks for the KIP. Just a few comments/questions:
1. The proposal allows users to configure the number of retries. I usually
find it easier as a user to work with timeouts since it's difficult to know
how long a retry might take. Have you considered adding a timeout option
which would
> On Mon, May 21, 2018 at 11:01 AM Arjun Satish
> > wrote:
> >
> > > Hey Jason,
> > >
> > > Thanks for your comments. Please find answers inline:
> > >
> > > On Mon, May 21, 2018 at 9:52 AM, Jason Gustafson
> > > wrote:
> >
+1. Just one nit: could we use an INT type for the config? I can't imagine
that not being enough.
-Jason
On Mon, May 21, 2018 at 3:59 PM, Ismael Juma wrote:
> Thanks for the KIP, +1 (binding).
>
> Ismael
>
> On Mon, May 21, 2018 at 7:52 AM Dhruvil Shah wrote:
>
> > Hi,
> >
> > I would like to
+1. Thanks for the KIP!
On Mon, May 21, 2018 at 1:34 PM, Arjun Satish
wrote:
> All,
>
> Thanks so much for your feedback on this KIP. I've made some small
> modifications today. I'll wait till midnight today (PDT) to close this
> vote. Please let me know if there are any further comments.
>
> Be
; >>
> > > >> On Thu, May 10, 2018 at 9:39 AM, Rajini Sivaram <
> > > rajinisiva...@gmail.com>
> > > >> wrote:
> > > >>> Hi Richard, Thanks for the KIP.
> > > >>>
> > > >>> +1 (binding)
> > > >>
Perhaps one minute? That is the default used by the producer.
-Jason
On Wed, May 30, 2018 at 9:50 AM, Ismael Juma wrote:
> Option 1 sounds good to me provided that we can come up with a good
> default. What would you suggest?
>
> Ismael
>
> On Wed, May 30, 2018 at 9:41
I'm going to call this vote since it has enough binding votes and it has
been open for a long time. The final tally:
Binding +4: me, Ismael, Rajini, and Guozhang
Non-binding +4: Ted, Moshe, Alex, and Dhruvil
There were no -1 votes.
Thanks to Alexander Dunayevsky for the KIP!
Thanks,
Jason
On F
ned with the producer.
> >
> > -Bill
> >
> > On Wed, May 30, 2018 at 3:43 PM, Ismael Juma wrote:
> >
> > > Sounds good to me,
> > >
> > > On Wed, May 30, 2018 at 12:40 PM Jason Gustafson
> > > wrote:
> > >
> >
gt; +1 as well.
>
> On Thu, May 31, 2018 at 6:00 PM, Jason Gustafson
> wrote:
>
> > Thanks everyone for the feedback. I've updated the KIP and added
> > KAFKA-6979.
> >
> > -Jason
> >
> > On Wed, May 30, 2018 at 3:50 PM, Guozhang Wang
> wrote:
&g
ducer's
> > > config with the same name, but their semantics are different.
> > >
> > > On the other hand, I'm a bit concerned with the reusing of the term
> > > `timeout` as we already have `session.timeout.ms` and `
> > request.timeout.ms`
> > > in Consume
etimes hang for a long time. If the API
> > > > timeout
> > > > > > is
> > > > > > > > the same as the RPC timeout, we are not robust against this
> > > failure
> > > > > > > > condition. The
Hey All,
I wrote up a KIP to handle one more edge case in the replication protocol
and to support better handling of truncation in the consumer when unclean
leader election is enabled. Let me know what you think.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-320%3A+Allow+fetchers+to+detec
Added. Thanks for contributing!
-Jason
On Mon, Jun 25, 2018 at 9:27 AM, lambdaliu(刘少波)
wrote:
> Hi Team,
>
> I am trying to claim a bug in Jira, Could you please help me gain the
> required permissions.
> my JIRA usernane is lambdaliu.
>
> thanks,
> lambdaliu.
>
Hey Manikumar,
Thanks for the KIP. This seems useful.
-Jason
On Thu, Jun 21, 2018 at 11:38 PM, Manikumar
wrote:
> Hi all,
>
> I have created a KIP to add support for dynamic update of
> max.connections.per.ip/max.connections.per.ip.overrides configs
>
> *https://cwiki.apache.org/confluence/pag
Done. Thanks for contributing!
-Jason
On Mon, Jun 25, 2018 at 12:49 PM, Yishun Guan wrote:
> Hi, could someone give me access to create KIP? Thanks! - Yishun
>
> On Mon, Jun 25, 2018, 10:44 AM Yishun Guan wrote:
>
> > Hi, my wiki id is gyishun. Thanks! - Yishun
> >
>
(too low)"
> and "Offset out of range (unknown truncation offset)", i.e. the two columns
> in table provided in the KIP?
>
> - It is probably a typo. Maybe fix "This is not the last The" in the
> Proposed Section.
>
>
> Thanks,
> Dong
>
> On
The other thing I forgot to mention is that resetting the offset using the
leader epoch is only available with the latest message format. By
supporting reset by timestamp, users on the v1 format can still get some
benefit from this KIP.
-Jason
On Tue, Jun 26, 2018 at 11:47 AM, Jason Gustafson
Hey Dong,
Sorry for being slow to catch up to this.
I think the benefit of the sanity check seems a little dubious in the first
place. We detect garbage at the end of the index file, but that's about it.
Is there any reason to think that corruption is more likely to occur there
or any other reaso
ild index. But this
> > alternative solution is inconsistent with the idea that "sanity check is
> not
> > part of any formal guarantee" and it may tie up all request handler
> > thread for rebuilding the indexed.
> >
> >
> > If this solution soun
@Dong
Those are fair points. Both approaches require some fuzziness to reset the
offset in these pathological scenarios and we cannot guarantee
at-least-once delivery either way unless we have the full history of leader
epochs that were consumed. The KIP-101 logic may actually be more accurate
tha
ffsetsForLeaderEpochs(Map epochsToSearch)
Thoughts?
-Jason
On Wed, Jun 27, 2018 at 11:12 AM, Jason Gustafson
wrote:
> @Dong
>
> Those are fair points. Both approaches require some fuzziness to reset the
> offset in these pathological scenarios and we cannot guarantee
> at
users they are willing to use some admin client to get further information?
>
>
> Guozhang
>
>
> On Wed, Jun 27, 2018 at 2:07 PM, Jason Gustafson
> wrote:
>
> > Thanks for the feedback. I've updated the KIP. Specifically I removed the
> > "closest&quo
Hey Gwen,
Why do users want partition size? It seems like a weird thing to be
concerned about. Perhaps they are trying to get a sense of the lag as a
percentage of the total size of the partition or something like that?
-Jason
On Tue, Jun 26, 2018 at 9:12 PM, Gwen Shapira wrote:
> Thank you!
>
Hey Gwen/Vahid,
I think that use case makes sense, but isn't it a little odd to go through
the consumer group tool? I would expect to find something like that from
the kafka-topics tool instead. I don't feel too strongly about it, but I
hate to complicate the tool by adding the need to query topic
+1
Thanks Manikumar!
On Fri, Jun 29, 2018 at 8:37 AM, Rajini Sivaram
wrote:
> +1 (binding)
>
> Thanks for the KIP, Manikumar!
>
> On Fri, Jun 29, 2018 at 4:23 PM, Dong Lin wrote:
>
> > +1
> >
> > Thanks!
> >
> > On Fri, 29 Jun 2018 at 7:36 AM Ted Yu wrote:
> >
> > > +1
> > >
> > > On Fri, Jun
+1 (binding). I checked release notes, documentation, and went through the
quickstart.
Thanks Matthias!
On Fri, Jun 22, 2018 at 6:43 PM, Matthias J. Sax
wrote:
> Hello Kafka users, developers and client-developers,
>
> This is the second candidate for release of Apache Kafka 0.10.2.2.
>
> Note,
gt; different from what was requested. However, if users may want to avoid
> auto
> > offset reset and be notified explicitly when there is log truncation,
> then seekToNearest()
> > probably does not help here. Would it make sense to replace
> seekToNearest()
> > with seek(
Hey Matthias,
I don't see the artifacts for scala 2.12. Did they not get uploaded?
Thanks,
Jason
On Fri, Jun 29, 2018 at 12:41 PM, Guozhang Wang wrote:
> +1 (binding), checked release note, java doc, and ran unit tests on source
> tgz.
>
>
> Guozhang
>
> On Mon, Jun 25, 2018 at 8:05 PM Manikum
nEpoch; // This may be needed later as discussed in KIP-232
> ... // Hopefully these are all we need to identify message in Kafka. But
> if we need more then we can add new fields in this class.
> }
>
> OffsetEpochs offsetEpochs(TopicPartition);
>
> void seek(TopicPartition, Off
on:
> > >
> > >
> > > ** Building real-time streaming data pipelines that reliably get data
> > > between systems or applications.
> > >
> > >
> > > ** Building real-time streaming applications that transform or react
> > > to th
Sorry to join the discussion late. Can you you add to the motivation the
use cases for header-based compaction. This seems not very clear to me.
Thanks,
Jason
On Mon, Jul 2, 2018 at 11:00 AM, Guozhang Wang wrote:
> Hi Luis,
>
> I believe that compaction property is indeed overridable at per-top
API.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Here is my thought process why we should keep position() and
> > > > seek()
> > > > >> API
> > > > >> > > > u
Hey Manikumar,
As Kafka begins to scale to larger and larger numbers of topics/partitions,
I'm a little concerned about the scalability of APIs such as this. The API
looks benign, but imagine you have have a few million partitions. We
already expose similar APIs in the producer and consumer, so pr
Hi, thanks for the KIP. +1 from me.
I think eventually we'd want --exclude-internal-topics to be the default,
but it seems reasonable to keep the current behavior for compatibility.
-Jason
On Mon, Jul 16, 2018 at 2:23 PM, Dong Lin wrote:
> +1
>
> Thanks!
> Dong
>
> On Mon, Jul 16, 2018 at 9:17
+1
- Did basic quickstarts on the 2.11 and 2.12 artifacts
- Checked upgrade notes and documentation
Thanks for managing the release, Dong!
-Jason
On Thu, Jul 12, 2018 at 2:36 PM, Harsha wrote:
> +1.
> 1. Ran unit tests
> 2. Ran 3 node cluster to run few tests.
>
> Thanks,
> Harsha
>
> On Thu
+1. This is useful (though the naming inconsistencies in the tools are
vexing, as always).
-Jason
On Tue, Jul 17, 2018 at 12:24 PM, Dong Lin wrote:
> Hi all,
>
> It seems that there is no further concern with the KIP-304. I guess it is
> time to start the voting thread.
>
> The KIP can be found
Hey Vahid,
I'm with Mike that it seems simpler to just use the consumer group
generation. Even if you can figure out how to reason about the local
generation, it still seems confusing to have something called "generation"
which is not the consumer group generation. There doesn't seem to be much
do
>
> (just a double check) the option name used in kip-338 is
> "--exclude-internal" rather than "--exclude-internal-topics". Do you prefer
> "--exclude-internal-topics"?
Nah, just a typo on my part. I think --exclude-internal is clear enough
given the name of the tool. Sorry for the confusion.
-
Hi Vahid,
Sorry for getting to this so late. I think there are two things here:
1. The use of "" as a groupId has always been a dubious practice at best.
We definitely ought to deprecate its use in the client. Perhaps in the next
major release, we can remove support completely. However, since old
Hey Manikumar,
This looks good. Do we have to keep the current behavior when handling old
DeleteTopics versions? I'm wondering if it would be better to return an
UNKNOWN_ERROR (say) and let the client raise that to the user instead of
just timing out.
Thanks,
Jason
On Fri, Jul 20, 2018 at 10:00
gt;
> Thanks,
>
> On Fri, Jul 20, 2018 at 11:02 PM Jason Gustafson
> wrote:
>
> > Hey Manikumar,
> >
> > This looks good. Do we have to keep the current behavior when handling
> old
> > DeleteTopics versions? I'm wondering if it would be better to ret
Thanks, +1 from me.
On Fri, Jul 20, 2018 at 11:41 AM, Manikumar
wrote:
> Thanks for the feedback, sounds good to me. Updated the KIP.
>
> On Sat, Jul 21, 2018 at 12:04 AM Jason Gustafson
> wrote:
>
> > After thinking about it, perhaps a better option is INVALID_REQUEST
makes sense to name something an empty string as far
> as
> > I'm aware - to me it seems like potential for confusion
> >
> >
> > On Fri, Jul 20, 2018 at 10:22 AM Rajini Sivaram >
> > wrote:
> >
> > > +1 to deprecate use of "" as gr
rlier suggestion "we
> just need to bump the OffsetCommit request API and only accept the offset
> commit for older versions.". Maybe I'm missing something?
>
> Thanks!
> --Vahid
>
>
>
>
> From: Jason Gustafson
> To: dev
> Date: 07/23/201
ng Lin wrote:
> >
> > > Hey Jason,
> > >
> > > It is a great summary. The solution sounds good. I might have minor
> > > comments regarding the method name. But we can discuss that minor
> points
> > > later after we reach consensus on the high
>
> Assumptions:
> * 2.1: The target release version for this KIP
> * 3.0: The next major release
>
> Please advise if you see an issue; otherwise, I'll update the KIP
> accordingly.
>
> Thanks!
> --Vahid
>
>
>
>
> From: Jason Gustafson
> To:
g, etc.
>
> best,
> Colin
>
>
> On Thu, Jul 26, 2018, at 11:50, Vahid S Hashemian wrote:
> > Hi Jason,
> >
> > That makes sense.
> > I have updated the KIP based on the recent feedback.
> >
> > Thanks!
> > --Vahid
> >
> >
> &
th
> MetadataResponse containing leader epoch?
>
> Thanks,
> Anna
>
> On Wed, Jul 25, 2018 at 1:44 PM Jason Gustafson
> wrote:
>
> > Hi All,
> >
> > I have made some updates to the KIP. As many of you know, a side project
> of
> > mine has been specifying
+1
I did the quickstart and verified the documentation (upgrade notes and
notable changes). Thanks Rajini!
On Fri, Jul 27, 2018 at 8:10 AM, Gwen Shapira wrote:
> +1
>
> Quickstart on binaries, built from sources, verified signatures -- it
> really is Rajini. Thank you!
>
> Gwen
>
> On Thu, Jul
Hey Boyang,
Thanks for the KIP. I think my main question is in the same vein as James'.
The problem is that the coordinator needs to be able to identify which
instance of a particular memberId is the active one. For EOS, each
transactionalId gets an epoch. When a new producer is started, it bumps
name the method to e.g.
> seekToLastConsumedMessage()?
>
> 7) Per point 3 in Jun's comment, would it be useful to explicitly specify
> in the KIP that we will log the truncation event if user has turned on auto
> offset reset policy?
>
>
> Thanks,
> Dong
>
>
>
Hey Stanislav,
Thanks for the KIP. I think the goal is to allow users to seek past a
records which cannot be parsed for whatever reason. However, it's a little
annoying that you need to catch two separate types to handle this. I'm
wondering if it makes sense to expose an interface like
`Unconsumab
oud users to coordinate
> consumer/stream instances more freely. Honestly, I'm interested in Jason's
> registration id proposal and open to more voices, but I feel it would be
> more complex than the current KIP for user to understand. Hope this makes
> sense, Jason.
>
>
&g
ber...@appnexus.com>
> wrote:
>
> > Jason,
> >
> > I really appreciate the broader conversation that you are bringing
> up here.
> >
> > I've been working on an application that does streaming joins for a
> while
> > n
that way.
> Regardless, I believe this is best left out for another KIP as I feel it
> would warrant a bigger discussion
>
> Best,
> Stanislav
>
> On Mon, Jul 30, 2018 at 9:34 PM Jason Gustafson
> wrote:
>
> > Hey Stanislav,
> >
> > Thanks for the KIP.
t / feedback / objection I'll start a vote
> soon.
>
> Thanks.
> --Vahid
>
>
>
> From: Jason Gustafson
> To: dev
> Date: 07/27/2018 10:38 AM
> Subject:Re: [DISCUSS] KIP-289: Improve the default group id
> behavior in KafkaConsumer
>
Hey Brett,
I'd suggest going ahead with a KIP if you already have some ideas about it.
One of the complications you may run into is that the active segment is not
cleaned at present.
I went ahead and gave you wiki permission. I assumed your username is
brettrann, so let me know if it's different.
Hey Stanislav,
I should have noticed it earlier from your example, but I just realized
that interfaces don't mix well with exceptions. There is no way to catch
the interface type, which means you have to depend on instanceof checks,
which is not very conventional. At the moment, we raise
Serializa
Hey All,
Another day, another KIP. This one is hopefully straightforward:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-352%3A+Distinguish+URPs+caused+by+reassignment.
Have a look and let me know what you think!
Thanks,
Jason
Hey Kevin,
Thanks for the KIP. I like Mickael's suggestion to
add --under-minisr-partitions since it fits with the metric we already
expose. It's also a good question whether there should be a separate
category for partitions which are right at min.isr. I'm reluctant to add
new categories, but I a
08/02/2018 11:23 AM
> Subject:Re: [DISCUSS] KIP-289: Improve the default group id
> behavior in KafkaConsumer
>
>
>
> Thanks, Jason. I don't have a very strong opinion on this. But like you
> said, if we skip bumping the RPC versions, this would be a smaller change,
;
>
> Thanks,
> Dong
>
>
> On Mon, Jul 30, 2018 at 9:33 AM, Jason Gustafson
> wrote:
>
> > Hey Dong,
> >
> > Thanks for the detailed review. Responses below:
> >
> > 1/2: Thanks for noticing the inconsistency. Would it be reasonable to
> &
+1 Thanks Vahid.
On Thu, Aug 2, 2018 at 1:27 PM, Vahid S Hashemian wrote:
> Hi everyone,
>
> I believe the feedback on this KIP has been addressed so far. So I'd like
> to start a vote.
> The KIP:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 341%3A+Update+Sticky+Assignor%27s+User+D
1 - 100 of 3206 matches
Mail list logo
