Review Request 26340: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summery/description when updating the RB with 
kafka-patch-review


Diffs
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Assignee: Manikumar Reddy
  Status: Patch Available  (was: Open)

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159071#comment-14159071
 ] 

Manikumar Reddy commented on KAFKA-1277:


Created reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
> Attachments: KAFKA-1277.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
> Attachments: KAFKA-1277.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: KAFKA-1277; Keep the summary/description when updating the RB with kafka-patch-review

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:12 a.m.)


Review request for kafka.


Summary (updated)
-

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description (updated)
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159074#comment-14159074
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_16:39:56.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: KAFKA-1277; Keep the summary/description when updating the RB with kafka-patch-review

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:23 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159078#comment-14159078
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_16:51:20.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: KAFKA-1277; Keep the summary/description when updating the RB with kafka-patch-review

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:29 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_16:57:30.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159079#comment-14159079
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: Testing this patch

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:32 a.m.)


Review request for kafka.


Summary (updated)
-

Testing this patch


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_17:00:37.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159081#comment-14159081
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: Testing this patch

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:33 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description (updated)
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_17:01:43.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159082#comment-14159082
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: Testing this patch

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:35 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_17:03:08.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159083#comment-14159083
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-04_17:09:02.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch, KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159084#comment-14159084
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26340/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch, KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26340: Testing this patch

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26340/
---

(Updated Oct. 4, 2014, 11:41 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description (updated)
---

Keep the summary/description when updating the RB with kafka-patch-review


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26340/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159088#comment-14159088
 ] 

Manikumar Reddy commented on KAFKA-1277:


In this patch, I disabled the auto-setting of Summary and Description fields of 
RB request. Unless explicitly set, these fields will not get updated for 
existing RBs..

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch, KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 26341: Patch for KAFKA-1057

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26341/
---

Review request for kafka.


Bugs: KAFKA-1057
https://issues.apache.org/jira/browse/KAFKA-1057


Repository: kafka


Description
---

KAFKA-1057;Trim whitespaces from user specified configs


Diffs
-

  core/src/main/scala/kafka/utils/VerifiableProperties.scala 
2f95d540c53296f3a9b1230a8a03df4790f2e5e6 

Diff: https://reviews.apache.org/r/26341/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1057) Trim whitespaces from user specified configs

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1057:
---
Attachment: KAFKA-1057.patch

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1057.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1057) Trim whitespaces from user specified configs

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1057:
---
Assignee: Manikumar Reddy
  Status: Patch Available  (was: Open)

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>Assignee: Manikumar Reddy
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1057.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1057) Trim whitespaces from user specified configs

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159094#comment-14159094
 ] 

Manikumar Reddy commented on KAFKA-1057:


Created reviewboard https://reviews.apache.org/r/26341/diff/
 against branch origin/trunk

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1057.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26341: Patch for KAFKA-1057

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26341/
---

(Updated Oct. 4, 2014, 2:48 p.m.)


Review request for kafka.


Bugs: KAFKA-1057
https://issues.apache.org/jira/browse/KAFKA-1057


Repository: kafka


Description
---

KAFKA-1057;Trim whitespaces from user specified configs


Diffs (updated)
-

  core/src/main/scala/kafka/utils/VerifiableProperties.scala 
2f95d540c53296f3a9b1230a8a03df4790f2e5e6 

Diff: https://reviews.apache.org/r/26341/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1057) Trim whitespaces from user specified configs

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1057:
---
Attachment: KAFKA-1057_2014-10-04_20:15:32.patch

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>Assignee: Manikumar Reddy
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1057.patch, KAFKA-1057_2014-10-04_20:15:32.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1057) Trim whitespaces from user specified configs

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159149#comment-14159149
 ] 

Manikumar Reddy commented on KAFKA-1057:


Updated reviewboard https://reviews.apache.org/r/26341/diff/
 against branch origin/trunk

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>Assignee: Manikumar Reddy
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1057.patch, KAFKA-1057_2014-10-04_20:15:32.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Humble request for wiki comment privileges

[Joe Stein]

What is your confluence username?
On Oct 2, 2014 7:45 PM, "Jarek Jarcec Cecho"  wrote:

> Might I humbly request wiki comment privileges? I would like to comment
> the Security proposal wiki page.
>
> Jarcec

Re: Humble request for wiki comment privileges

[Jarek Jarcec Cecho]

Simply “jarcec” :)

Jarcec

On Oct 4, 2014, at 12:43 PM, Joe Stein  wrote:

> What is your confluence username?
> On Oct 2, 2014 7:45 PM, "Jarek Jarcec Cecho"  wrote:
> 
>> Might I humbly request wiki comment privileges? I would like to comment
>> the Security proposal wiki page.
>> 
>> Jarcec

Re: Humble request for wiki comment privileges

[Joe Stein]

done

/***
 Joe Stein
 Founder, Principal Consultant
 Big Data Open Source Security LLC
 http://www.stealth.ly
 Twitter: @allthingshadoop 
/

On Sat, Oct 4, 2014 at 3:45 PM, Jarek Jarcec Cecho 
wrote:

> Simply “jarcec” :)
>
> Jarcec
>
> On Oct 4, 2014, at 12:43 PM, Joe Stein  wrote:
>
> > What is your confluence username?
> > On Oct 2, 2014 7:45 PM, "Jarek Jarcec Cecho"  wrote:
> >
> >> Might I humbly request wiki comment privileges? I would like to comment
> >> the Security proposal wiki page.
> >>
> >> Jarcec
>
>

Re: Humble request for wiki comment privileges

[Jarek Jarcec Cecho]

Thank you Joe!

Jarcec

On Oct 4, 2014, at 12:46 PM, Joe Stein  wrote:

> done
> 
> /***
> Joe Stein
> Founder, Principal Consultant
> Big Data Open Source Security LLC
> http://www.stealth.ly
> Twitter: @allthingshadoop 
> /
> 
> On Sat, Oct 4, 2014 at 3:45 PM, Jarek Jarcec Cecho 
> wrote:
> 
>> Simply “jarcec” :)
>> 
>> Jarcec
>> 
>> On Oct 4, 2014, at 12:43 PM, Joe Stein  wrote:
>> 
>>> What is your confluence username?
>>> On Oct 2, 2014 7:45 PM, "Jarek Jarcec Cecho"  wrote:
>>> 
 Might I humbly request wiki comment privileges? I would like to comment
 the Security proposal wiki page.
 
 Jarcec
>> 
>> 

[jira] [Assigned] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sriharsha Chintalapani reassigned KAFKA-1670:
-

Assignee: Sriharsha Chintalapani

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1624) building on JDK 8 fails

[Ismael Juma (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159286#comment-14159286
 ] 

Ismael Juma commented on KAFKA-1624:


Note that Scala 2.10.4 also includes a number of fixes for Java 8 support.

> building on JDK 8 fails
> ---
>
> Key: KAFKA-1624
> URL: https://issues.apache.org/jira/browse/KAFKA-1624
> Project: Kafka
>  Issue Type: Bug
>Reporter: Joe Stein
>  Labels: newbie
> Fix For: 0.9.0
>
>
> {code}
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; 
> support was removed in 8.0
> error: error while loading CharSequence, class file 
> '/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar(java/lang/CharSequence.class)' is 
> broken
> (class java.lang.RuntimeException/bad constant pool tag 18 at byte 10)
> error: error while loading Comparator, class file 
> '/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar(java/util/Comparator.class)' is 
> broken
> (class java.lang.RuntimeException/bad constant pool tag 18 at byte 20)
> error: error while loading AnnotatedElement, class file 
> '/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar(java/lang/reflect/AnnotatedElement.class)'
>  is broken
> (class java.lang.RuntimeException/bad constant pool tag 18 at byte 76)
> error: error while loading Arrays, class file 
> '/usr/lib/jvm/java-8-oracle/jre/lib/rt.jar(java/util/Arrays.class)' is broken
> (class java.lang.RuntimeException/bad constant pool tag 18 at byte 765)
> /tmp/sbt_53783b12/xsbt/ExtractAPI.scala:395: error: java.util.Comparator does 
> not take type parameters
>   private[this] val sortClasses = new Comparator[Symbol] {
> ^
> 5 errors found
> :core:compileScala FAILED
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':core:compileScala'.
> > org.gradle.messaging.remote.internal.PlaceholderException (no error message)
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug option to get more log output.
> BUILD FAILED
> Total time: 1 mins 48.298 secs
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 26346: Patch for KAFKA-1670

[Sriharsha Chintalapani]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26346/
---

Review request for kafka.


Bugs: KAFKA-1670
https://issues.apache.org/jira/browse/KAFKA-1670


Repository: kafka


Description
---

KAFKA-1670. Corrupt log files for segment.bytes values close to Int.MaxInt.


Diffs
-

  core/src/main/scala/kafka/log/Log.scala 
0ddf97bd30311b6039e19abade41d2fbbad2f59b 

Diff: https://reviews.apache.org/r/26346/diff/


Testing
---


Thanks,

Sriharsha Chintalapani

[jira] [Commented] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159309#comment-14159309
 ] 

Sriharsha Chintalapani commented on KAFKA-1670:
---

Created reviewboard https://reviews.apache.org/r/26346/diff/
 against branch origin/trunk

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sriharsha Chintalapani updated KAFKA-1670:
--
Status: Patch Available  (was: Open)

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sriharsha Chintalapani updated KAFKA-1670:
--
Attachment: KAFKA-1670.patch

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159312#comment-14159312
 ] 

Sriharsha Chintalapani commented on KAFKA-1670:
---

This is caused by maybeRoll  not checking for any boundary conditions for Int 
overflow. 

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sriharsha Chintalapani updated KAFKA-1670:
--
Fix Version/s: 0.8.2

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Neha Narkhede (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159338#comment-14159338
 ] 

Neha Narkhede commented on KAFKA-1277:
--

[~omkreddy] I tried testing the patch, but it failed with the following error
{noformat}
nnarkhed-mn1:kafka-git-idea nnarkhed$ python kafka-patch-review.py -j 
KAFKA-1277 -b trunk
Configuring reviewboard url to https://reviews.apache.org
Updating your remote branches to pull the latest changes
Usage: rbt post [options] [changenum]

Uploads diffs to create and update review requests.

rbt: error: --guess-fields option does not take a value
ERROR: reviewboard update failed. Exiting.
{noformat}

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch, KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede updated KAFKA-1277:
-
Reviewer: Neha Narkhede

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277_2014-10-04_16:39:56.patch, 
> KAFKA-1277_2014-10-04_16:51:20.patch, KAFKA-1277_2014-10-04_16:57:30.patch, 
> KAFKA-1277_2014-10-04_17:00:37.patch, KAFKA-1277_2014-10-04_17:01:43.patch, 
> KAFKA-1277_2014-10-04_17:03:08.patch, KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede updated KAFKA-1670:
-
Reviewer: Jun Rao

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26346: Patch for KAFKA-1670

[Neha Narkhede]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26346/#review55455
---


Can you try to add a unit test for this?


core/src/main/scala/kafka/log/Log.scala


Could you please change the API docs to reflect this change?


- Neha Narkhede


On Oct. 4, 2014, 10:28 p.m., Sriharsha Chintalapani wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26346/
> ---
> 
> (Updated Oct. 4, 2014, 10:28 p.m.)
> 
> 
> Review request for kafka.
> 
> 
> Bugs: KAFKA-1670
> https://issues.apache.org/jira/browse/KAFKA-1670
> 
> 
> Repository: kafka
> 
> 
> Description
> ---
> 
> KAFKA-1670. Corrupt log files for segment.bytes values close to Int.MaxInt.
> 
> 
> Diffs
> -
> 
>   core/src/main/scala/kafka/log/Log.scala 
> 0ddf97bd30311b6039e19abade41d2fbbad2f59b 
> 
> Diff: https://reviews.apache.org/r/26346/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sriharsha Chintalapani
> 
>

Re: Review Request 26291: Patch for KAFKA-1648

[Neha Narkhede]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26291/#review55456
---


Can you try to add a unit test for this?


core/src/main/scala/kafka/consumer/ZookeeperConsumerConnector.scala


Can this empty comment be removed?


- Neha Narkhede


On Oct. 2, 2014, 10:43 p.m., Mayuresh Gharat wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26291/
> ---
> 
> (Updated Oct. 2, 2014, 10:43 p.m.)
> 
> 
> Review request for kafka.
> 
> 
> Bugs: KAFKA-1648
> https://issues.apache.org/jira/browse/KAFKA-1648
> 
> 
> Repository: kafka
> 
> 
> Description
> ---
> 
> Added a check to see if there are not topics
> 
> 
> Diffs
> -
> 
>   core/src/main/scala/kafka/consumer/PartitionAssignor.scala 
> 8ea7368dc394a497164ea093ff8e9f2e6a94b1de 
>   core/src/main/scala/kafka/consumer/ZookeeperConsumerConnector.scala 
> fbc680fde21b02f11285a4f4b442987356abd17b 
> 
> Diff: https://reviews.apache.org/r/26291/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Mayuresh Gharat
> 
>

[jira] [Updated] (KAFKA-1057) Trim whitespaces from user specified configs

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede updated KAFKA-1057:
-
   Resolution: Fixed
Fix Version/s: (was: 0.9.0)
   0.8.3
   Status: Resolved  (was: Patch Available)

Thanks for the patch, pushed to trunk

> Trim whitespaces from user specified configs
> 
>
> Key: KAFKA-1057
> URL: https://issues.apache.org/jira/browse/KAFKA-1057
> Project: Kafka
>  Issue Type: Bug
>  Components: config
>Reporter: Neha Narkhede
>Assignee: Manikumar Reddy
>  Labels: newbie
> Fix For: 0.8.3
>
> Attachments: KAFKA-1057.patch, KAFKA-1057_2014-10-04_20:15:32.patch
>
>
> Whitespaces in configs are a common problem that leads to config errors. It 
> will be nice if Kafka can trim the whitespaces from configs automatically



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: Kafka-trunk #287

[Apache Jenkins Server]

See 

Changes:

[neha.narkhede] KAFKA-1057 Trim whitespaces from user specified configs; 
reviewed by Neha Narkhede

--
[...truncated 397 lines...]

kafka.admin.TopicCommandTest > testConfigPreservationAcrossPartitionAlteration 
PASSED

kafka.admin.AdminTest > testReplicaAssignment PASSED

kafka.admin.AdminTest > testManualReplicaAssignment PASSED

kafka.admin.AdminTest > testTopicCreationInZK PASSED

kafka.admin.AdminTest > testPartitionReassignmentWithLeaderInNewReplicas PASSED

kafka.admin.AdminTest > testPartitionReassignmentWithLeaderNotInNewReplicas 
PASSED

kafka.admin.AdminTest > testPartitionReassignmentNonOverlappingReplicas PASSED

kafka.admin.AdminTest > testReassigningNonExistingPartition PASSED

kafka.admin.AdminTest > testResumePartitionReassignmentThatWasCompleted PASSED

kafka.admin.AdminTest > testPreferredReplicaJsonData PASSED

kafka.admin.AdminTest > testBasicPreferredReplicaElection PASSED

kafka.admin.AdminTest > testShutdownBroker PASSED

kafka.admin.AdminTest > testTopicConfigChange PASSED

kafka.admin.AddPartitionsTest > testTopicDoesNotExist PASSED

kafka.admin.AddPartitionsTest > testWrongReplicaCount PASSED

kafka.admin.AddPartitionsTest > testIncrementPartitions PASSED

kafka.admin.AddPartitionsTest > testManualAssignmentOfReplicas PASSED

kafka.admin.AddPartitionsTest > testReplicaPlacement PASSED

kafka.admin.DeleteTopicTest > testDeleteTopicWithAllAliveReplicas PASSED

kafka.admin.DeleteTopicTest > testResumeDeleteTopicWithRecoveredFollower PASSED

kafka.admin.DeleteTopicTest > testResumeDeleteTopicOnControllerFailover PASSED

kafka.admin.DeleteTopicTest > testPartitionReassignmentDuringDeleteTopic PASSED

kafka.admin.DeleteTopicTest > testDeleteTopicDuringAddPartition FAILED
junit.framework.AssertionFailedError: Admin path /admin/delete_topic/test 
path not deleted even after a replica is restarted
at junit.framework.Assert.fail(Assert.java:47)
at kafka.utils.TestUtils$.waitUntilTrue(TestUtils.scala:592)
at 
kafka.admin.DeleteTopicTest.verifyTopicDeletion(DeleteTopicTest.scala:246)
at 
kafka.admin.DeleteTopicTest.testDeleteTopicDuringAddPartition(DeleteTopicTest.scala:160)

kafka.admin.DeleteTopicTest > testAddPartitionDuringDeleteTopic PASSED

kafka.admin.DeleteTopicTest > testRecreateTopicAfterDeletion PASSED

kafka.admin.DeleteTopicTest > testDeleteNonExistingTopic PASSED

kafka.api.ProducerFailureHandlingTest > testInvalidPartition PASSED

kafka.api.ProducerFailureHandlingTest > testTooLargeRecordWithAckZero PASSED

kafka.api.ProducerFailureHandlingTest > testTooLargeRecordWithAckOne PASSED

kafka.api.ProducerFailureHandlingTest > testNonExistentTopic PASSED

kafka.api.ProducerFailureHandlingTest > testWrongBrokerList PASSED

kafka.api.ProducerFailureHandlingTest > testNoResponse PASSED

kafka.api.ProducerFailureHandlingTest > testSendAfterClosed PASSED

kafka.api.ProducerFailureHandlingTest > testBrokerFailure PASSED

kafka.api.ProducerFailureHandlingTest > testCannotSendToInternalTopic PASSED

kafka.api.RequestResponseSerializationTest > 
testSerializationAndDeserialization PASSED

kafka.api.ApiUtilsTest > testShortStringNonASCII PASSED

kafka.api.ApiUtilsTest > testShortStringASCII PASSED

kafka.api.test.ProducerSendTest > testSendOffset PASSED

kafka.api.test.ProducerSendTest > testClose PASSED

kafka.api.test.ProducerSendTest > testSendToPartition PASSED

kafka.api.test.ProducerSendTest > testAutoCreateTopic PASSED

kafka.api.test.ProducerCompressionTest > testCompression[0] PASSED

kafka.api.test.ProducerCompressionTest > testCompression[1] PASSED

kafka.javaapi.consumer.ZookeeperConsumerConnectorTest > testBasic PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testWrittenEqualsRead PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testIteratorIsConsistent PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testSizeInBytes PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > 
testIteratorIsConsistentWithCompression PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testSizeInBytesWithCompression 
PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testEquals PASSED

kafka.javaapi.message.ByteBufferMessageSetTest > testEqualsWithCompression 
PASSED

kafka.integration.UncleanLeaderElectionTest > testUncleanLeaderElectionEnabled 
PASSED

kafka.integration.UncleanLeaderElectionTest > testUncleanLeaderElectionDisabled 
PASSED

kafka.integration.UncleanLeaderElectionTest > 
testUncleanLeaderElectionEnabledByTopicOverride PASSED

kafka.integration.UncleanLeaderElectionTest > 
testCleanLeaderElectionDisabledByTopicOverride PASSED

kafka.integration.UncleanLeaderElectionTest > 
testUncleanLeaderElectionInvalidTopicOverride PASSED

kafka.integration.FetcherTest > testFetcher PASSED

kafka.integration.RollingBounceTest > testRollingBounce PASSED

kafka.integration.PrimitiveApiTest > testFetchRequestCanProperlyS

Re: Review Request 26291: Patch for KAFKA-1648

[Mayuresh Gharat]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26291/
---

(Updated Oct. 5, 2014, 12:40 a.m.)


Review request for kafka.


Bugs: KAFKA-1648
https://issues.apache.org/jira/browse/KAFKA-1648


Repository: kafka


Description (updated)
---

Removed the unnecessary comment


Diffs (updated)
-

  core/src/main/scala/kafka/consumer/PartitionAssignor.scala 
8ea7368dc394a497164ea093ff8e9f2e6a94b1de 
  core/src/main/scala/kafka/consumer/ZookeeperConsumerConnector.scala 
fbc680fde21b02f11285a4f4b442987356abd17b 

Diff: https://reviews.apache.org/r/26291/diff/


Testing
---


Thanks,

Mayuresh Gharat

[jira] [Updated] (KAFKA-1648) Round robin consumer balance throws an NPE when there are no topics

[Mayuresh Gharat (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mayuresh Gharat updated KAFKA-1648:
---
Attachment: KAFKA-1648_2014-10-04_17:40:47.patch

> Round robin consumer balance throws an NPE when there are no topics
> ---
>
> Key: KAFKA-1648
> URL: https://issues.apache.org/jira/browse/KAFKA-1648
> Project: Kafka
>  Issue Type: Bug
>  Components: consumer
>Reporter: Todd Palino
>Assignee: Mayuresh Gharat
>  Labels: newbie
> Attachments: KAFKA-1648.patch, KAFKA-1648_2014-10-04_17:40:47.patch
>
>
> If you use the roundrobin rebalance method with a wildcard consumer, and 
> there are no topics in the cluster, rebalance throws a NullPointerException 
> in the consumer and fails. It retries the rebalance, but will continue to 
> throw the NPE.
> 2014/09/23 17:51:16.147 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Cleared all relevant 
> queues for this fetcher
> 2014/09/23 17:51:16.147 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Cleared the data 
> chunks in all the consumer message iterators
> 2014/09/23 17:51:16.148 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Committing all 
> offsets after clearing the fetcher queues
> 2014/09/23 17:51:46.148 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], begin rebalancing 
> consumer kafka-audit_lva1-app0007.corp-1411494404908-4e620544 try #0
> 2014/09/23 17:51:46.148 ERROR [OffspringServletRuntime] [main] 
> [kafka-console-audit] [] Boot listener 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditBootListener failed
> kafka.common.ConsumerRebalanceFailedException: 
> kafka-audit_lva1-app0007.corp-1411494404908-4e620544 can't rebalance after 10 
> retries
>   at 
> kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener.syncedRebalance(ZookeeperConsumerConnector.scala:630)
>   at 
> kafka.consumer.ZookeeperConsumerConnector.kafka$consumer$ZookeeperConsumerConnector$$reinitializeConsumer(ZookeeperConsumerConnector.scala:897)
>   at 
> kafka.consumer.ZookeeperConsumerConnector$WildcardStreamsHandler.(ZookeeperConsumerConnector.scala:931)
>   at 
> kafka.consumer.ZookeeperConsumerConnector.createMessageStreamsByFilter(ZookeeperConsumerConnector.scala:159)
>   at 
> kafka.javaapi.consumer.ZookeeperConsumerConnector.createMessageStreamsByFilter(ZookeeperConsumerConnector.scala:101)
>   at 
> com.linkedin.tracker.consumer.TrackingConsumerImpl.initWildcardIterators(TrackingConsumerImpl.java:88)
>   at 
> com.linkedin.tracker.consumer.TrackingConsumerImpl.getWildcardIterators(TrackingConsumerImpl.java:116)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAudit.createAuditThreads(KafkaConsoleAudit.java:59)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAudit.initializeAudit(KafkaConsoleAudit.java:50)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditFactory.createInstance(KafkaConsoleAuditFactory.java:125)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditFactory.createInstance(KafkaConsoleAuditFactory.java:20)
>   at 
> com.linkedin.util.factory.SimpleSingletonFactory.createInstance(SimpleSingletonFactory.java:20)
>   at 
> com.linkedin.util.factory.SimpleSingletonFactory.createInstance(SimpleSingletonFactory.java:14)
>   at com.linkedin.util.factory.Generator.doGetBean(Generator.java:337)
>   at com.linkedin.util.factory.Generator.getBean(Generator.java:270)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditBootListener.onBoot(KafkaConsoleAuditBootListener.java:16)
>   at 
> com.linkedin.offspring.servlet.OffspringServletRuntime.startGenerator(OffspringServletRuntime.java:147)
>   at 
> com.linkedin.offspring.servlet.OffspringServletRuntime.start(OffspringServletRuntime.java:73)
>   at 
> com.linkedin.offspring.servlet.OffspringServletContextListener.contextInitialized(OffspringServletContextListener.java:28)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:771)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:424)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:763)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:706)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:492)
>   at 
> org.eclipse.

[jira] [Commented] (KAFKA-1648) Round robin consumer balance throws an NPE when there are no topics

[Mayuresh Gharat (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159366#comment-14159366
 ] 

Mayuresh Gharat commented on KAFKA-1648:


Updated reviewboard https://reviews.apache.org/r/26291/diff/
 against branch origin/trunk

> Round robin consumer balance throws an NPE when there are no topics
> ---
>
> Key: KAFKA-1648
> URL: https://issues.apache.org/jira/browse/KAFKA-1648
> Project: Kafka
>  Issue Type: Bug
>  Components: consumer
>Reporter: Todd Palino
>Assignee: Mayuresh Gharat
>  Labels: newbie
> Attachments: KAFKA-1648.patch, KAFKA-1648_2014-10-04_17:40:47.patch
>
>
> If you use the roundrobin rebalance method with a wildcard consumer, and 
> there are no topics in the cluster, rebalance throws a NullPointerException 
> in the consumer and fails. It retries the rebalance, but will continue to 
> throw the NPE.
> 2014/09/23 17:51:16.147 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Cleared all relevant 
> queues for this fetcher
> 2014/09/23 17:51:16.147 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Cleared the data 
> chunks in all the consumer message iterators
> 2014/09/23 17:51:16.148 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], Committing all 
> offsets after clearing the fetcher queues
> 2014/09/23 17:51:46.148 [ZookeeperConsumerConnector] 
> [kafka-audit_lva1-app0007.corp-1411494404908-4e620544], begin rebalancing 
> consumer kafka-audit_lva1-app0007.corp-1411494404908-4e620544 try #0
> 2014/09/23 17:51:46.148 ERROR [OffspringServletRuntime] [main] 
> [kafka-console-audit] [] Boot listener 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditBootListener failed
> kafka.common.ConsumerRebalanceFailedException: 
> kafka-audit_lva1-app0007.corp-1411494404908-4e620544 can't rebalance after 10 
> retries
>   at 
> kafka.consumer.ZookeeperConsumerConnector$ZKRebalancerListener.syncedRebalance(ZookeeperConsumerConnector.scala:630)
>   at 
> kafka.consumer.ZookeeperConsumerConnector.kafka$consumer$ZookeeperConsumerConnector$$reinitializeConsumer(ZookeeperConsumerConnector.scala:897)
>   at 
> kafka.consumer.ZookeeperConsumerConnector$WildcardStreamsHandler.(ZookeeperConsumerConnector.scala:931)
>   at 
> kafka.consumer.ZookeeperConsumerConnector.createMessageStreamsByFilter(ZookeeperConsumerConnector.scala:159)
>   at 
> kafka.javaapi.consumer.ZookeeperConsumerConnector.createMessageStreamsByFilter(ZookeeperConsumerConnector.scala:101)
>   at 
> com.linkedin.tracker.consumer.TrackingConsumerImpl.initWildcardIterators(TrackingConsumerImpl.java:88)
>   at 
> com.linkedin.tracker.consumer.TrackingConsumerImpl.getWildcardIterators(TrackingConsumerImpl.java:116)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAudit.createAuditThreads(KafkaConsoleAudit.java:59)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAudit.initializeAudit(KafkaConsoleAudit.java:50)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditFactory.createInstance(KafkaConsoleAuditFactory.java:125)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditFactory.createInstance(KafkaConsoleAuditFactory.java:20)
>   at 
> com.linkedin.util.factory.SimpleSingletonFactory.createInstance(SimpleSingletonFactory.java:20)
>   at 
> com.linkedin.util.factory.SimpleSingletonFactory.createInstance(SimpleSingletonFactory.java:14)
>   at com.linkedin.util.factory.Generator.doGetBean(Generator.java:337)
>   at com.linkedin.util.factory.Generator.getBean(Generator.java:270)
>   at 
> com.linkedin.kafkaconsoleaudit.KafkaConsoleAuditBootListener.onBoot(KafkaConsoleAuditBootListener.java:16)
>   at 
> com.linkedin.offspring.servlet.OffspringServletRuntime.startGenerator(OffspringServletRuntime.java:147)
>   at 
> com.linkedin.offspring.servlet.OffspringServletRuntime.start(OffspringServletRuntime.java:73)
>   at 
> com.linkedin.offspring.servlet.OffspringServletContextListener.contextInitialized(OffspringServletContextListener.java:28)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:771)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:424)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:763)
>   at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249)
>   at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:706)
>   at 
> or

[jira] [Updated] (KAFKA-1663) Controller unable to shutdown after a soft failure

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede updated KAFKA-1663:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks for the patch! Pushed to trunk

> Controller unable to shutdown after a soft failure
> --
>
> Key: KAFKA-1663
> URL: https://issues.apache.org/jira/browse/KAFKA-1663
> Project: Kafka
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1663.patch
>
>
> As part of testing KAFKA-1558 I came across a case where inducing soft 
> failure in the current controller elects a new controller  but the old 
> controller doesn't shutdown properly.
> steps to reproduce
> 1) 5 broker cluster
> 2) high number of topics(I tested it with 1000 topics)
> 3) on the current controller do kill -SIGSTOP  pid( broker's process id)
> 4) wait for bit over zookeeper timeout (server.properties)
> 5) kill -SIGCONT pid
> 6) There will be a new controller elected. check old controller's
> log 
> [2014-09-30 15:59:53,398] INFO [SessionExpirationListener on 1], ZK expired; 
> shut down all controller components and try to re-elect 
> (kafka.controller.KafkaController$SessionExpirationListener)
> [2014-09-30 15:59:53,400] INFO [delete-topics-thread-1], Shutting down 
> (kafka.controller.TopicDeletionManager$DeleteTopicsThread)
> If it stops there and the broker  logs keeps printing 
> Cached zkVersion [0] not equal to that in zookeeper, skip updating ISR 
> (kafka.cluster.Partition)
> than the controller shutdown never completes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (KAFKA-1600) Controller failover not working correctly.

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede resolved KAFKA-1600.
--
Resolution: Fixed

Duplicate JIRA KAFKA-1600 is now resolved.

> Controller failover not working correctly.
> --
>
> Key: KAFKA-1600
> URL: https://issues.apache.org/jira/browse/KAFKA-1600
> Project: Kafka
>  Issue Type: Bug
>  Components: controller
>Affects Versions: 0.8.1
> Environment: Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 
> GNU/Linux
> java version "1.7.0_03"
>Reporter: Ding Haifeng
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: kafka_failure_logs.tar.gz
>
>
> We are running a 10 node Kafka 0.8.1 cluster and experienced a failure as 
> following. 
> At some time, broker A stopped acting as controller any more. We see this by 
> kafka.controller - KafkaController - ActiveControllerCount in JMX metrics 
> jumped from 1 to 0.
> In the meanwhile, broker A was still running and registering itself in the 
> zookeeper /kafka/controller node. So no other brokers could be elected as new 
> controller.
> Since that the cluster was running without controller. Producers and 
> consumers still worked. But functions requiring a controller such as new 
> topic leader election and topic leader failover were not working any more.
> A force restart of broker A could lead to a controller election and bring the 
> cluster back to a correct state.
> Here is our brief observations. I can provide more necessary informations if 
> needed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1558) AdminUtils.deleteTopic does not work

[Neha Narkhede (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159379#comment-14159379
 ] 

Neha Narkhede commented on KAFKA-1558:
--

[~sriharsha] Now that KAFKA-1663 is pushed to trunk, the previously failing 
test should now pass right? The only other thing to wait on would be the leader 
rebalance tests. [~clarkhaskins], [~guozhang]: At this point, many failure 
tests pass on delete topic. It will be great to try delete topic on 100s of 
topics on some of LinkedIn's clusters, if possible. Any chance this test can 
happen in the 0.8.2 timeframe (1-2 weeks) ?

> AdminUtils.deleteTopic does not work
> 
>
> Key: KAFKA-1558
> URL: https://issues.apache.org/jira/browse/KAFKA-1558
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Henning Schmiedehausen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: kafka-thread-dump.log
>
>
> the AdminUtils:.deleteTopic method is implemented as
> {code}
> def deleteTopic(zkClient: ZkClient, topic: String) {
> ZkUtils.createPersistentPath(zkClient, 
> ZkUtils.getDeleteTopicPath(topic))
> }
> {code}
> but the DeleteTopicCommand actually does
> {code}
> zkClient = new ZkClient(zkConnect, 3, 3, ZKStringSerializer)
> zkClient.deleteRecursive(ZkUtils.getTopicPath(topic))
> {code}
> so I guess, that the 'createPersistentPath' above should actually be 
> {code}
> def deleteTopic(zkClient: ZkClient, topic: String) {
> ZkUtils.deletePathRecursive(zkClient, ZkUtils.getTopicPath(topic))
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1610) Local modifications to collections generated from mapValues will be lost

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede updated KAFKA-1610:
-
Reviewer:   (was: Neha Narkhede)

Sorry, may not get a chance to get to this review in a timely manner. 
[~jjkoshy], [~junrao] pinging you guys in case any of you can.

> Local modifications to collections generated from mapValues will be lost
> 
>
> Key: KAFKA-1610
> URL: https://issues.apache.org/jira/browse/KAFKA-1610
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Mayuresh Gharat
>  Labels: newbie
> Fix For: 0.9.0
>
> Attachments: KAFKA-1610.patch, KAFKA-1610_2014-08-29_09:51:51.patch, 
> KAFKA-1610_2014-08-29_10:03:55.patch, KAFKA-1610_2014-09-03_11:27:50.patch, 
> KAFKA-1610_2014-09-16_13:08:17.patch, KAFKA-1610_2014-09-16_15:23:27.patch, 
> KAFKA-1610_2014-09-30_23:21:46.patch, KAFKA-1610_2014-10-02_12:07:01.patch, 
> KAFKA-1610_2014-10-02_12:09:46.patch
>
>
> In our current Scala code base we have 40+ usages of mapValues, however it 
> has an important semantic difference with map, which is that "map" creates a 
> new map collection instance, while "mapValues" just create a map view of the 
> original map, and hence any further value changes to the view will be 
> effectively lost.
> Example code:
> {code}
> scala> case class Test(i: Int, var j: Int) {}
> defined class Test
> scala> val a = collection.mutable.Map(1 -> 1)
> a: scala.collection.mutable.Map[Int,Int] = Map(1 -> 1)
> scala> val b = a.mapValues(v => Test(v, v))
> b: scala.collection.Map[Int,Test] = Map(1 -> Test(1,1))
> scala> val c = a.map(v => v._1 -> Test(v._2, v._2))
> c: scala.collection.mutable.Map[Int,Test] = Map(1 -> Test(1,1))
> scala> b.foreach(kv => kv._2.j = kv._2.j + 1)
> scala> b
> res1: scala.collection.Map[Int,Test] = Map(1 -> Test(1,1))
> scala> c.foreach(kv => kv._2.j = kv._2.j + 1)
> scala> c
> res3: scala.collection.mutable.Map[Int,Test] = Map(1 -> Test(1,2))
> scala> a.put(1,3)
> res4: Option[Int] = Some(1)
> scala> b
> res5: scala.collection.Map[Int,Test] = Map(1 -> Test(3,3))
> scala> c
> res6: scala.collection.mutable.Map[Int,Test] = Map(1 -> Test(1,2))
> {code}
> We need to go through all these mapValue to see if they should be changed to 
> map



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1558) AdminUtils.deleteTopic does not work

[Sriharsha Chintalapani (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159381#comment-14159381
 ] 

Sriharsha Chintalapani commented on KAFKA-1558:
---

[~nehanarkhede] I ran all the tests except leader rebalance tests with 
KAFKA-1663 all of them are passed in my tests. With 1000 topics set to 
partition 3 and replication factor of 3 and producers, consumers running on all 
of the topics. I am planning on doing the leader rebalance tests tonight will 
update the results. It will be great to do this testing on LinkedIn's cluster 
too :).

> AdminUtils.deleteTopic does not work
> 
>
> Key: KAFKA-1558
> URL: https://issues.apache.org/jira/browse/KAFKA-1558
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Henning Schmiedehausen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: kafka-thread-dump.log
>
>
> the AdminUtils:.deleteTopic method is implemented as
> {code}
> def deleteTopic(zkClient: ZkClient, topic: String) {
> ZkUtils.createPersistentPath(zkClient, 
> ZkUtils.getDeleteTopicPath(topic))
> }
> {code}
> but the DeleteTopicCommand actually does
> {code}
> zkClient = new ZkClient(zkConnect, 3, 3, ZKStringSerializer)
> zkClient.deleteRecursive(ZkUtils.getTopicPath(topic))
> {code}
> so I guess, that the 'createPersistentPath' above should actually be 
> {code}
> def deleteTopic(zkClient: ZkClient, topic: String) {
> ZkUtils.deletePathRecursive(zkClient, ZkUtils.getTopicPath(topic))
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1631) ReplicationFactor and under-replicated partitions incorrect during reassignment

[Neha Narkhede (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159388#comment-14159388
 ] 

Neha Narkhede commented on KAFKA-1631:
--

The behavior of partition reassignment being old set -> old set + new set -> 
new set is just an implementation detail that users don't need to know and 
understand. However, there are 2 ways to report under replicated partitions 
today and this solution fixes one but not the other. For instance, if 
partitions being reassigned are not reported as under replicated through the 
topics tool (with this patch) but are reported by the broker's mbean, users 
would get confused. An ideal long term solution would be to define partition 
states as being one of the following - new, initializing, ready, migrating, 
under replicated (maybe more or less) and expose the partition's state as being 
one of these through the topic tool as well as JMX. It is possible to get away 
without having these states if there are maybe just 2 possible states that the 
partition lives in, but as the # of states increases, it is worth exposing 
those explicitly. One of these states is under-replicated and partitions being 
reassigned should belong to a separate "migrating" state, not "under 
replicated". 

> ReplicationFactor and under-replicated partitions incorrect during 
> reassignment
> ---
>
> Key: KAFKA-1631
> URL: https://issues.apache.org/jira/browse/KAFKA-1631
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>  Labels: newbie
> Attachments: KAFKA-1631-v1.patch
>
>
> We have a topic with a replication factor of 3. We monitor 
> UnderReplicatedPartitions as recommended by the documentation.
> During a partition reassignment, partitions being reassigned are reported as 
> under-replicated. Running a describe shows:
> {code}
> Topic:activity-wal-1PartitionCount:15   ReplicationFactor:5 
> Configs:
> Topic: activity-wal-1   Partition: 0Leader: 14  Replicas: 
> 14,13,12,11,15Isr: 14,12,11,13
> Topic: activity-wal-1   Partition: 1Leader: 14  Replicas: 
> 15,14,11  Isr: 14,11
> Topic: activity-wal-1   Partition: 2Leader: 11  Replicas: 
> 11,15,12  Isr: 12,11,15
> ...
> {code}
> It looks like the displayed replication factor, 5, is simply the number of 
> replicas listed for the first partition, which includes both brokers in the 
> current list and those onto which the partition is being reassigned. 
> Partition 0 is also included in the list when using the 
> `--under-replicated-partitions` option, even though it is replicated to more 
> partitions than the true replication factor.
> During a reassignment, the under-replicated partitions metric is not usable, 
> meaning that actual under-replicated partitions can go unnoticed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-328) Write unit test for kafka server startup and shutdown API

[Neha Narkhede (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159389#comment-14159389
 ] 

Neha Narkhede commented on KAFKA-328:
-

[~balaji.sesha...@dish.com] I use Intellij 13 community edition and whatever 
formatting that comes in that by default. 

> Write unit test for kafka server startup and shutdown API 
> --
>
> Key: KAFKA-328
> URL: https://issues.apache.org/jira/browse/KAFKA-328
> Project: Kafka
>  Issue Type: Bug
>Reporter: Neha Narkhede
>Assignee: BalajiSeshadri
>  Labels: newbie
> Attachments: KAFKA-328.patch
>
>
> Background discussion in KAFKA-320
> People often try to embed KafkaServer in an application that ends up calling 
> startup() and shutdown() repeatedly and sometimes in odd ways. To ensure this 
> works correctly we have to be very careful about cleaning up resources. This 
> is a good practice for making unit tests reliable anyway.
> A good first step would be to add some unit tests on startup and shutdown to 
> cover various cases:
> 1. A Kafka server can startup if it is not already starting up, if it is not 
> currently being shutdown, or if it hasn't been already started
> 2. A Kafka server can shutdown if it is not already shutting down, if it is 
> not currently starting up, or if it hasn't been already shutdown. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to normal : Kafka-trunk #288

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-1385) mirrormaker hangs during shutdown if no topic is consumed

[Neha Narkhede (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neha Narkhede resolved KAFKA-1385.
--
Resolution: Fixed

Fixed by patch for KAFKA-1650


> mirrormaker hangs during shutdown if no topic is consumed
> -
>
> Key: KAFKA-1385
> URL: https://issues.apache.org/jira/browse/KAFKA-1385
> Project: Kafka
>  Issue Type: Bug
>  Components: core
>Affects Versions: 0.8.2
>Reporter: Jun Rao
>
> Couldn't do clean shutdown when running the following command.
> bin/kafka-run-class.sh kafka.tools.MirrorMaker --producer.config 
> config/producer.properties --consumer.config config/consumer.properties 
> --blacklist=".*"
> Saw the following stacktrace.
> "Thread-6" prio=5 tid=7f94120af800 nid=0x113e16000 waiting on condition 
> [113e15000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <7ec0eb870> (a 
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> at 
> kafka.tools.MirrorMaker$MirrorMakerThread.awaitShutdown(MirrorMaker.scala:216)
> at 
> kafka.tools.MirrorMaker$$anonfun$cleanShutdown$2.apply(MirrorMaker.scala:167)
> at 
> kafka.tools.MirrorMaker$$anonfun$cleanShutdown$2.apply(MirrorMaker.scala:167)
> at 
> scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:61)
> at scala.collection.immutable.List.foreach(List.scala:45)
> at kafka.tools.MirrorMaker$.cleanShutdown(MirrorMaker.scala:167)
> at kafka.tools.MirrorMaker$$anon$2.run(MirrorMaker.scala:144)
> "mirrormaker-0" prio=5 tid=7f9414a90800 nid=0x113804000 waiting on condition 
> [113803000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <7ec0b0298> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at kafka.consumer.ConsumerIterator.makeNext(ConsumerIterator.scala:63)
> at kafka.consumer.ConsumerIterator.makeNext(ConsumerIterator.scala:33)
> at 
> kafka.utils.IteratorTemplate.maybeComputeNext(IteratorTemplate.scala:66)
> at kafka.utils.IteratorTemplate.hasNext(IteratorTemplate.scala:58)
> at scala.collection.Iterator$class.foreach(Iterator.scala:631)
> at kafka.utils.IteratorTemplate.foreach(IteratorTemplate.scala:32)
> at scala.collection.IterableLike$class.foreach(IterableLike.scala:79)
> at kafka.consumer.KafkaStream.foreach(KafkaStream.scala:25)
> at 
> kafka.tools.MirrorMaker$MirrorMakerThread.run(MirrorMaker.scala:190)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26346: Patch for KAFKA-1670

[Sriharsha Chintalapani]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26346/
---

(Updated Oct. 5, 2014, 3:17 a.m.)


Review request for kafka.


Bugs: KAFKA-1670
https://issues.apache.org/jira/browse/KAFKA-1670


Repository: kafka


Description
---

KAFKA-1670. Corrupt log files for segment.bytes values close to Int.MaxInt.


Diffs (updated)
-

  core/src/main/scala/kafka/log/Log.scala 
0ddf97bd30311b6039e19abade41d2fbbad2f59b 
  core/src/test/scala/unit/kafka/log/LogTest.scala 
577d102fc2eb6bb1a72326141ecd431db6d66f04 

Diff: https://reviews.apache.org/r/26346/diff/


Testing
---


Thanks,

Sriharsha Chintalapani

[jira] [Commented] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159407#comment-14159407
 ] 

Sriharsha Chintalapani commented on KAFKA-1670:
---

Updated reviewboard https://reviews.apache.org/r/26346/diff/
 against branch origin/trunk

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch, KAFKA-1670_2014-10-04_20:17:46.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sriharsha Chintalapani updated KAFKA-1670:
--
Attachment: KAFKA-1670_2014-10-04_20:17:46.patch

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch, KAFKA-1670_2014-10-04_20:17:46.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26346: Patch for KAFKA-1670

[Sriharsha Chintalapani]

> On Oct. 4, 2014, 11:28 p.m., Neha Narkhede wrote:
> > Can you try to add a unit test for this?

I added unit test under LogTest. This test very basic its just adds messages to 
file until the file reaches Int.Max. 
This will result in couple of issues first being atleast having 2G+ tmp space 
and also adds atleast 1 min to test execution latency.


- Sriharsha


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26346/#review55455
---


On Oct. 5, 2014, 3:17 a.m., Sriharsha Chintalapani wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26346/
> ---
> 
> (Updated Oct. 5, 2014, 3:17 a.m.)
> 
> 
> Review request for kafka.
> 
> 
> Bugs: KAFKA-1670
> https://issues.apache.org/jira/browse/KAFKA-1670
> 
> 
> Repository: kafka
> 
> 
> Description
> ---
> 
> KAFKA-1670. Corrupt log files for segment.bytes values close to Int.MaxInt.
> 
> 
> Diffs
> -
> 
>   core/src/main/scala/kafka/log/Log.scala 
> 0ddf97bd30311b6039e19abade41d2fbbad2f59b 
>   core/src/test/scala/unit/kafka/log/LogTest.scala 
> 577d102fc2eb6bb1a72326141ecd431db6d66f04 
> 
> Diff: https://reviews.apache.org/r/26346/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sriharsha Chintalapani
> 
>

[jira] [Commented] (KAFKA-1670) Corrupt log files for segment.bytes values close to Int.MaxInt

[Sriharsha Chintalapani (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159411#comment-14159411
 ] 

Sriharsha Chintalapani commented on KAFKA-1670:
---

[~nehanarkhede] [~junrao] LogConfig default values doesn't match broker 
configuration defaults here https://kafka.apache.org/08/configuration.html
example
  SegmentSize = 1024 * 1024 (LogConfig)  and in broker log.segment.bytes
1024 * 1024 * 1024
and also MaxIndexSize
any reason for them not to be same ?

> Corrupt log files for segment.bytes values close to Int.MaxInt
> --
>
> Key: KAFKA-1670
> URL: https://issues.apache.org/jira/browse/KAFKA-1670
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.8.1.1
>Reporter: Ryan Berdeen
>Assignee: Sriharsha Chintalapani
>Priority: Blocker
> Fix For: 0.8.2
>
> Attachments: KAFKA-1670.patch, KAFKA-1670_2014-10-04_20:17:46.patch
>
>
> The maximum value for the topic-level config {{segment.bytes}} is 
> {{Int.MaxInt}} (2147483647). *Using this value causes brokers to corrupt 
> their log files, leaving them unreadable.*
> We set {{segment.bytes}} to {{2122317824}} which is well below the maximum. 
> One by one, the ISR of all partitions shrunk to 1. Brokers would crash when 
> restarted, attempting to read from a negative offset in a log file. After 
> discovering that many segment files had grown to 4GB or more, we were forced 
> to shut down our *entire production Kafka cluster* for several hours while we 
> split all segment files into 1GB chunks.
> Looking into the {{kafka.log}} code, the {{segment.bytes}} parameter is used 
> inconsistently. It is treated as a *soft* maximum for the size of the segment 
> file 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/LogConfig.scala#L26)
>  with logs rolled only after 
> (https://github.com/apache/kafka/blob/0.8.1.1/core/src/main/scala/kafka/log/Log.scala#L246)
>  they exceed this value. However, much of the code that deals with log files 
> uses *ints* to store the size of the file and the position in the file. 
> Overflow of these ints leads the broker to append to the segments 
> indefinitely, and to fail to read these segments for consuming or recovery.
> This is trivial to reproduce:
> {code}
> $ bin/kafka-topics.sh --topic segment-bytes-test --create 
> --replication-factor 2 --partitions 1 --zookeeper zkhost:2181
> $ bin/kafka-topics.sh --topic segment-bytes-test --alter --config 
> segment.bytes=2147483647 --zookeeper zkhost:2181
> $ yes "Int.MaxValue is a ridiculous bound on file size in 2014" | 
> bin/kafka-console-producer.sh --broker-list localhost:6667 zkhost:2181 
> --topic segment-bytes-test
> {code}
> After running for a few minutes, the log file is corrupt:
> {code}
> $ ls -lh data/segment-bytes-test-0/
> total 9.7G
> -rw-r--r-- 1 root root  10M Oct  3 19:39 .index
> -rw-r--r-- 1 root root 9.7G Oct  3 19:39 .log
> {code}
> We recovered the data from the log files using a simple Python script: 
> https://gist.github.com/also/9f823d9eb9dc0a410796



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 26348: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26348/
---

Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26348/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159436#comment-14159436
 ] 

Manikumar Reddy commented on KAFKA-1277:


Created reviewboard https://reviews.apache.org/r/26348/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26348: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26348/
---

(Updated Oct. 5, 2014, 5:37 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description (updated)
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26348/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-05_11:04:33.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159437#comment-14159437
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26348/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26348: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26348/
---

(Updated Oct. 5, 2014, 5:41 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26348/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-05_11:09:08.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159439#comment-14159439
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26348/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26348: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26348/
---

(Updated Oct. 5, 2014, 5:43 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26348/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-05_11:10:50.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159441#comment-14159441
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26348/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 26349: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26349/
---

Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description
---

KAFKA-1277;Keep the summary/description when updating the RB with 
kafka-patch-review


Diffs
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26349/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Updated] (KAFKA-328) Write unit test for kafka server startup and shutdown API

[BalajiSeshadri (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

BalajiSeshadri updated KAFKA-328:
-
Attachment: KAFKA-328-FORMATTED.patch

> Write unit test for kafka server startup and shutdown API 
> --
>
> Key: KAFKA-328
> URL: https://issues.apache.org/jira/browse/KAFKA-328
> Project: Kafka
>  Issue Type: Bug
>Reporter: Neha Narkhede
>Assignee: BalajiSeshadri
>  Labels: newbie
> Attachments: KAFKA-328-FORMATTED.patch, KAFKA-328.patch
>
>
> Background discussion in KAFKA-320
> People often try to embed KafkaServer in an application that ends up calling 
> startup() and shutdown() repeatedly and sometimes in odd ways. To ensure this 
> works correctly we have to be very careful about cleaning up resources. This 
> is a good practice for making unit tests reliable anyway.
> A good first step would be to add some unit tests on startup and shutdown to 
> cover various cases:
> 1. A Kafka server can startup if it is not already starting up, if it is not 
> currently being shutdown, or if it hasn't been already started
> 2. A Kafka server can shutdown if it is not already shutting down, if it is 
> not currently starting up, or if it hasn't been already shutdown. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159444#comment-14159444
 ] 

Manikumar Reddy commented on KAFKA-1277:


Created reviewboard https://reviews.apache.org/r/26349/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-328) Write unit test for kafka server startup and shutdown API

[BalajiSeshadri (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159445#comment-14159445
 ] 

BalajiSeshadri commented on KAFKA-328:
--

[~nehanarkhede] Please find patch for Startup Test.

> Write unit test for kafka server startup and shutdown API 
> --
>
> Key: KAFKA-328
> URL: https://issues.apache.org/jira/browse/KAFKA-328
> Project: Kafka
>  Issue Type: Bug
>Reporter: Neha Narkhede
>Assignee: BalajiSeshadri
>  Labels: newbie
> Attachments: KAFKA-328-FORMATTED.patch, KAFKA-328.patch
>
>
> Background discussion in KAFKA-320
> People often try to embed KafkaServer in an application that ends up calling 
> startup() and shutdown() repeatedly and sometimes in odd ways. To ensure this 
> works correctly we have to be very careful about cleaning up resources. This 
> is a good practice for making unit tests reliable anyway.
> A good first step would be to add some unit tests on startup and shutdown to 
> cover various cases:
> 1. A Kafka server can startup if it is not already starting up, if it is not 
> currently being shutdown, or if it hasn't been already started
> 2. A Kafka server can shutdown if it is not already shutting down, if it is 
> not currently starting up, or if it hasn't been already shutdown. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manikumar Reddy updated KAFKA-1277:
---
Attachment: KAFKA-1277_2014-10-05_11:18:17.patch

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch, 
> KAFKA-1277_2014-10-05_11:18:17.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 26349: Patch for KAFKA-1277

[Manikumar Reddy O]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26349/
---

(Updated Oct. 5, 2014, 5:51 a.m.)


Review request for kafka.


Bugs: KAFKA-1277
https://issues.apache.org/jira/browse/KAFKA-1277


Repository: kafka


Description (updated)
---

Testing this patch


Diffs (updated)
-

  kafka-patch-review.py b7f132f9d210b8648859ab8f9c89f30ec128ab38 

Diff: https://reviews.apache.org/r/26349/diff/


Testing
---


Thanks,

Manikumar Reddy O

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159446#comment-14159446
 ] 

Manikumar Reddy commented on KAFKA-1277:


Updated reviewboard https://reviews.apache.org/r/26349/diff/
 against branch origin/trunk

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch, 
> KAFKA-1277_2014-10-05_11:18:17.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KAFKA-1277) Keep the summery/description when updating the RB with kafka-patch-review

[Manikumar Reddy (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159447#comment-14159447
 ] 

Manikumar Reddy commented on KAFKA-1277:


[~nehanarkhede]  What is the version of your rbt tool?
I am using RBTools 0.6.2

$ rbt --version
RBTools 0.6.2

I uploaded a new patch, which should work with older version of rbt.
Can you try the latest patch?

> Keep the summery/description when updating the RB with kafka-patch-review
> -
>
> Key: KAFKA-1277
> URL: https://issues.apache.org/jira/browse/KAFKA-1277
> Project: Kafka
>  Issue Type: Bug
>Reporter: Guozhang Wang
>Assignee: Manikumar Reddy
> Attachments: KAFKA-1277.patch, KAFKA-1277.patch, KAFKA-1277.patch, 
> KAFKA-1277_2014-10-04_16:39:56.patch, KAFKA-1277_2014-10-04_16:51:20.patch, 
> KAFKA-1277_2014-10-04_16:57:30.patch, KAFKA-1277_2014-10-04_17:00:37.patch, 
> KAFKA-1277_2014-10-04_17:01:43.patch, KAFKA-1277_2014-10-04_17:03:08.patch, 
> KAFKA-1277_2014-10-04_17:09:02.patch, KAFKA-1277_2014-10-05_11:04:33.patch, 
> KAFKA-1277_2014-10-05_11:09:08.patch, KAFKA-1277_2014-10-05_11:10:50.patch, 
> KAFKA-1277_2014-10-05_11:18:17.patch
>
>
> Today kafka-patch-review tool will always use a default title and description 
> if they are not specified, even when updating an existing RB. Would better 
> change to leave the current title/description as is.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)