[jira] [Commented] (KAFKA-8818) CreatePartitions Request protocol documentation

[Asutosh Pandya (Jira)]

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

Asutosh Pandya commented on KAFKA-8818:
---

[~ffosilva] - Please review

> CreatePartitions Request protocol documentation
> ---
>
> Key: KAFKA-8818
> URL: https://issues.apache.org/jira/browse/KAFKA-8818
> Project: Kafka
>  Issue Type: Bug
>  Components: documentation
>Reporter: Fábio Silva
>Priority: Major
>  Labels: documentation, protocol-documentation
>
> CreatePartitions Request protocol documentation contains a invalid type 
> ARRAY(INT32) (assignment field), it must be INT32.
> Wrong: 
> {code:java}
> assignment => ARRAY(INT32){code}
> Correct:
> {code:java}
> assignment => INT32
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Assigned] (KAFKA-8698) ListOffsets Response protocol documentation

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya reassigned KAFKA-8698:
-

Assignee: Asutosh Pandya

> ListOffsets Response protocol documentation
> ---
>
> Key: KAFKA-8698
> URL: https://issues.apache.org/jira/browse/KAFKA-8698
> Project: Kafka
>  Issue Type: Bug
>  Components: documentation
>Reporter: Fábio Silva
>Assignee: Asutosh Pandya
>Priority: Minor
>  Labels: documentation
>
> The documentation of ListOffsets Response (Version: 0) appears to have an 
> typo on offsets field name, suffixed with `'`.
> {code:java}
> [offsets']{code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (KAFKA-7345) Potentially unclosed FileChannel in StateDirectory#unlock

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya updated KAFKA-7345:
--
Attachment: KAFKA_7345.patch

> Potentially unclosed FileChannel in StateDirectory#unlock
> -
>
> Key: KAFKA-7345
> URL: https://issues.apache.org/jira/browse/KAFKA-7345
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Reporter: Ted Yu
>Priority: Minor
> Attachments: KAFKA_7345.patch
>
>
> {code}
> lockAndOwner.lock.release();
> log.debug("{} Released state dir lock for task {}", logPrefix(), 
> taskId);
> final FileChannel fileChannel = channels.remove(taskId);
> if (fileChannel != null) {
> fileChannel.close();
> {code}
> If {{lockAndOwner.lock.release()}} throws IOE, the closing of the FileChannel 
> would be skipped.



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

[jira] [Updated] (KAFKA-6420) Adding Msys support

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya updated KAFKA-6420:
--
Attachment: KAFKA-6420.patch

> Adding Msys support
> ---
>
> Key: KAFKA-6420
> URL: https://issues.apache.org/jira/browse/KAFKA-6420
> Project: Kafka
>  Issue Type: Improvement
>  Components: tools
> Environment: Msys/Msys2 on Windows
>Reporter: Pas
>Priority: Trivial
>  Labels: windows
> Attachments: KAFKA-6420.patch
>
>
> Hello,
> In kafka-run-class.sh (currently line 24), using:
> {code:none}
> if [[ $(uname -a) =~ "CYGWIN" ]] || [[ $(uname -a) =~ "Msys" ]]; then
> {code}
> instead of:
> {code:none}
> if [[ $(uname -a) =~ "CYGWIN" ]]; then
> {code}
> would be great.
> Thanks for considering!



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

[jira] [Commented] (KAFKA-6673) Segment and Stamped implement Comparable, but don't override equals.

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6673:
---

Could someone please review this PR?

> Segment and Stamped implement Comparable, but don't override equals.
> 
>
> Key: KAFKA-6673
> URL: https://issues.apache.org/jira/browse/KAFKA-6673
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: KAFKA_6673.patch
>
>
> The classes in question:
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/internals/Segment.java
> and
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/processor/internals/Stamped.java
> This came up while doing static analysis on the codebase on the trunk branch.
> As described by the analysis tool built into Intellij:
> {quote}
> Reports classes which implement java.lang.Comparable which do not override 
> equals(). If equals() is not overridden, the equals() implementation is not 
> consistent with the compareTo() implementation. If an object of such a class 
> is added to a collection such as java.util.SortedSet, this collection will 
> violate the contract of java.util.Set, which is defined in terms of equals().
> {quote}
>  
> Implementing an equals for an object is generally a best practice, especially 
> considering this caveat, where it's not the compareTo that will be used but 
> the equals method.



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

[jira] [Commented] (KAFKA-6673) Segment and Stamped implement Comparable, but don't override equals.

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6673:
---

[~KoenDG]

Have implemented review comment and tried to mimic compareTo logic for similar 
behavior.

> Segment and Stamped implement Comparable, but don't override equals.
> 
>
> Key: KAFKA-6673
> URL: https://issues.apache.org/jira/browse/KAFKA-6673
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: KAFKA_6673.patch
>
>
> The classes in question:
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/internals/Segment.java
> and
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/processor/internals/Stamped.java
> This came up while doing static analysis on the codebase on the trunk branch.
> As described by the analysis tool built into Intellij:
> {quote}
> Reports classes which implement java.lang.Comparable which do not override 
> equals(). If equals() is not overridden, the equals() implementation is not 
> consistent with the compareTo() implementation. If an object of such a class 
> is added to a collection such as java.util.SortedSet, this collection will 
> violate the contract of java.util.Set, which is defined in terms of equals().
> {quote}
>  
> Implementing an equals for an object is generally a best practice, especially 
> considering this caveat, where it's not the compareTo that will be used but 
> the equals method.



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

[jira] [Commented] (KAFKA-6673) Segment and Stamped implement Comparable, but don't override equals.

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6673:
---

PR: https://github.com/apache/kafka/pull/4745

> Segment and Stamped implement Comparable, but don't override equals.
> 
>
> Key: KAFKA-6673
> URL: https://issues.apache.org/jira/browse/KAFKA-6673
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: KAFKA_6673.patch
>
>
> The classes in question:
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/internals/Segment.java
> and
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/processor/internals/Stamped.java
> This came up while doing static analysis on the codebase on the trunk branch.
> As described by the analysis tool built into Intellij:
> {quote}
> Reports classes which implement java.lang.Comparable which do not override 
> equals(). If equals() is not overridden, the equals() implementation is not 
> consistent with the compareTo() implementation. If an object of such a class 
> is added to a collection such as java.util.SortedSet, this collection will 
> violate the contract of java.util.Set, which is defined in terms of equals().
> {quote}
>  
> Implementing an equals for an object is generally a best practice, especially 
> considering this caveat, where it's not the compareTo that will be used but 
> the equals method.



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

[jira] [Updated] (KAFKA-6673) Segment and Stamped implement Comparable, but don't override equals.

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya updated KAFKA-6673:
--
Attachment: KAFKA_6673.patch

> Segment and Stamped implement Comparable, but don't override equals.
> 
>
> Key: KAFKA-6673
> URL: https://issues.apache.org/jira/browse/KAFKA-6673
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Reporter: Koen De Groote
>Priority: Minor
> Attachments: KAFKA_6673.patch
>
>
> The classes in question:
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/internals/Segment.java
> and
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/processor/internals/Stamped.java
> This came up while doing static analysis on the codebase on the trunk branch.
> As described by the analysis tool built into Intellij:
> {quote}
> Reports classes which implement java.lang.Comparable which do not override 
> equals(). If equals() is not overridden, the equals() implementation is not 
> consistent with the compareTo() implementation. If an object of such a class 
> is added to a collection such as java.util.SortedSet, this collection will 
> violate the contract of java.util.Set, which is defined in terms of equals().
> {quote}
>  
> Implementing an equals for an object is generally a best practice, especially 
> considering this caveat, where it's not the compareTo that will be used but 
> the equals method.



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

[jira] [Commented] (KAFKA-6486) TimeWindows causes unordered calls to windowed aggregation functions

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6486:
---

[~mjsax]

Pull Request created: [https://github.com/apache/kafka/pull/4628]

Best Regards,

Asutosh

> TimeWindows causes unordered calls to windowed aggregation functions
> 
>
> Key: KAFKA-6486
> URL: https://issues.apache.org/jira/browse/KAFKA-6486
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 1.0.0
>Reporter: Valentino Proietti
>Priority: Minor
> Attachments: KAFKA-6486.patch
>
>
> This is not a real bug but it causes some weird behaviour, at least in my 
> opinion.
> The TimeWindows has a method called windowsFor() that uses and returns an 
> HashMap:
>     @Override
>     *public* Map windowsFor(*final* *long* timestamp) {
>         *long* windowStart = (Math._max_(0, timestamp - sizeMs + advanceMs) / 
> advanceMs) * advanceMs;
>         *final* Map windows = *new* HashMap<>();
>         
> the HashMap does not preserve the order of insertion and this ends up later 
> in calls to any streams windowed aggregation functions that are not ordered 
> by window time as I would expect.
> A simple solution is to replace the HashMap with a LinkedHashMap and that's 
> what I did.
> Anyway replacing it directly in your code can save hours of debugging to 
> understand what's happening.
> Thank you 
>  



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

[jira] [Commented] (KAFKA-6486) TimeWindows causes unordered calls to windowed aggregation functions

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6486:
---

Thank You [~mjsax], would love to contribute as much as I can.

Below are the details:

PR: [https://github.com/apache/kafka/pull/4619]

JIRA: https://issues.apache.org/jira/browse/KAFKA-5609

 

Once above Pull Request is merged, will create PR for current patch. Hope that 
works.

> TimeWindows causes unordered calls to windowed aggregation functions
> 
>
> Key: KAFKA-6486
> URL: https://issues.apache.org/jira/browse/KAFKA-6486
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 1.0.0
>Reporter: Valentino Proietti
>Priority: Minor
> Attachments: KAFKA-6486.patch
>
>
> This is not a real bug but it causes some weird behaviour, at least in my 
> opinion.
> The TimeWindows has a method called windowsFor() that uses and returns an 
> HashMap:
>     @Override
>     *public* Map windowsFor(*final* *long* timestamp) {
>         *long* windowStart = (Math._max_(0, timestamp - sizeMs + advanceMs) / 
> advanceMs) * advanceMs;
>         *final* Map windows = *new* HashMap<>();
>         
> the HashMap does not preserve the order of insertion and this ends up later 
> in calls to any streams windowed aggregation functions that are not ordered 
> by window time as I would expect.
> A simple solution is to replace the HashMap with a LinkedHashMap and that's 
> what I did.
> Anyway replacing it directly in your code can save hours of debugging to 
> understand what's happening.
> Thank you 
>  



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

[jira] [Commented] (KAFKA-6486) TimeWindows causes unordered calls to windowed aggregation functions

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-6486:
---

Added patch with above mentioned change.

I already have one Pull Request to merge, hence attaching patch.

 

Best Regards,

Asutosh

> TimeWindows causes unordered calls to windowed aggregation functions
> 
>
> Key: KAFKA-6486
> URL: https://issues.apache.org/jira/browse/KAFKA-6486
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 1.0.0
>Reporter: Valentino Proietti
>Priority: Minor
> Attachments: KAFKA-6486.patch
>
>
> This is not a real bug but it causes some weird behaviour, at least in my 
> opinion.
> The TimeWindows has a method called windowsFor() that uses and returns an 
> HashMap:
>     @Override
>     *public* Map windowsFor(*final* *long* timestamp) {
>         *long* windowStart = (Math._max_(0, timestamp - sizeMs + advanceMs) / 
> advanceMs) * advanceMs;
>         *final* Map windows = *new* HashMap<>();
>         
> the HashMap does not preserve the order of insertion and this ends up later 
> in calls to any streams windowed aggregation functions that are not ordered 
> by window time as I would expect.
> A simple solution is to replace the HashMap with a LinkedHashMap and that's 
> what I did.
> Anyway replacing it directly in your code can save hours of debugging to 
> understand what's happening.
> Thank you 
>  



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

[jira] [Comment Edited] (KAFKA-6486) TimeWindows causes unordered calls to windowed aggregation functions

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya edited comment on KAFKA-6486 at 2/27/18 12:50 AM:
-

[~guozhang]

 

Added patch with above mentioned change.

I already have one Pull Request to merge, hence attaching patch.

 

Best Regards,

Asutosh


was (Author: asutosh_pandya):
Added patch with above mentioned change.

I already have one Pull Request to merge, hence attaching patch.

 

Best Regards,

Asutosh

> TimeWindows causes unordered calls to windowed aggregation functions
> 
>
> Key: KAFKA-6486
> URL: https://issues.apache.org/jira/browse/KAFKA-6486
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 1.0.0
>Reporter: Valentino Proietti
>Priority: Minor
> Attachments: KAFKA-6486.patch
>
>
> This is not a real bug but it causes some weird behaviour, at least in my 
> opinion.
> The TimeWindows has a method called windowsFor() that uses and returns an 
> HashMap:
>     @Override
>     *public* Map windowsFor(*final* *long* timestamp) {
>         *long* windowStart = (Math._max_(0, timestamp - sizeMs + advanceMs) / 
> advanceMs) * advanceMs;
>         *final* Map windows = *new* HashMap<>();
>         
> the HashMap does not preserve the order of insertion and this ends up later 
> in calls to any streams windowed aggregation functions that are not ordered 
> by window time as I would expect.
> A simple solution is to replace the HashMap with a LinkedHashMap and that's 
> what I did.
> Anyway replacing it directly in your code can save hours of debugging to 
> understand what's happening.
> Thank you 
>  



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

[jira] [Updated] (KAFKA-6486) TimeWindows causes unordered calls to windowed aggregation functions

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya updated KAFKA-6486:
--
Attachment: KAFKA-6486.patch

> TimeWindows causes unordered calls to windowed aggregation functions
> 
>
> Key: KAFKA-6486
> URL: https://issues.apache.org/jira/browse/KAFKA-6486
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 1.0.0
>Reporter: Valentino Proietti
>Priority: Minor
> Attachments: KAFKA-6486.patch
>
>
> This is not a real bug but it causes some weird behaviour, at least in my 
> opinion.
> The TimeWindows has a method called windowsFor() that uses and returns an 
> HashMap:
>     @Override
>     *public* Map windowsFor(*final* *long* timestamp) {
>         *long* windowStart = (Math._max_(0, timestamp - sizeMs + advanceMs) / 
> advanceMs) * advanceMs;
>         *final* Map windows = *new* HashMap<>();
>         
> the HashMap does not preserve the order of insertion and this ends up later 
> in calls to any streams windowed aggregation functions that are not ordered 
> by window time as I would expect.
> A simple solution is to replace the HashMap with a LinkedHashMap and that's 
> what I did.
> Anyway replacing it directly in your code can save hours of debugging to 
> understand what's happening.
> Thank you 
>  



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

[jira] [Commented] (KAFKA-5609) Connect log4j should log to file by default

[Asutosh Pandya (JIRA)]

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

Asutosh Pandya commented on KAFKA-5609:
---

[~yevabyzek]

 

Have created pull request for above issue: 
[https://github.com/apache/kafka/pull/4619.] 

I am trying to attach the patch as well but unable to do that, also am not able 
to assign the issue to myself. Let me know if I need to send a patch through 
other digital medium.

Best Regards,

Asutosh

> Connect log4j should log to file by default
> ---
>
> Key: KAFKA-5609
> URL: https://issues.apache.org/jira/browse/KAFKA-5609
> Project: Kafka
>  Issue Type: Improvement
>  Components: config, KafkaConnect
>Affects Versions: 0.11.0.0
>Reporter: Yeva Byzek
>Priority: Minor
>  Labels: easyfix
>
> {{https://github.com/apache/kafka/blob/trunk/config/connect-log4j.properties}}
> Currently logs to stdout.  It should also log to a file by default, otherwise 
> it just writes to console and messages can be lost



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