[jira] [Created] (KAFKA-6482) when produce send a invalidity timestamps, broker will be not delete retention files

2018-01-25 Thread HongLiang (JIRA)
HongLiang created KAFKA-6482:


 Summary: when produce send a invalidity timestamps, broker will be 
not delete retention files
 Key: KAFKA-6482
 URL: https://issues.apache.org/jira/browse/KAFKA-6482
 Project: Kafka
  Issue Type: Bug
  Components: log
Affects Versions: 1.0.0
Reporter: HongLiang


when produce send a invalidity timestamps, broker will be not delete retention 
files.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (KAFKA-6484) 'ConsumerGroupCommand' performance optimization for old consumer describe group

2018-01-25 Thread HongLiang (JIRA)
HongLiang created KAFKA-6484:


 Summary: 'ConsumerGroupCommand' performance optimization for old 
consumer describe group
 Key: KAFKA-6484
 URL: https://issues.apache.org/jira/browse/KAFKA-6484
 Project: Kafka
  Issue Type: Improvement
  Components: admin
Affects Versions: 1.0.0
Reporter: HongLiang
 Attachments: ConsumerGroupCommand.diff

ConsumerGroupCommand describegroup performance optimization.
performance improvement 3 times compare trunk(1.0+). and performance 
improvement 10 times compare 0.10.2.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (KAFKA-6485) 'ConsumerGroupCommand' performance optimization for old consumer describe group

2018-01-25 Thread HongLiang (JIRA)
HongLiang created KAFKA-6485:


 Summary: 'ConsumerGroupCommand' performance optimization for old 
consumer describe group
 Key: KAFKA-6485
 URL: https://issues.apache.org/jira/browse/KAFKA-6485
 Project: Kafka
  Issue Type: Improvement
  Components: admin
Affects Versions: 1.0.0
Reporter: HongLiang
 Attachments: ConsumerGroupCommand.diff

ConsumerGroupCommand describegroup performance optimization.
performance improvement 3 times compare trunk(1.0+). and performance 
improvement 10 times compare 0.10.2.1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (KAFKA-6306) Auto-commit of offsets fail, and not recover forever...

2017-12-04 Thread HongLiang (JIRA)
HongLiang created KAFKA-6306:


 Summary: Auto-commit of offsets fail, and not recover forever...
 Key: KAFKA-6306
 URL: https://issues.apache.org/jira/browse/KAFKA-6306
 Project: Kafka
  Issue Type: Bug
  Components: clients, consumer
Affects Versions: 1.0.0, 0.10.2.1
Reporter: HongLiang
 Attachments: _883ddf50-beb7-4e87-9630-168acaa9b046.png, 
e6cf53be-e128-47dc-a45a-79439a9e55ff.png

Auto-commit of offsets fail, and not recover forever. at 
sendOffsetCommitRequest, while "generation equal NULL", ConsumerCoordinator 
request will fail always. it maybe a bug. error log below:
has more and more warn log 
"2017-12-01 22:08:39.112 WARN pool-390-thread-1#1 
(ConsumerCoordinator.java:626) - Auto-commit of offsets 
{drawing_gift_sent-1=OffsetAndMetadata{offset=32150359, metadata=''}} failed 
for group gift_rich_audience_write: Commit cannot be completed since the group 
has already rebalanced and assigned the partitions to another member. This 
means that the time between subsequent calls to poll() was longer than the 
configured max.poll.interval.ms, which typically implies that the poll loop is 
spending too much time message processing. You can address this either by 
increasing the session timeout or by reducing the maximum size of batches 
returned in poll() with max.poll.records."
!e6cf53be-e128-47dc-a45a-79439a9e55ff.png|thumbnail!
!_883ddf50-beb7-4e87-9630-168acaa9b046.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (KAFKA-6326) when broker is unavailable(such as broker's machine is down), controller will wait 30 sec timeout

2017-12-07 Thread HongLiang (JIRA)
HongLiang created KAFKA-6326:


 Summary: when broker is unavailable(such as broker's machine is 
down), controller will wait 30 sec timeout 
 Key: KAFKA-6326
 URL: https://issues.apache.org/jira/browse/KAFKA-6326
 Project: Kafka
  Issue Type: Bug
  Components: controller
Affects Versions: 1.0.0
Reporter: HongLiang
 Attachments: _f7d1d2b4-39ae-4e02-8519-99bcba849668.png, 
fast-recver-shutdownbroker.diff

when broker is unavailable(such as broker's machine is down), controller will 
wait 30 sec timeout by dedault. it seems to be that the timeout waiting is not 
necessary. It will be increase the MTTR of dead broker .



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)