This is to start off a discussion on the above KIP at
https://cwiki.apache.org/confluence/display/KAFKA/KIP-59%3A+Proposal+for+a+kafka+broker+commandThe
proposal is to fill the void of a command line tool/utility that can provide
information on the brokers in a Kafka cluster.
The code is availabl
Hi Gwen,
Thanks for the reply.
I will initiate another discussion thread also.
Here's the earlier thread -
https://mail-archives.apache.org/mod_mbox/kafka-users/201605.mbox/%3c545407a926534b4fbf3a62628c725a4cdcb5c...@ord-exdb102.corp.valueclick.com%3E
I guess I jumped the gun and did the discussio
[
https://issues.apache.org/jira/browse/KAFKA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420195#comment-15420195
]
Ben Manes commented on KAFKA-3973:
--
Measuring on both put() and removeEldestEntry() is sl
GitHub user hachikuji opened a pull request:
https://github.com/apache/kafka/pull/1734
KAFKA-3916: Check for disconnects properly before sending from the
controller
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/hachikuji/kafka
[
https://issues.apache.org/jira/browse/KAFKA-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420154#comment-15420154
]
ASF GitHub Bot commented on KAFKA-3916:
---
GitHub user hachikuji opened a pull request
Jason Gustafson created KAFKA-4038:
--
Summary: Transient failure in
DeleteTopicsRequestTest.testErrorDeleteTopicRequests
Key: KAFKA-4038
URL: https://issues.apache.org/jira/browse/KAFKA-4038
Project:
[
https://issues.apache.org/jira/browse/KAFKA-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420118#comment-15420118
]
ASF GitHub Bot commented on KAFKA-4037:
---
GitHub user ewencp opened a pull request:
GitHub user ewencp opened a pull request:
https://github.com/apache/kafka/pull/1733
KAFKA-4037: Make Connect REST API retries aware of 409 CONFLICT errors
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ewencp/kafka rest-api-retr
Ewen Cheslack-Postava created KAFKA-4037:
Summary: Transient failure in ConnectRestApiTest
Key: KAFKA-4037
URL: https://issues.apache.org/jira/browse/KAFKA-4037
Project: Kafka
Issue T
On Mon, Aug 8, 2016 at 2:44 PM, Grant Henke wrote:
> Thank you for the feedback everyone. Below I respond to the last batch of
> emails:
>
> You mention that "delete" actions
> > will get processed before "add" actions, which makes sense to me. An
> > alternative to avoid the confusion in the fir
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420091#comment-15420091
]
Todd Palino commented on KAFKA-3959:
If that's the case, then the default should be se
[
https://issues.apache.org/jira/browse/KAFKA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420061#comment-15420061
]
Bill Bejeck commented on KAFKA-3973:
Attaching JMH benchmark results, removing the pre
[
https://issues.apache.org/jira/browse/KAFKA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck updated KAFKA-3973:
---
Attachment: MemBytesBenchmark.txt
> Investigate feasibility of caching bytes vs. records
> ---
[
https://issues.apache.org/jira/browse/KAFKA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck updated KAFKA-3973:
---
Attachment: (was: MemoryLRUCache.java)
> Investigate feasibility of caching bytes vs. records
> --
[
https://issues.apache.org/jira/browse/KAFKA-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Bejeck updated KAFKA-3973:
---
Attachment: (was: CachingPerformanceBenchmarks.java)
> Investigate feasibility of caching bytes vs
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420049#comment-15420049
]
Maysam Yabandeh commented on KAFKA-3924:
Thanks [~aozeritsky]. That makes sense.
I'm supportive of this for 2 reasons -
1. The community has been looking for predictability and this allows us to
offer that to Kafka users
2. Trunk stability and the ability to release from trunk. This is important
for several companies and more frequent releases means higher quality and
faster d
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420038#comment-15420038
]
Alexey Ozeritskiy commented on KAFKA-3924:
--
{quote}
KafakRequestHandler is proces
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Ozeritskiy updated KAFKA-3924:
-
Attachment: deadlock-stack
> Data loss due to halting when LEO is larger than leader's LEO
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420026#comment-15420026
]
Maysam Yabandeh commented on KAFKA-3924:
Thanks [~aozeritsky] Let me run my unders
Plus one. This is a good direction to move towards.
The frequency of releases would probably depend on how long it takes
to certify the release.
> On Aug 13, 2016, at 10:18 AM, Jay Kreps wrote:
>
> I'm +1.
>
> I've seen this both ways and I really do think that time-based releases
> tend to sca
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420014#comment-15420014
]
Alexey Ozeritskiy commented on KAFKA-3924:
--
You are right. Shutdown hook is joini
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420004#comment-15420004
]
Maysam Yabandeh commented on KAFKA-3924:
Thanks [~aozeritsky]. I am not sure if I
I'm +1.
I've seen this both ways and I really do think that time-based releases
tend to scale better with more developers doing parallel work (I think the
probability of at least one feature slipping as you have more and more
developers gets very high, and if that means the release slips then the
[
https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419992#comment-15419992
]
Grant Henke commented on KAFKA-3959:
[~onurkaraman] I understand the need for a quick
[
https://issues.apache.org/jira/browse/KAFKA-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419984#comment-15419984
]
Flavio Junqueira commented on KAFKA-1211:
-
[~junrao]
bq. the leader needs to firs
[
https://issues.apache.org/jira/browse/KAFKA-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419873#comment-15419873
]
Alexey Ozeritskiy commented on KAFKA-3924:
--
I've got the deadlock with that patch
To add to what Gwen said (which makes sense to me), here's a link to the
Cassandra release model:
http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/
It involves monthly releases, so more aggressive than what is being
proposed, but they follow a tick tock model where a feature relea
28 matches
Mail list logo
