[jira] [Commented] (KAFKA-5508) Documentation for altering topics

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on KAFKA-5508:
---

GitHub user huxihx opened a pull request:

https://github.com/apache/kafka/pull/3429

KAFKA-5508: Documentation for altering topics

Operations documentation should guide user to employ `kafka-configs.sh` to 
add/remove configs for a topic.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/huxihx/kafka 
KAFKA-5508_Doc_for_altering_topics

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/3429.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3429


commit ec66e8f1a6b14c47eaca0205d0ffedc76ce4ce53
Author: huxihx 
Date:   2017-06-26T00:53:31Z

KAFKA-5508: Documentation for altering topics

Operations documentation should guide user to employ `kafka-configs.sh` to 
add/remove configs for a topic.




> Documentation for altering topics
> -
>
> Key: KAFKA-5508
> URL: https://issues.apache.org/jira/browse/KAFKA-5508
> Project: Kafka
>  Issue Type: Bug
>  Components: documentation
>Reporter: Tom Bentley
>Assignee: huxihx
>Priority: Minor
>
> According to the upgrade documentation:
> bq. Altering topic configuration from the kafka-topics.sh script 
> (kafka.admin.TopicCommand) has been deprecated. Going forward, please use the 
> kafka-configs.sh script (kafka.admin.ConfigCommand) for this functionality. 
> But the Operations documentation still tells people to use kafka-topics.sh to 
> alter their topic configurations.



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

[jira] [Assigned] (KAFKA-5508) Documentation for altering topics

[huxihx (JIRA)]

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

huxihx reassigned KAFKA-5508:
-

Assignee: huxihx

> Documentation for altering topics
> -
>
> Key: KAFKA-5508
> URL: https://issues.apache.org/jira/browse/KAFKA-5508
> Project: Kafka
>  Issue Type: Bug
>  Components: documentation
>Reporter: Tom Bentley
>Assignee: huxihx
>Priority: Minor
>
> According to the upgrade documentation:
> bq. Altering topic configuration from the kafka-topics.sh script 
> (kafka.admin.TopicCommand) has been deprecated. Going forward, please use the 
> kafka-configs.sh script (kafka.admin.ConfigCommand) for this functionality. 
> But the Operations documentation still tells people to use kafka-topics.sh to 
> alter their topic configurations.



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

[jira] [Commented] (KAFKA-5145) Remove task close() call from closeNonAssignedSuspendedTasks method

[Matthias J. Sax (JIRA)]

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

Matthias J. Sax commented on KAFKA-5145:


[~mingleizhang] Thanks for starting to contribute to Kafka! I just realized, 
that this is a duplicate and there is already a PR for the other Jira (cf 
KAFKA-5485). There should be other "newbie" Jira thought you can pick up.

[~damianguy] Can you add [~mingleizhang] to the contributor list, so he can 
assign Jiras to himself. Thx.

> Remove task close() call from closeNonAssignedSuspendedTasks method
> ---
>
> Key: KAFKA-5145
> URL: https://issues.apache.org/jira/browse/KAFKA-5145
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.10.2.0
>Reporter: Narendra Kumar
>  Labels: newbie
> Attachments: BugTest.java, DebugTransformer.java, logs.txt
>
>
> While rebalancing ProcessorNode.close() can be called twice, once  from 
> StreamThread.suspendTasksAndState() and once from  
> StreamThread.closeNonAssignedSuspendedTasks(). If ProcessorNode.close() 
> throws some exception because of calling close() multiple times( i.e. 
> IllegalStateException from  some KafkaConsumer instance being used by some 
> processor for some lookup), we fail to close the task's state manager ( i.e. 
> call to task.closeStateManager(true); fails).  After rebalance, if the same 
> task id is launched on same application instance but in different thread then 
> the task get stuck because it fails to get lock to the task's state directory.
> Since processor close() is already called from 
> StreamThread.suspendTasksAndState() we don't need to call again from 
> StreamThread.closeNonAssignedSuspendedTasks().



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

[jira] [Commented] (KAFKA-4750) KeyValueIterator returns null values

[Matthias J. Sax (JIRA)]

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

Matthias J. Sax commented on KAFKA-4750:


Sounds good to me.

> KeyValueIterator returns null values
> 
>
> Key: KAFKA-4750
> URL: https://issues.apache.org/jira/browse/KAFKA-4750
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.10.1.1, 0.11.0.0, 0.10.2.1
>Reporter: Michal Borowiecki
>Assignee: Evgeny Veretennikov
>  Labels: newbie
> Attachments: DeleteTest.java
>
>
> The API for ReadOnlyKeyValueStore.range method promises the returned iterator 
> will not return null values. However, after upgrading from 0.10.0.0 to 
> 0.10.1.1 we found null values are returned causing NPEs on our side.
> I found this happens after removing entries from the store and I found 
> resemblance to SAMZA-94 defect. The problem seems to be as it was there, when 
> deleting entries and having a serializer that does not return null when null 
> is passed in, the state store doesn't actually delete that key/value pair but 
> the iterator will return null value for that key.
> When I modified our serilizer to return null when null is passed in, the 
> problem went away. However, I believe this should be fixed in kafka streams, 
> perhaps with a similar approach as SAMZA-94.



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

[jira] [Commented] (KAFKA-4750) KeyValueIterator returns null values

[Guozhang Wang (JIRA)]

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

Guozhang Wang commented on KAFKA-4750:
--

I think the Streams library should not assume that either 1) the serde will 
always return {{null}} if the input is {{null}}, or 2) the serde will never 
return {{null}} if the input is not {{null}}. On the other hand, since we are 
treating {{null}} to indicate deletion specifically, checking null values 
before calling the serde makes sense to me.



> KeyValueIterator returns null values
> 
>
> Key: KAFKA-4750
> URL: https://issues.apache.org/jira/browse/KAFKA-4750
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.10.1.1, 0.11.0.0, 0.10.2.1
>Reporter: Michal Borowiecki
>Assignee: Evgeny Veretennikov
>  Labels: newbie
> Attachments: DeleteTest.java
>
>
> The API for ReadOnlyKeyValueStore.range method promises the returned iterator 
> will not return null values. However, after upgrading from 0.10.0.0 to 
> 0.10.1.1 we found null values are returned causing NPEs on our side.
> I found this happens after removing entries from the store and I found 
> resemblance to SAMZA-94 defect. The problem seems to be as it was there, when 
> deleting entries and having a serializer that does not return null when null 
> is passed in, the state store doesn't actually delete that key/value pair but 
> the iterator will return null value for that key.
> When I modified our serilizer to return null when null is passed in, the 
> problem went away. However, I believe this should be fixed in kafka streams, 
> perhaps with a similar approach as SAMZA-94.



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

[jira] [Commented] (KAFKA-5145) Remove task close() call from closeNonAssignedSuspendedTasks method

[mingleizhang (JIRA)]

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

mingleizhang commented on KAFKA-5145:
-

I am a new to kafka. Can anyone give me a permission that contribute to Kafka ?

> Remove task close() call from closeNonAssignedSuspendedTasks method
> ---
>
> Key: KAFKA-5145
> URL: https://issues.apache.org/jira/browse/KAFKA-5145
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.10.2.0
>Reporter: Narendra Kumar
>  Labels: newbie
> Attachments: BugTest.java, DebugTransformer.java, logs.txt
>
>
> While rebalancing ProcessorNode.close() can be called twice, once  from 
> StreamThread.suspendTasksAndState() and once from  
> StreamThread.closeNonAssignedSuspendedTasks(). If ProcessorNode.close() 
> throws some exception because of calling close() multiple times( i.e. 
> IllegalStateException from  some KafkaConsumer instance being used by some 
> processor for some lookup), we fail to close the task's state manager ( i.e. 
> call to task.closeStateManager(true); fails).  After rebalance, if the same 
> task id is launched on same application instance but in different thread then 
> the task get stuck because it fails to get lock to the task's state directory.
> Since processor close() is already called from 
> StreamThread.suspendTasksAndState() we don't need to call again from 
> StreamThread.closeNonAssignedSuspendedTasks().



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