Vinoth Chandar created KAFKA-10258:
--
Summary: Get rid of use_zk_connection flag in kafka.py public
methods
Key: KAFKA-10258
URL: https://issues.apache.org/jira/browse/KAFKA-10258
Project: Kafka
Vinoth Chandar created KAFKA-10213:
--
Summary: Prefer --bootstrap-server in ducktape tests for Kafka
clients
Key: KAFKA-10213
URL: https://issues.apache.org/jira/browse/KAFKA-10213
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-10138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-10138.
Resolution: Fixed
> Prefer --bootstrap-server for reassign_partitions command in duckt
Vinoth Chandar created KAFKA-10174:
--
Summary: Prefer --bootstrap-server ducktape tests using
kafka_configs.sh
Key: KAFKA-10174
URL: https://issues.apache.org/jira/browse/KAFKA-10174
Project: Kafka
Vinoth Chandar created KAFKA-10138:
--
Summary: Prefer --bootstrap-server for reassign_partitions command
in ducktape tests
Key: KAFKA-10138
URL: https://issues.apache.org/jira/browse/KAFKA-10138
Vinoth Chandar created KAFKA-10131:
--
Summary: Minimize use of --zookeeper flag in ducktape tests
Key: KAFKA-10131
URL: https://issues.apache.org/jira/browse/KAFKA-10131
Project: Kafka
Issue
Vinoth Chandar created KAFKA-10071:
--
Summary: TopicCommand tool should make more efficient metadata
calls to Kafka Servers
Key: KAFKA-10071
URL: https://issues.apache.org/jira/browse/KAFKA-10071
[
https://issues.apache.org/jira/browse/KAFKA-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-9512.
---
Resolution: Fixed
Closing since the PR is now landed
> Flaky T
Chiming in a bit late here..
+1 This is a very valid improvement. Avoiding doing gets on irrelevant
partitions will improve performance and efficiency for IQs.
As an incremental improvement to the current APIs, adding an option to
filter out based on partitions makes sense
On Mon, Jan
Vinoth Chandar created KAFKA-9431:
-
Summary: Expose API in KafkaStreams to fetch all local offset lags
Key: KAFKA-9431
URL: https://issues.apache.org/jira/browse/KAFKA-9431
Project: Kafka
Vinoth Chandar created KAFKA-9430:
-
Summary: Tighten up lag estimates when source topic optimization
is on
Key: KAFKA-9430
URL: https://issues.apache.org/jira/browse/KAFKA-9430
Project: Kafka
Vinoth Chandar created KAFKA-9429:
-
Summary: Allow ability to control whether stale reads out of state
stores are desirable
Key: KAFKA-9429
URL: https://issues.apache.org/jira/browse/KAFKA-9429
Vinoth Chandar created KAFKA-9428:
-
Summary: Expose standby information in KafkaStreams via
queryMetadataForKey API
Key: KAFKA-9428
URL: https://issues.apache.org/jira/browse/KAFKA-9428
Project
y
> want to query stall state during recovery or not).
>
> It's unclear to me though atm, how a user would opt-in/opt-out and what
> the default should be (maybe better to throw the exception by default to
> have strong consistency guarantees by default?)
>
>
> -Matth
+1 on merging `StreamsNotRunningException` and
`StateStoreNotAvailableException`, both exceptions are fatal anyway. IMO its
best to have these exceptions be about the state store (and not streams state),
to easier understanding.
Additionally, KIP-535 allows for querying of state stores in
Thanks, everyone involved!
On Mon, Nov 18, 2019 at 7:51 AM John Roesler wrote:
> Thanks to you, also, Navinder!
>
> Looking forward to getting this feature in.
> -John
>
> On Sun, Nov 17, 2019 at 11:34 PM Navinder Brar
> wrote:
> >
> > Hello all,
> >
> > With 4 binding +1 votes from Guozhang
choice in the future.
>
> That said, it's just my opinion. I'm fine either way.
>
> 20. Vinoth's reply makes sense to me, fwiw.
>
> Beyond these two points, I'm happy with the current proposal.
>
> Thanks again,
> -John
>
> On Thu, Nov 14, 2019 at 4:48 AM Vinoth Chand
ot;Rejected alternative" sections to avoid that we
> cycle back to old proposal (including the reason _why_ they got rejected).
>
>
> Thanks a lot!
>
>
> -Matthias
>
>
>
> On 11/13/19 7:10 PM, Vinoth Chandar wrote:
> > Given we have had a healthy discussion
tions for the task: some of
> them
> > > may also act as changelog topics but these are exceptional cases; for
> > > standby tasks the "standbyTopicPartitions" are actually the changelog
> > > topics of the task. So maybe renaming it to
> "standbyChange
se IQ
> to begin with), it might be worth to maintain an internal flag
> `updateTimeLagEnabled` that is set to `false` initially and only set to
> `true` on the first call of a user to get standby-metadata.
>
>
> -Matthias
>
>
>
> On 11/4/19 5:13 PM, Vinoth Chandar wrote:
>
Ping :) Any thoughts?
On Mon, Nov 4, 2019 at 5:13 PM Vinoth Chandar wrote:
> >> I'm having some trouble wrapping my head around what race conditions
> might occur, other than the fundamentally broken state in which different
> instances are running totally different topolog
here are already separate API
> > calls in the proposal, one for time-lag, and another for offset-lag,
> > so are they not already broken up? FWIW, yes, I agree, the offset lag
> > is already locally known, so we don't need to build in an extra
> > synchronous broker API ca
if we don't have a
> > configurable setting. This gives the users the flexibility to the users
> to
> > serve their requirements as at the end of the day it would take CPU
> cycles.
> > I am ok with starting it with a default and see how it goes based upon
> > feedback.
> > >
&
w
> these new interfaces would play together. And thanks again for the
> update!
> -John
>
> On Thu, Oct 31, 2019 at 2:41 PM John Roesler wrote:
> >
> > Hey Vinoth,
> >
> > I started going over the KIP again yesterday. There are a lot of
> > updates
t; separate functions. We already have one which returns streamsMetadata for
> active tasks, and now we can add another one for standbys.
>
>
>
> On Saturday, 26 October, 2019, 03:55:16 am IST, Vinoth Chandar <
> vchan...@confluent.io> wrote:
>
> +1 to Sophie's sug
ead of
> letting
> > >> the storeMetadataAPI to return the staleness information, letting the
> > >> client to query either active or standby and letting standby query
> > response
> > >> to include both the values + timestamp (or lag, as in diffs of
&
data API / Assignment,Subscription / and Heartbeat as
> slim as possible.
>
> Side note: I do think that some time soon, we'll have to add a library
> for IQ server/clients. I think that this logic will start to get
> pretty complex.
>
> I hope this thinking is reasonably clear
method only returns a handle to
> >> stores of active(processing) tasks. How can a user actually get a handle
> >> to an store of an active(restoring) or standby task for querying? Seems
> >> we should add a new method to get standby handles? Changing the
> >&
994 is closed(by you). As suggested, we will replace
> > "replica" with "standby".
> > >
> > > In the new API, "StreamsMetadataState::allMetadataForKey(boolean
> > enableReplicaServing, String storeName, K key, Serializer
> > keyS
[
https://issues.apache.org/jira/browse/KAFKA-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-8994.
---
Resolution: Duplicate
> Streams should expose standby replication information & allo
[
https://issues.apache.org/jira/browse/KAFKA-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar reopened KAFKA-8994:
---
> Streams should expose standby replication information & allow stale reads of
> s
[
https://issues.apache.org/jira/browse/KAFKA-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-8994.
---
Resolution: Fixed
> Streams should expose standby replication information & allo
nother state before Restoring or check the
> difference between last committed offset and current position. Only if it
> is within a permissible range (say 1) we will serve from Restoring the
> state of Active.
>
>
> On Wednesday, 16 October, 2019, 10:01:35
thoughts. Can we also work this into the KIP?
I already implemented A to unblock myself for now. Seems feasible to do.
On Tue, Oct 15, 2019 at 12:21 PM Vinoth Chandar
wrote:
> >>I get your point. But suppose there is a replica which has just become
> active, so in that case replic
n a replica in such case.
>
> Finally, we may need to introduce a configuration to control this. Some
> users may prefer errors to stale data. Can we also add it to the KIP?>>
> Will add this.
>
> Regards,
> Navinder
>
>
> On2019/10/14 16:56:49, Vinoth Chandar wrote:
>
Hi Navinder,
Thanks for sharing the KIP! Few thoughts
- Can we link the JIRA, discussion thread also to the KIP
- Based on the discussion on KAFKA-6144, I was under the impression that
this KIP is also going to cover exposing of the standby information in
StreamsMetadata and thus subsume
Vinoth Chandar created KAFKA-8994:
-
Summary: Streams should expose standby replication information &
allow stale reads of state store
Key: KAFKA-8994
URL: https://issues.apache.org/jira/browse/KAFKA-
[
https://issues.apache.org/jira/browse/KAFKA-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-8839.
---
Resolution: Fixed
Closing since the PR has been merged
> Improve logging in Kafka Stre
[
https://issues.apache.org/jira/browse/KAFKA-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-8913.
---
Resolution: Fixed
> Document topic based configs & ISR settings for Strea
Vinoth Chandar created KAFKA-8913:
-
Summary: Document topic based configs & ISR settings for Streams
apps
Key: KAFKA-8913
URL: https://issues.apache.org/jira/browse/KAFKA-8913
Project: K
+1 (non-binding).
On Fri, Sep 6, 2019 at 12:46 AM Bruno Cadonna wrote:
> +1 (non-binding)
>
> On Fri, Sep 6, 2019 at 12:32 AM Guozhang Wang wrote:
> >
> > +1 (binding).
> >
> > On Thu, Sep 5, 2019 at 2:47 PM John Roesler wrote:
> >
> > > Hello, all,
> > >
> > > After a great discussion, I'd
Vinoth Chandar created KAFKA-8870:
-
Summary: Prevent dirty reads of Streams state store from
Interactive queries
Key: KAFKA-8870
URL: https://issues.apache.org/jira/browse/KAFKA-8870
Project: Kafka
Vinoth Chandar created KAFKA-8839:
-
Summary: Improve logging in Kafka Streams around debugging task
lifecycle
Key: KAFKA-8839
URL: https://issues.apache.org/jira/browse/KAFKA-8839
Project: Kafka
[
https://issues.apache.org/jira/browse/KAFKA-8831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinoth Chandar resolved KAFKA-8831.
---
Resolution: Not A Problem
I will think about better logging and put up a patch. Closing
Vinoth Chandar created KAFKA-8810:
-
Summary: Add mechanism to detect topology mismatch between streams
instances
Key: KAFKA-8810
URL: https://issues.apache.org/jira/browse/KAFKA-8810
Project: Kafka
Vinoth Chandar created KAFKA-8799:
-
Summary: Support ability to pass global user data to consumers
during Assignment
Key: KAFKA-8799
URL: https://issues.apache.org/jira/browse/KAFKA-8799
Project
I am interested in picking up KAFKA-7149
Can I be added to the list? My jira id : vinoth
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14985707#comment-14985707
]
Vinoth Chandar commented on KAFKA-2580:
---
[~jkreps] ah ok. point taken :)
> Kafka Broker keeps f
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14984243#comment-14984243
]
Vinoth Chandar commented on KAFKA-2580:
---
Based on this, looks like we can close this?
>> So
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14963574#comment-14963574
]
Vinoth Chandar commented on KAFKA-2580:
---
[~jjkoshy] Good point. if I understand correctly, even
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941910#comment-14941910
]
Vinoth Chandar commented on KAFKA-2580:
---
A LRU file handle is something very commonly employed
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908298#comment-14908298
]
Vinoth Chandar commented on KAFKA-2580:
---
More context on how we determined this
{code}
vinoth@kafka
[
https://issues.apache.org/jira/browse/KAFKA-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14908910#comment-14908910
]
Vinoth Chandar commented on KAFKA-2580:
---
Thanks for jumping in [~guozhang] .we have 256MB segment
Vinoth Chandar created KAFKA-2580:
-
Summary: Kafka Broker keeps file handles open for all log files
(even if its not written to/read from)
Key: KAFKA-2580
URL: https://issues.apache.org/jira/browse/KAFKA-2580
54 matches
Mail list logo
