Hi Ryanne,
I also worked around it, but would rather not have needed to. So, I'm in the
position of creating a small KIP that I personally don't need to use right now.
But, I do have a PR and it's really simple, so I reckon it's a no-brainer to
enhance the framework in this small way so future conn
> That could be a defect in the implementation
That's what I am thinking. I don't think there is anything in the interface
or documentation that would imply that stop() could be called multiple
times, so I wouldn't expect any code to break if you fixed this behavior.
Quite the contrary -- I think
Hi Vahid,
Thanks for taking a look at this KIP.
- The KIP is proposing a new interface because the existing "stop()" interface
isn't called at the end of the SourceTask's existence. It's a signal to the
task to stop, rather than a signal that it has actually stopped. Essentially, if
the task has r
Hi Andrew,
Thanks for the KIP. I'm not too familiar with the internals of KC so I hope
you can clarify a couple of things:
- It seems the KIP is proposing a new interface because the existing
"stop()" interface doesn't fully perform what it should ideally be doing.
Is that a fair stateme
Ah, I'm sorta wrong -- in the current implementation, restartTask()
stops the task and starts a *new* task instance with the same task ID.
(I'm not certain that is clear from the documentation or interfaces,
or if that may change in the future.)
Ryanne
On Thu, Jan 24, 2019 at 10:25 AM Ryanne Dola
I've now added a diagram to illustrate the states of a SourceTask. The KIP is
essentially trying to give a clear signal to SourceTask when all work has
stopped. In particular, if a SourceTask has a session to the source system that
it uses in poll() and commit(), it now has a safe way to release
Andrew, I believe the task can be started again with start() during the
stopping and stopped states in your diagram.
Ryanne
On Thu, Jan 24, 2019, 10:20 AM Andrew Schofield I've now added a diagram to illustrate the states of a SourceTask. The KIP
> is essentially trying to give a clear signal to
Ryanne,
Thanks for your comments. I think my overarching point is that the various
states of a SourceTask and the transitions between them seem a bit loose and
that makes it difficult to figure out when the resources held by a SourceTask
can be safely released. Your "I can't tell from the docume
On 2019/01/18 18:02:24, Andrew Schofield wrote:
> Hi,> >
> I’ve created a new KIP to enhance the SourceTask interface in Kafka
Connect.> >
> >
>
https://cwiki.apache.org/confluence/display/KAFKA/KIP-419:+Safely+notify+Kafka+Connect+SourceTask+is+stopped>
>
> >
> Comments welcome.> >
> >
> Andrew S
Andrew, do we know whether the SourceTask may be start()ed again? If this
is the last call to a SourceTask I suggest we call it close(). I can't tell
from the documentation.
Also, do we need this if a SourceTask can keep track of whether it was
start()ed since the last stop()?
Ryanne
On Fri, Ja
Hi,
I’ve created a new KIP to enhance the SourceTask interface in Kafka Connect.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-419:+Safely+notify+Kafka+Connect+SourceTask+is+stopped
Comments welcome.
Andrew Schofield
IBM Event Streams
11 matches
Mail list logo
