Please vote!
Hope for your votes
permissions again.
Username: steff1193
Kind regards, Per Steffensen
mmit" that lies in its
JavaDoc, and that essentially cannot be used for anything, except for
making you confused. You know nothing about the state when it is called.
But as long as you do not oppose the proposed solution, we probably
should not spend too much time arguing back and forth about opinions.
Ryanne
Regards, and thanks for participating in the discussion
Per Steffensen
On 17/10/2018 18.17, Ryanne Dolan wrote:
> this does not guarantee that the
> offsets of R have been written/flushed at the next commit() call
True, but does it matter? So long as you can guarantee the records are
delivered to the downstream Kafka cluster, it shouldn't matter if they
have been
On 17/10/2018 16.43, Ryanne Dolan wrote:
I see, thanks.
On the other hand, the commitRecord() callback provides the functionality
you require in this case. In commitRecord() your SourceTask can track the
offsets of records that have been ack'd by the producer client, and then in
commit() you can
P. This way we also have
at least two persons who really understands what this is about. Some
times you only really understand what something is about, when you are
forced to write about it (at least that is my excuse ).
Regards, Per Steffensen
On 16/10/2018 05.57, Konstantine Karantasi
() is invoked by the framework. Is
that not the case?
Ryanne
On Wed, Oct 10, 2018 at 8:50 AM Per Steffensen <mailto:perst...@gmail.com>> wrote:
Please help make the proposed changes in KIP-381 become reality.
Please
comment.
KIP:
https://cwiki.apache.org/conflue
Please help make the proposed changes in KIP-381 become reality. Please
comment.
KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-381%3A+Connect%3A+Tell+about+records+that+had+their+offsets+flushed+in+callback
JIRA: https://issues.apache.org/jira/browse/KAFKA-5716
PR: https://githu
Per Steffensen created KAFKA-6505:
-
Summary: Add simple raw "offset-commit-failures", "offset-commits"
and "offset-commit-successes" count metric
Key: KAFKA-6505
URL: https://issue
Per Steffensen created KAFKA-6504:
-
Summary: Connect: Some per-task-metrics not working
Key: KAFKA-6504
URL: https://issues.apache.org/jira/browse/KAFKA-6504
Project: Kafka
Issue Type: Bug
Per Steffensen created KAFKA-6503:
-
Summary: Connect: Plugin scan is very slow
Key: KAFKA-6503
URL: https://issues.apache.org/jira/browse/KAFKA-6503
Project: Kafka
Issue Type: Improvement
Per Steffensen created KAFKA-5716:
-
Summary: Connect: When SourceTask.commit it is possible not
everthing from SourceTask.poll has been sent
Key: KAFKA-5716
URL: https://issues.apache.org/jira/browse/KAFKA-5716
Well I guess there is one: https://github.com/dhanuka84/kafka-connect-tcp
Maybe you can use or build on top of that.
On 05/07/17 05:45, Gwen Shapira wrote:
I don't remember seeing one. There is no reason not to write one (let us
know if you do, so we can put it on the connector hub!).
Few thing
Per Steffensen created KAFKA-5505:
-
Summary: Connect: Do not restart connector and existing tasks on
task-set change
Key: KAFKA-5505
URL: https://issues.apache.org/jira/browse/KAFKA-5505
Project
Thanks a lot for responding, Randall! See my comments below.
Regards, Per Steffensen
On 22/05/17 22:36, Randall Hauch wrote:
You're not doing anything wrong, but I suspect you're requesting task
reconfiguration more frequently than was originally envisioned, which
means that t
the SourceConnector,
just because it has a changed task-config-set
Or am I doing something wrong in my SourceConnector? Are there a
different way that I should maintain a dynamic set of tasks?
Thanks!!!
Regards, Per Steffensen
17 matches
Mail list logo
