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
[
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
[
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-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
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-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
[
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
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=15420026#comment-15420026
]
Maysam Yabandeh commented on KAFKA-3924:
Thanks [~aozeritsky] Let me run my unders
[
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=15420038#comment-15420038
]
Alexey Ozeritskiy commented on KAFKA-3924:
--
{quote}
KafakRequestHandler is proces
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=15420049#comment-15420049
]
Maysam Yabandeh commented on KAFKA-3924:
Thanks [~aozeritsky]. That makes sense.
[
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-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: MemBytesBenchmark.txt
> Investigate feasibility of caching bytes vs. records
> ---
[
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-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
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
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
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
[
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:
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-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
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-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
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
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
28 matches
Mail list logo
