[jira] [Updated] (KAFKA-4447) Controller resigned but it also acts as a controller for a long time

[ https://issues.apache.org/jira/browse/KAFKA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4447: --- Labels: reliability (was: ) > Controller resigned but it also acts as a controller for a long time

[jira] [Updated] (KAFKA-4375) Kafka consumer may swallow some interrupts meant for the calling thread

[ https://issues.apache.org/jira/browse/KAFKA-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4375: --- Fix Version/s: 0.10.2.0 > Kafka consumer may swallow some interrupts meant for the calling thread >

[jira] [Resolved] (KAFKA-4365) In case async producer closes the TCP connection to Kafka broker, last sent messages might be lost.

[ https://issues.apache.org/jira/browse/KAFKA-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-4365. Resolution: Duplicate Duplicate of KAFKA-3703. > In case async producer closes the TCP connection

[jira] [Resolved] (KAFKA-3889) Change default Scala version to 2.11

[ https://issues.apache.org/jira/browse/KAFKA-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma resolved KAFKA-3889. Resolution: Not A Problem This is as intended. We may move to 2.11 as the default once we drop

[jira] [Updated] (KAFKA-2758) Improve Offset Commit Behavior

[ https://issues.apache.org/jira/browse/KAFKA-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-2758: --- Labels: newbiee reliability (was: newbiee) > Improve Offset Commit Behavior >

[jira] [Updated] (KAFKA-4009) Data corruption or EIO leads to data loss

[ https://issues.apache.org/jira/browse/KAFKA-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4009: --- Labels: reliability (was: ) > Data corruption or EIO leads to data loss >

[jira] [Created] (KAFKA-4471) KafkaConsumer unpauses queues after subscribe()

Sergey Alaev created KAFKA-4471: --- Summary: KafkaConsumer unpauses queues after subscribe() Key: KAFKA-4471 URL: https://issues.apache.org/jira/browse/KAFKA-4471 Project: Kafka Issue Type: Bug

[jira] [Updated] (KAFKA-4460) Consumer stops getting messages when partition leader dies

[ https://issues.apache.org/jira/browse/KAFKA-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4460: --- Labels: reliability (was: ) > Consumer stops getting messages when partition leader dies >

[jira] [Updated] (KAFKA-3971) Consumers drop from coordinator and cannot reconnect

[ https://issues.apache.org/jira/browse/KAFKA-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3971: --- Labels: reliability (was: ) > Consumers drop from coordinator and cannot reconnect >

[jira] [Updated] (KAFKA-1429) Yet another deadlock in controller shutdown

[ https://issues.apache.org/jira/browse/KAFKA-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-1429: --- Labels: reliability (was: ) > Yet another deadlock in controller shutdown >

[jira] [Updated] (KAFKA-3083) a soft failure in controller may leave a topic partition in an inconsistent state

[ https://issues.apache.org/jira/browse/KAFKA-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3083: --- Labels: reliability (was: ) > a soft failure in controller may leave a topic partition in an

[jira] [Updated] (KAFKA-4360) Controller may deadLock when autoLeaderRebalance encounter zk expired

[ https://issues.apache.org/jira/browse/KAFKA-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4360: --- Labels: bugfix reliability (was: bugfix) > Controller may deadLock when autoLeaderRebalance

[jira] [Updated] (KAFKA-3040) Broker didn't report new data after change in leader

[ https://issues.apache.org/jira/browse/KAFKA-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3040: --- Labels: reliability (was: ) > Broker didn't report new data after change in leader >

[jira] [Updated] (KAFKA-2082) Kafka Replication ends up in a bad state

[ https://issues.apache.org/jira/browse/KAFKA-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-2082: --- Labels: reliability zkclient-problems (was: zkclient-problems) > Kafka Replication ends up in a bad

Re: [VOTE] KIP-93: Improve invalid timestamp handling in Kafka Streams

+1 (binding) I second Ewen's point about compatibility. On Wed, Nov 30, 2016 at 2:53 AM, Damian Guy wrote: > +1 > > On Wed, 30 Nov 2016 at 05:58 Ewen Cheslack-Postava > wrote: > > > +1 (binding). > > > > Also, see my notes in discussion thread around

[jira] [Updated] (KAFKA-4471) KafkaConsumer unpauses partitions after subscribe()

[ https://issues.apache.org/jira/browse/KAFKA-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Alaev updated KAFKA-4471: Description: How to reproduce: 1. initialize KafkaConsumer and subscribe to some topics by calling

[jira] [Updated] (KAFKA-4464) Clean shutdown of broker fails due to controller error

[ https://issues.apache.org/jira/browse/KAFKA-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4464: --- Labels: reliability (was: ) > Clean shutdown of broker fails due to controller error >

[jira] [Updated] (KAFKA-4358) Following a hung broker, newly elected leader is unnecessarily slow assuming leadership because of ReplicaFetcherThread

[ https://issues.apache.org/jira/browse/KAFKA-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4358: --- Fix Version/s: 0.10.2.0 > Following a hung broker, newly elected leader is unnecessarily slow

[jira] [Updated] (KAFKA-4138) Producer data write network traffic to kafka brokers is increased for 50%

[ https://issues.apache.org/jira/browse/KAFKA-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4138: --- Labels: performance (was: ) > Producer data write network traffic to kafka brokers is increased for

[jira] [Updated] (KAFKA-3795) Transient system test failure upgrade_test.TestUpgrade

[ https://issues.apache.org/jira/browse/KAFKA-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3795: --- Labels: reliability (was: ) > Transient system test failure upgrade_test.TestUpgrade >

[jira] [Commented] (KAFKA-1194) The kafka broker cannot delete the old log files after the configured time

[ https://issues.apache.org/jira/browse/KAFKA-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708838#comment-15708838 ] Abhi commented on KAFKA-1194: - For me i tried the build with this config of server-properties

[jira] [Updated] (KAFKA-4412) Replication fetch stuck in loop on offset null

[ https://issues.apache.org/jira/browse/KAFKA-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4412: --- Labels: reliability (was: ) > Replication fetch stuck in loop on offset null >

[jira] [Updated] (KAFKA-3410) Unclean leader election and "Halting because log truncation is not allowed"

[ https://issues.apache.org/jira/browse/KAFKA-3410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3410: --- Labels: reliability (was: ) > Unclean leader election and "Halting because log truncation is not

[jira] [Updated] (KAFKA-3919) Broker faills to start after ungraceful shutdown due to non-monotonically incrementing offsets in logs

[ https://issues.apache.org/jira/browse/KAFKA-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3919: --- Labels: reliability (was: ) > Broker faills to start after ungraceful shutdown due to

[jira] [Updated] (KAFKA-1342) Slow controlled shutdowns can result in stale shutdown requests

[ https://issues.apache.org/jira/browse/KAFKA-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-1342: --- Labels: newbie++ newbiee reliability (was: newbie++ newbiee) > Slow controlled shutdowns can result

[jira] [Updated] (KAFKA-3693) Lost highwatermark at broker start-up

[ https://issues.apache.org/jira/browse/KAFKA-3693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3693: --- Labels: reliability (was: ) > Lost highwatermark at broker start-up >

[jira] [Updated] (KAFKA-1120) Controller could miss a broker state change

[ https://issues.apache.org/jira/browse/KAFKA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-1120: --- Labels: reliability (was: ) > Controller could miss a broker state change >

[jira] [Updated] (KAFKA-3959) __consumer_offsets wrong number of replicas at startup

[ https://issues.apache.org/jira/browse/KAFKA-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3959: --- Labels: reliability (was: ) > __consumer_offsets wrong number of replicas at startup >

[jira] [Updated] (KAFKA-3968) fsync() is not called on parent directory when new FileMessageSet is flushed to disk

[ https://issues.apache.org/jira/browse/KAFKA-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3968: --- Labels: reliability (was: ) > fsync() is not called on parent directory when new FileMessageSet is

[jira] [Updated] (KAFKA-3994) Deadlock between consumer heartbeat expiration and offset commit.

[ https://issues.apache.org/jira/browse/KAFKA-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3994: --- Labels: reliability (was: ) > Deadlock between consumer heartbeat expiration and offset commit. >

[jira] [Updated] (KAFKA-4150) Facing Message Loss When trying rolling updates

[ https://issues.apache.org/jira/browse/KAFKA-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4150: --- Labels: reliability (was: ) > Facing Message Loss When trying rolling updates >

[jira] [Updated] (KAFKA-1211) Hold the produce request with ack > 1 in purgatory until replicas' HW has larger than the produce offset

[ https://issues.apache.org/jira/browse/KAFKA-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-1211: --- Labels: reliability (was: ) > Hold the produce request with ack > 1 in purgatory until replicas' HW

[jira] [Updated] (KAFKA-3924) 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:all-tabpanel ] Ismael Juma updated KAFKA-3924: --- Labels: reliability (was: ) > Data loss due to halting when LEO is larger than leader's LEO >

[jira] [Updated] (KAFKA-4471) KafkaConsumer unpauses partitions after subscribe()

[ https://issues.apache.org/jira/browse/KAFKA-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Alaev updated KAFKA-4471: Summary: KafkaConsumer unpauses partitions after subscribe() (was: KafkaConsumer unpauses queues

[jira] [Updated] (KAFKA-4433) Kafka Controller Does not send a LeaderAndIsr to old leader of a topicPartition during reassignment, if the old leader is not a part of the new assigned replicas

[ https://issues.apache.org/jira/browse/KAFKA-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4433: --- Labels: reliability (was: ) > Kafka Controller Does not send a LeaderAndIsr to old leader of a >

[jira] [Updated] (KAFKA-4358) Following a hung broker, newly elected leader is unnecessarily slow assuming leadership because of ReplicaFetcherThread

[ https://issues.apache.org/jira/browse/KAFKA-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4358: --- Labels: reliability (was: ) > Following a hung broker, newly elected leader is unnecessarily slow

[jira] [Commented] (KAFKA-1194) The kafka broker cannot delete the old log files after the configured time

[ https://issues.apache.org/jira/browse/KAFKA-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709138#comment-15709138 ] Soumyajit Sahu commented on KAFKA-1194: --- [~haraldk] could you please provide all of your

[jira] [Updated] (KAFKA-1194) The kafka broker cannot delete the old log files after the configured time

[ https://issues.apache.org/jira/browse/KAFKA-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhi updated KAFKA-1194: Attachment: screenshot-1.png > The kafka broker cannot delete the old log files after the configured time >

[jira] [Commented] (KAFKA-4471) KafkaConsumer unpauses partitions after subscribe()

[ https://issues.apache.org/jira/browse/KAFKA-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708867#comment-15708867 ] Sergey Alaev commented on KAFKA-4471: - We are using single KafkaConsumer instance to manage many

[jira] [Updated] (KAFKA-4084) automated leader rebalance causes replication downtime for clusters with too many partitions

[ https://issues.apache.org/jira/browse/KAFKA-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4084: --- Labels: reliability (was: ) > automated leader rebalance causes replication downtime for clusters

[jira] [Updated] (KAFKA-4039) Exit Strategy: using exceptions instead of inline invocation of exit/halt

[ https://issues.apache.org/jira/browse/KAFKA-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4039: --- Labels: reliability (was: ) > Exit Strategy: using exceptions instead of inline invocation of

[jira] [Updated] (KAFKA-4086) long processing consumer restart will stall

[ https://issues.apache.org/jira/browse/KAFKA-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4086: --- Labels: consumer reliability (was: consumer) > long processing consumer restart will stall >

[jira] [Updated] (KAFKA-3039) Temporary loss of leader resulted in log being completely truncated

[ https://issues.apache.org/jira/browse/KAFKA-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-3039: --- Labels: reliability (was: ) > Temporary loss of leader resulted in log being completely truncated >

[jira] [Updated] (KAFKA-4305) Possible race condition in log segment truncation and Kafka Request Handler

[ https://issues.apache.org/jira/browse/KAFKA-4305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4305: --- Labels: reliability (was: ) > Possible race condition in log segment truncation and Kafka Request

[jira] [Updated] (KAFKA-4229) Controller can't start after several zk expired event

[ https://issues.apache.org/jira/browse/KAFKA-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4229: --- Labels: reliability (was: ) > Controller can't start after several zk expired event >

[jira] [Updated] (KAFKA-4418) Broker Leadership Election Fails If Missing ZK Path Raises Exception

[ https://issues.apache.org/jira/browse/KAFKA-4418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ismael Juma updated KAFKA-4418: --- Labels: reliability (was: ) > Broker Leadership Election Fails If Missing ZK Path Raises Exception >

[jira] [Commented] (KAFKA-4471) KafkaConsumer unpauses partitions after subscribe()

[ https://issues.apache.org/jira/browse/KAFKA-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709355#comment-15709355 ] Vahid Hashemian commented on KAFKA-4471: [~salaev] Thanks for reporting the issue and providing

Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag

Hi, Michael, Thanks for the KIP. A few comments below. 1. The message format change contains "HeadersLength Headers". Is that intended? 2. For compressed messageset, is the tombstone bit only set at the shallow level? Do we always leave that bit in the wrapper message unset? An alternative is

[jira] [Resolved] (KAFKA-3309) Update Protocol Documentation WIP patch

[ https://issues.apache.org/jira/browse/KAFKA-3309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish K Singh resolved KAFKA-3309. --- Resolution: Duplicate > Update Protocol Documentation WIP patch >

[jira] [Commented] (KAFKA-4469) Consumer throughput regression caused by decrease in max.poll.records

[ https://issues.apache.org/jira/browse/KAFKA-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709573#comment-15709573 ] Jason Gustafson commented on KAFKA-4469: [~ijuma] suggests that the inefficiency is not

[jira] [Updated] (KAFKA-1911) Log deletion on stopping replicas should be async

[ https://issues.apache.org/jira/browse/KAFKA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Koshy updated KAFKA-1911: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Log deletion on stopping replicas

[jira] [Updated] (KAFKA-3715) Higher granularity streams metrics

[ https://issues.apache.org/jira/browse/KAFKA-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eno Thereska updated KAFKA-3715: Assignee: aarti gupta (was: Eno Thereska) > Higher granularity streams metrics >

[jira] [Commented] (KAFKA-4454) Authorizer should also include the Principal generated by the PrincipalBuilder.

[ https://issues.apache.org/jira/browse/KAFKA-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709335#comment-15709335 ] Mayuresh Gharat commented on KAFKA-4454: [~jjkoshy] [~ashishsinghdev] [~parth.brahmbhatt] [~ijuma]

[jira] [Assigned] (KAFKA-4471) KafkaConsumer unpauses partitions after subscribe()

[ https://issues.apache.org/jira/browse/KAFKA-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vahid Hashemian reassigned KAFKA-4471: -- Assignee: Vahid Hashemian > KafkaConsumer unpauses partitions after subscribe() >

[jira] [Commented] (KAFKA-1911) Log deletion on stopping replicas should be async

[ https://issues.apache.org/jira/browse/KAFKA-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709379#comment-15709379 ] ASF GitHub Bot commented on KAFKA-1911: --- Github user asfgit closed the pull request at:

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

Thanks, Ashish. I think the idea of having the client make an ApiVersionRequest call when it starts up is a good one. This idea is described in both KIP-97, and the KAFKA-3600 patches. I also think we ought to maintain per-node version information. It would be good to get that in so that we

[jira] [Commented] (KAFKA-4415) Reduce time to create and send MetadataUpdateRequest

[ https://issues.apache.org/jira/browse/KAFKA-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709345#comment-15709345 ] Dong Lin commented on KAFKA-4415: - [~ijuma] As of current Kafka implementation, Kafka does send

[GitHub] kafka pull request #1664: KAFKA-1911: Async delete topic

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/1664 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: [DISCUSS] 0.10.1.1 Plan

@Bernard Leach That sounds good, we can consider adding a kafka_2.12-0.10.1.1-beta.tgz into maven for Scala community to test it out. Guozhang On Tue, Nov 29, 2016 at 10:01 PM, Bernard Leach wrote: > Hi Guozhang, > > My suggestion was to not add

[jira] [Updated] (KAFKA-4469) Consumer throughput regression caused by inefficient list removal and copy

[ https://issues.apache.org/jira/browse/KAFKA-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson updated KAFKA-4469: --- Summary: Consumer throughput regression caused by inefficient list removal and copy (was:

[jira] [Updated] (KAFKA-4415) Reduce time to create and send MetadataUpdateRequest

[ https://issues.apache.org/jira/browse/KAFKA-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dong Lin updated KAFKA-4415: Description: As of current implementation, when controller receives ControlledShutdownRequest, it will 1)

Re: [DISCUSS] KIP-97: Improved Kafka Client RPC Compatibility Policy

Hello Ismael, It is good to know that you are willing to review KAFKA-3600 again. As before, we at Cloudera are highly in support of client compatibility, and KAFKA-3600 has always been a building block for that. Now that client compatibility is at forefront again, thanks to Colin, I will be

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

Eno, > So in general, we have the problem of failures during writes to the metadata topic itself. The KIP suggests to use marker messaged for this case. The marker is either written (indicating success) or not. If not, after failure/rebalance the (new) group leader will collect HW again. As long

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

In the KIP, two types of intermediate topics are described, 1) ones that connect two sub-topologies, and 2) others that are internal repartitioning topics (e.g., for joins). I wasn't envisioning stopping the consumption of (2) at the HWM. The HWM can be used for the source topics only (so I

[jira] [Commented] (KAFKA-4469) Consumer throughput regression caused by inefficient list removal and copy

[ https://issues.apache.org/jira/browse/KAFKA-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709847#comment-15709847 ] ASF GitHub Bot commented on KAFKA-4469: --- Github user asfgit closed the pull request at:

[GitHub] kafka pull request #2190: KAFKA-4469: Fix consumer performance regression fr...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/2190 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: [VOTE] KIP-96 - Add per partition metrics for in-sync and replica count

+1 (binding) On Wed, Nov 30, 2016 at 1:43 PM Eno Thereska wrote: > +1 (non binding) > > > On 30 Nov 2016, at 21:34, Xavier Léauté wrote: > > > > Based on the feedback KIP-96 seems pretty uncontroversial, so I'd like to > > initiate a vote on it. > >

[GitHub] kafka pull request #2189: KAFKA-4271: Fix the server start script for Window...

Github user asfgit closed the pull request at: https://github.com/apache/kafka/pull/2189 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

With the marker we have substituted a failure problem for a liveness problem in that under repeated failure the other instances will not do any useful work. As mentioned in the other email, I don't know if we need to worry about that corner case just yet. Eno > On 30 Nov 2016, at 20:06,

Re: [VOTE] KIP-96 - Add per partition metrics for in-sync and replica count

+1 (non binding) > On 30 Nov 2016, at 21:34, Xavier Léauté wrote: > > Based on the feedback KIP-96 seems pretty uncontroversial, so I'd like to > initiate a vote on it. > >

[jira] [Updated] (KAFKA-4451) Recovering empty replica yields negative offsets in index of compact partitions

[ https://issues.apache.org/jira/browse/KAFKA-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gwen Shapira updated KAFKA-4451: Labels: reliability (was: ) > Recovering empty replica yields negative offsets in index of compact

Re: [VOTE] KIP-96 - Add per partition metrics for in-sync and replica count

+1. Thanks for the KIP! On Wed, Nov 30, 2016 at 1:47 PM, Gwen Shapira wrote: > +1 (binding) > > On Wed, Nov 30, 2016 at 1:34 PM, Xavier Léauté > wrote: > > Based on the feedback KIP-96 seems pretty uncontroversial, so I'd like to > > initiate a vote on

[jira] [Commented] (KAFKA-3994) Deadlock between consumer heartbeat expiration and offset commit.

[ https://issues.apache.org/jira/browse/KAFKA-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709975#comment-15709975 ] ASF GitHub Bot commented on KAFKA-3994: --- Github user hachikuji closed the pull request at:

[GitHub] kafka pull request #1738: KAFKA-3994: Fix deadlock in Watchers by calling tr...

Github user hachikuji closed the pull request at: https://github.com/apache/kafka/pull/1738 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

[VOTE] KIP-96 - Add per partition metrics for in-sync and replica count

Based on the feedback KIP-96 seems pretty uncontroversial, so I'd like to initiate a vote on it. https://cwiki.apache.org/confluence/display/KAFKA/KIP-96+-+Add+per+partition+metrics+for+in-sync+and+assigned+replica+count Xavier

[jira] [Resolved] (KAFKA-4469) Consumer throughput regression caused by inefficient list removal and copy

[ https://issues.apache.org/jira/browse/KAFKA-4469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-4469. Resolution: Fixed Issue resolved by pull request 2190

Re: [DISCUSS] KIP-96 - Add per partition metrics for in-sync and assigned replica count

FYI, Based on internal feedback I renamed AssignedReplicasCount to simply be called ReplicasCount. On Tue, Nov 29, 2016 at 7:56 PM Neha Narkhede wrote: > This seems useful, +1 > > On Tue, Nov 29, 2016 at 5:39 AM Ismael Juma wrote: > > > Hi Xavier, > > > >

Re: [VOTE] KIP-96 - Add per partition metrics for in-sync and replica count

+1 (binding) On Wed, Nov 30, 2016 at 1:34 PM, Xavier Léauté wrote: > Based on the feedback KIP-96 seems pretty uncontroversial, so I'd like to > initiate a vote on it. > >

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

Both types of intermediate topics are handled the exact same way and both types do connect different subtopologies (even if the user might not be aware that there are multiple subtopologies in case of internal data repartitioning). So there is no distinction between user intermediate topics (via

[jira] [Commented] (KAFKA-3994) Deadlock between consumer heartbeat expiration and offset commit.

[ https://issues.apache.org/jira/browse/KAFKA-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709959#comment-15709959 ] ASF GitHub Bot commented on KAFKA-3994: --- GitHub user hachikuji opened a pull request:

[GitHub] kafka pull request #2195: KAFKA-3994: Fix deadlock in Watchers by calling tr...

GitHub user hachikuji opened a pull request: https://github.com/apache/kafka/pull/2195 KAFKA-3994: Fix deadlock in Watchers by calling tryComplete without any locks You can merge this pull request into a Git repository by running: $ git pull

Build failed in Jenkins: kafka-trunk-jdk8 #1067

See Changes: [jjkoshy] KAFKA-1911; Async delete topic - contributed by Mayuresh Gharat -- [...truncated 12186 lines...] org.apache.kafka.common.record.RecordTest > testChecksum[190] PASSED

[jira] [Updated] (KAFKA-4271) The console consumer fails on Windows with new consumer is used

[ https://issues.apache.org/jira/browse/KAFKA-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guozhang Wang updated KAFKA-4271: - Resolution: Fixed Fix Version/s: 0.10.1.1 0.10.2.0 Status:

[jira] [Commented] (KAFKA-4271) The console consumer fails on Windows with new consumer is used

[ https://issues.apache.org/jira/browse/KAFKA-4271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709663#comment-15709663 ] ASF GitHub Bot commented on KAFKA-4271: --- Github user asfgit closed the pull request at:

[DISCUSS] KIP-98: Exactly Once Delivery and Transactional Messaging

Hi all, I have just created KIP-98 to enhance Kafka with exactly once delivery semantics: *https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging

[jira] [Commented] (KAFKA-4405) Kafka consumer improperly send prefetch request

[ https://issues.apache.org/jira/browse/KAFKA-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708052#comment-15708052 ] Eno Thereska commented on KAFKA-4405: - I opened a PR since the performance difference is still

[GitHub] kafka pull request #2192: MyKafka

GitHub user geeag opened a pull request: https://github.com/apache/kafka/pull/2192 MyKafka We suspect that the test suite hangs we have been seeing are due to PermGen exhaustion. It is a common reason for hard JVM lock-ups. Author: Ismael Juma

[jira] [Comment Edited] (KAFKA-4007) Improve fetch pipelining for low values of max.poll.records

[ https://issues.apache.org/jira/browse/KAFKA-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708070#comment-15708070 ] Ismael Juma edited comment on KAFKA-4007 at 11/30/16 9:43 AM: -- I think it's

[jira] [Commented] (KAFKA-4007) Improve fetch pipelining for low values of max.poll.records

[ https://issues.apache.org/jira/browse/KAFKA-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708070#comment-15708070 ] Ismael Juma commented on KAFKA-4007: I think it's worth clarifying that a new fetch request is sent if

[jira] [Commented] (KAFKA-4405) Kafka consumer improperly send prefetch request

[ https://issues.apache.org/jira/browse/KAFKA-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708050#comment-15708050 ] ASF GitHub Bot commented on KAFKA-4405: --- GitHub user enothereska opened a pull request:

[GitHub] kafka pull request #2193: KAFKA-4405: Check max.poll.records before prefetch...

GitHub user enothereska opened a pull request: https://github.com/apache/kafka/pull/2193 KAFKA-4405: Check max.poll.records before prefetching You can merge this pull request into a Git repository by running: $ git pull https://github.com/enothereska/kafka KAFKA-4405-prefetch

[jira] [Commented] (KAFKA-3715) Higher granularity streams metrics

[ https://issues.apache.org/jira/browse/KAFKA-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708137#comment-15708137 ] Eno Thereska commented on KAFKA-3715: - Just sent you email, might make more sense to work together off

Re: [DISCUSS] KIP-94: Session Windows

Thanks Matthias. 1) Yes good suggestion will update. 2) As it is consistent with Aggregator and a developer may want to use the key. So why not? 3) Thanks. I'll update the KIP Cheers, Damian On Tue, 29 Nov 2016 at 23:47 Matthias J. Sax wrote: > Very nice KIP! > > >

Re: [VOTE] KIP-93: Improve invalid timestamp handling in Kafka Streams

+1 On Wed, 30 Nov 2016 at 05:58 Ewen Cheslack-Postava wrote: > +1 (binding). > > Also, see my notes in discussion thread around future compatibility > discussions for breaking plugin interface changes like this. > > -Ewen > > On Tue, Nov 29, 2016 at 3:54 PM, Guozhang Wang

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

Hi Matthias, I like the first part of the KIP. However, the second part with the failure modes and metadata topic is quite complex and I'm worried it doesn't solve the problems you mention under failure. For example, the application can fail before writing to the metadata topic. In that case,

Re: [DISCUSS] KIP-95: Incremental Batch Processing for Kafka Streams

I think the KIP looks good. I also think we need the metadata topic in-order to provide sane guarantees on what data will be processed. As Matthias has outlined in the KIP we need to know when to stop consuming from intermediate topics, i.e, topics that are part of the same application but are

[jira] [Commented] (KAFKA-4443) Controller should send UpdateMetadataRequest prior to LeaderAndIsrRequest during failover

[ https://issues.apache.org/jira/browse/KAFKA-4443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708268#comment-15708268 ] ASF GitHub Bot commented on KAFKA-4443: --- GitHub user ijuma opened a pull request:

[GitHub] kafka pull request #2194: KAFKA-4443: Minor comment clean-up

GitHub user ijuma opened a pull request: https://github.com/apache/kafka/pull/2194 KAFKA-4443: Minor comment clean-up Removed stale comment left behind, minor fixes (UpdateMetadataRequest instead of MetadataUpdateRequest) and remove redundant comments. You can merge this pull

[jira] [Commented] (KAFKA-1194) The kafka broker cannot delete the old log files after the configured time

[ https://issues.apache.org/jira/browse/KAFKA-1194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15708281#comment-15708281 ] Harald Kirsch commented on KAFKA-1194: -- The report of success was slightly exaggerted :-( After

Re: [VOTE] KIP-87 - Add Compaction Tombstone Flag

Thanks Becket, The intent was it would be immutable. This didn’t get picked up on during the discussion phase but a very good point about setter methods and make it constructor parameter instead. Have updated KIP, thanks for the feedback. On 29/11/2016, 18:30, "Becket Qin"

  1   2   >