[jira] [Created] (KAFKA-8229) Connect Sink Task updates nextCommit when commitRequest is true
Scott Reynolds created KAFKA-8229: - Summary: Connect Sink Task updates nextCommit when commitRequest is true Key: KAFKA-8229 URL: https://issues.apache.org/jira/browse/KAFKA-8229 Project: Kafka Issue Type: Bug Reporter: Scott Reynolds Today, when a WorkerSinkTask uses context.requestCommit(), the next call to iteration will cause the commit to happen. As part of the commit execution it will also change the nextCommit milliseconds. This creates some weird behaviors when a SinkTask calls context.requestCommit multiple times. In our case, we were calling requestCommit when the number of kafka records we processed exceed a threshold. This resulted in the nextCommit being several days in the future and caused it to only commit when the record threshold was reached. We expected the task to commit when the record threshold was reached OR when the timer went off. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KAFKA-4632) Kafka Connect WorkerSinkTask.closePartitions doesn't handle WakeupException
Scott Reynolds created KAFKA-4632:
-
Summary: Kafka Connect WorkerSinkTask.closePartitions doesn't
handle WakeupException
Key: KAFKA-4632
URL: https://issues.apache.org/jira/browse/KAFKA-4632
Project: Kafka
Issue Type: Bug
Affects Versions: 0.10.0.1, 0.10.0.0, 0.10.1.0
Reporter: Scott Reynolds
WorkerSinkTask's closePartitions method isn't handling WakeupException that can
be thrown from commitSync.
{code}
org.apache.kafka.common.errors.WakeupException
at
org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.maybeTriggerWakeup
(ConsumerNetworkClient.java:404)
at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll
(ConsumerNetworkClient.java:245)
at org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll
(ConsumerNetworkClient.java:180)
at
org.apache.kafka.clients.consumer.internals.ConsumerCoordinator.commitOffsetsSync
(ConsumerCoordinator.java:499)
at org.apache.kafka.clients.consumer.KafkaConsumer.commitSync
(KafkaConsumer.java:1104)
at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommitSync
(WorkerSinkTask.java:245)
at org.apache.kafka.connect.runtime.WorkerSinkTask.doCommit
(WorkerSinkTask.java:264)
at org.apache.kafka.connect.runtime.WorkerSinkTask.commitOffsets
(WorkerSinkTask.java:305)
at org.apache.kafka.connect.runtime.WorkerSinkTask.closePartitions
(WorkerSinkTask.java:435)
at org.apache.kafka.connect.runtime.WorkerSinkTask.execute
(WorkerSinkTask.java:147)
at org.apache.kafka.connect.runtime.WorkerTask.doRun (WorkerTask.java:140)
at org.apache.kafka.connect.runtime.WorkerTask.run (WorkerTask.java:175)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:617)
at java.lang.Thread.run (Thread.java:745)
{code}
I believe it should catch it and ignore it as that is what the poll method does
when isStopping is true
{code:java}
} catch (WakeupException we) {
log.trace("{} consumer woken up", id);
if (isStopping())
return;
if (shouldPause()) {
pauseAll();
} else if (!pausedForRedelivery) {
resumeAll();
}
}
{code}
But unsure, love some insight into this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KAFKA-4577) NPE in ControllerChannelManager.scala::addUpdateMetadataRequestForBrokers
[
https://issues.apache.org/jira/browse/KAFKA-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15818922#comment-15818922
]
Scott Reynolds commented on KAFKA-4577:
---
Nothing interesting was happening, obviously ISR change was happening but it
wasn't triggered by a human.
Had this happen again yesterday.
It is unclear to me what is set to null and how it got to that state for this:
{code:java}
controller.deleteTopicManager.partitionsToBeDeleted.isEmpty
{code}
> NPE in ControllerChannelManager.scala::addUpdateMetadataRequestForBrokers
> --
>
> Key: KAFKA-4577
> URL: https://issues.apache.org/jira/browse/KAFKA-4577
> Project: Kafka
> Issue Type: Bug
>Affects Versions: 0.10.1.0
>Reporter: Scott Reynolds
>
> Seems as if either deleteTopicManager or deleteTopicManager.
> partitionsToBeDeleted wasn't set ?
> {code}
> java.lang.NullPointerException
> at
> kafka.controller.ControllerBrokerRequestBatch.addUpdateMetadataRequestForBrokers
> (ControllerChannelManager.scala:331)
> at kafka.controller.KafkaController.sendUpdateMetadataRequest
> (KafkaController.scala:1023)
> at
> kafka.controller.IsrChangeNotificationListener.kafka$controller$IsrChangeNotificationListener$$processUpdateNotifications
> (KafkaController.scala:1371)
> at
> kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply$mcV$sp
> (KafkaController.scala:1358)
> at
> kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply
> (KafkaController.scala:1351)
> at
> kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply
> (KafkaController.scala:1351)
> at kafka.utils.CoreUtils$.inLock (CoreUtils.scala:234)
> at kafka.controller.IsrChangeNotificationListener.handleChildChange
> (KafkaController.scala:1351)
> at org.I0Itec.zkclient.ZkClient$10.run (ZkClient.java:843)
> at org.I0Itec.zkclient.ZkEventThread.run (ZkEventThread.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KAFKA-4577) NPE in ControllerChannelManager.scala::addUpdateMetadataRequestForBrokers
Scott Reynolds created KAFKA-4577:
-
Summary: NPE in
ControllerChannelManager.scala::addUpdateMetadataRequestForBrokers
Key: KAFKA-4577
URL: https://issues.apache.org/jira/browse/KAFKA-4577
Project: Kafka
Issue Type: Bug
Affects Versions: 0.10.1.0
Reporter: Scott Reynolds
Seems as if either deleteTopicManager or deleteTopicManager.
partitionsToBeDeleted wasn't set ?
{code}
java.lang.NullPointerException
at
kafka.controller.ControllerBrokerRequestBatch.addUpdateMetadataRequestForBrokers
(ControllerChannelManager.scala:331)
at kafka.controller.KafkaController.sendUpdateMetadataRequest
(KafkaController.scala:1023)
at
kafka.controller.IsrChangeNotificationListener.kafka$controller$IsrChangeNotificationListener$$processUpdateNotifications
(KafkaController.scala:1371)
at
kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply$mcV$sp
(KafkaController.scala:1358)
at
kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply
(KafkaController.scala:1351)
at
kafka.controller.IsrChangeNotificationListener$$anonfun$handleChildChange$1.apply
(KafkaController.scala:1351)
at kafka.utils.CoreUtils$.inLock (CoreUtils.scala:234)
at kafka.controller.IsrChangeNotificationListener.handleChildChange
(KafkaController.scala:1351)
at org.I0Itec.zkclient.ZkClient$10.run (ZkClient.java:843)
at org.I0Itec.zkclient.ZkEventThread.run (ZkEventThread.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KAFKA-3413) Load Error Message should be a Warning
Scott Reynolds created KAFKA-3413: - Summary: Load Error Message should be a Warning Key: KAFKA-3413 URL: https://issues.apache.org/jira/browse/KAFKA-3413 Project: Kafka Issue Type: Improvement Components: consumer, offset manager Affects Versions: 0.9.0.1, 0.9.0.0 Reporter: Scott Reynolds Assignee: Neha Narkhede There is a Error message from AbstractReplicaFetcherThread that isn't really an error. Each implementation of this thread can logs out when an error or fatal error occurs. ReplicaFetcherThread, has both warn, error and fatal in the handleOffsetOutOfRange method. ConsumerFetcherThread seems to reset itself without logging out an error. Seems that the Reset message isn't shouldn't be an error level as it doesn't indicate any real error. This patch makes it a warning: https://github.com/apache/kafka/compare/trunk...SupermanScott:offset-reset-to-warn?diff=split=offset-reset-to-warn -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (KAFKA-3413) Load Error Message should be a Warning
[
https://issues.apache.org/jira/browse/KAFKA-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15198055#comment-15198055
]
Scott Reynolds edited comment on KAFKA-3413 at 3/16/16 8:11 PM:
{quote}This is an error due to the severe implications - on a replica, this
will cause a re-replication of an entire partition. Sysadmins will want to know
that their network is about to get really really busy, so this is logged at a
level where they are likely to catch it.{quote}
hmm ok. We do not get it frequently only when we are replacing and reassigning
topics.
Just it isn't an Error. There is nothing wrong.
{quote}a level where they are likely to catch it.{quote}
hmm maybe. Feels bad though doesn't.
In general, my team sets off pages on all Errors but we can adjust that if it
is just us facing this. Just smells a bit.
was (Author: scottreynolds):
>This is an error due to the severe implications - on a replica, this will
>cause a re-replication of an entire partition. Sysadmins will want to know
>that their network is about to get really really busy, so this is logged at a
>level where they are likely to catch it.
hmm ok. We do not get it frequently only when we are replacing and reassigning
topics.
Just it isn't an Error. There is nothing wrong.
>a level where they are likely to catch it.
hmm maybe. Feels bad though doesn't.
In general, my team sets off pages on all Errors but we can adjust that if it
is just us facing this. Just smells a bit.
> Load Error Message should be a Warning
> --
>
> Key: KAFKA-3413
> URL: https://issues.apache.org/jira/browse/KAFKA-3413
> Project: Kafka
> Issue Type: Improvement
> Components: consumer, offset manager
>Affects Versions: 0.9.0.0, 0.9.0.1
>Reporter: Scott Reynolds
>Assignee: Neha Narkhede
>
> There is a Error message from AbstractReplicaFetcherThread that isn't really
> an error.
> Each implementation
> of this thread can logs out when an error or fatal error occurs.
> ReplicaFetcherThread, has both warn, error and fatal in the
> handleOffsetOutOfRange method.
> ConsumerFetcherThread seems to reset itself without logging out an error.
> Seems that the Reset message isn't shouldn't be an error level as it
> doesn't indicate any real error.
> This patch makes it a warning:
> https://github.com/apache/kafka/compare/trunk...SupermanScott:offset-reset-to-warn?diff=split=offset-reset-to-warn
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KAFKA-3413) Load Error Message should be a Warning
[ https://issues.apache.org/jira/browse/KAFKA-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15198055#comment-15198055 ] Scott Reynolds commented on KAFKA-3413: --- >This is an error due to the severe implications - on a replica, this will >cause a re-replication of an entire partition. Sysadmins will want to know >that their network is about to get really really busy, so this is logged at a >level where they are likely to catch it. hmm ok. We do not get it frequently only when we are replacing and reassigning topics. Just it isn't an Error. There is nothing wrong. >a level where they are likely to catch it. hmm maybe. Feels bad though doesn't. In general, my team sets off pages on all Errors but we can adjust that if it is just us facing this. Just smells a bit. > Load Error Message should be a Warning > -- > > Key: KAFKA-3413 > URL: https://issues.apache.org/jira/browse/KAFKA-3413 > Project: Kafka > Issue Type: Improvement > Components: consumer, offset manager >Affects Versions: 0.9.0.0, 0.9.0.1 >Reporter: Scott Reynolds >Assignee: Neha Narkhede > > There is a Error message from AbstractReplicaFetcherThread that isn't really > an error. > Each implementation > of this thread can logs out when an error or fatal error occurs. > ReplicaFetcherThread, has both warn, error and fatal in the > handleOffsetOutOfRange method. > ConsumerFetcherThread seems to reset itself without logging out an error. > Seems that the Reset message isn't shouldn't be an error level as it > doesn't indicate any real error. > This patch makes it a warning: > https://github.com/apache/kafka/compare/trunk...SupermanScott:offset-reset-to-warn?diff=split=offset-reset-to-warn -- This message was sent by Atlassian JIRA (v6.3.4#6332)
