[
https://issues.apache.org/jira/browse/KAFKA-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15332159#comment-15332159
]
Ewen Cheslack-Postava edited comment on KAFKA-2925 at 6/15/16 5:38 PM:
-----------------------------------------------------------------------
[~hachikuji] Can you remember if we've gotten the start()/stop() behavior into
better shape now such that this isn't possible? I remember a few patches around
that ordering -- specifically, I think we may be managing this at the framework
level such that the stop() won't be invoked until start() is both invoked and
completed.
was (Author: ewencp):
[~hachikuji] Can you remember if we've gotten the start()/stop() behavior into
better shape now such that this isn't possible? I remember a few patches around
that ordering.
> NullPointerException if FileStreamSinkTask is stopped before initialization
> finishes
> ------------------------------------------------------------------------------------
>
> Key: KAFKA-2925
> URL: https://issues.apache.org/jira/browse/KAFKA-2925
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Affects Versions: 0.9.0.0
> Reporter: Ewen Cheslack-Postava
> Assignee: Ewen Cheslack-Postava
> Priority: Minor
>
> If a FileStreamSinkTask is stopped too quickly after a distributed herder
> rebalances work, it can result in cleanup happening without start() ever
> being called:
> {quote}
> Sink task org.apache.kafka.connect.runtime.WorkerSinkTask@f9ac651 was stopped
> before completing join group. Task initialization and start is being skipped
> (org.apache.kafka.connect.runtime.WorkerSinkTask:150)
> {quote}
> This is actually a bit weird since stop() is still called so resources
> allocated in the constructor can be cleaned up, but possibly unexpected that
> stop() will be called without start() ever being called.
> Because the code in FileStreamSinkTask's stop() method assumes start() has
> been called, it can result in a NullPointerException because it assumes the
> PrintStream is already initialized.
> The easy fix is to check for nulls before closing. However, we should
> probably also consider whether the current possibly sequence of events is
> confusing and if we shoud not invoke stop() and make it clear in the SInkTask
> interface that you should only initialize stuff in the constructor that won't
> need any manual cleanup later.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
