[GitHub] [kafka] ijuma commented on pull request #8705: KAFKA-10029; Don't update completedReceives when channels are closed to avoid ConcurrentModificationException

ijuma commented on pull request #8705: URL: https://github.com/apache/kafka/pull/8705#issuecomment-634696784 One more thing, can we improve `KafkaChannel.hashCode/equals` to avoid unnecessary work? The calls to `Objects.equals` and `Objects.hash` seem pointless.

[GitHub] [kafka] ijuma commented on pull request #8705: KAFKA-10029; Don't update completedReceives when channels are closed to avoid ConcurrentModificationException

ijuma commented on pull request #8705: URL: https://github.com/apache/kafka/pull/8705#issuecomment-634696095 This change is probably OK, but the way we call `close` while iterating over `completedReceives` seems a bit fragile. It would probably be safer to collect the items we need to

[GitHub] [kafka] ijuma commented on pull request #8705: KAFKA-10029; Don't update completedReceives when channels are closed to avoid ConcurrentModificationException

ijuma commented on pull request #8705: URL: https://github.com/apache/kafka/pull/8705#issuecomment-634692630 @rajinisivaram We also retain a reference to the `NetworkReceive`, which is probably a bigger deal, right? This is

[GitHub] [kafka] ijuma commented on pull request #8705: KAFKA-10029; Don't update completedReceives when channels are closed to avoid ConcurrentModificationException

ijuma commented on pull request #8705: URL: https://github.com/apache/kafka/pull/8705#issuecomment-633725248 @rajinisivaram What's the implication of not removing the completed receive in `doClose`? This is an automated