https://issues.apache.org/jira/browse/KAFKA-3829
Thanks again Gwen.
In connect-distributed.properties I have values like:
session.timeout.ms=12
But at startup I get warnings like:
The configuration session.timeout.ms = 12 was supplied but isn't a
> known config.
I'm getting these warnings for most settings (eg, internal.key.converter,
key.converter,
Thanks Gwen, that was exactly my problem. I had changed the value of the
group.id to the same value as the config name. But rereading the docs I did
not find any hint of that this would occur. Did I miss it somewhere?
-barry
tocol for each consumer
> and also check that you don't have extra consumers in the group, perhaps
> because the group id is reused / common.
>
> Hope this helps,
>
> -Dana
> On Jun 10, 2016 4:24 AM, "Barry Kaplan" <bkap...@memelet.com> wrote:
>
> I delete the group using kafka-consumer-groups.sh --delete and still I get
> the error.
>
I delete the group using kafka-consumer-groups.sh --delete and still I get
the error.
I didn't really expect this to help, but still, I tried deleting /all/
topics and recreating them. But still my connect app will no longer run due
to this error.
Does this error even have anything to do with persisted state, or is the
broker complaining about live client connections?
h more likely.
>
> Thanks
>
> Tom Crayford, Heroku Kafka
>
> On Fri, Jun 10, 2016 at 7:02 AM, Barry Kaplan <bkap...@memelet.com> wrote:
>
> > If too much heap cause problems, would it make sense to run multiple
> > brokers on a box with lots memory? For example, an
I am getting this error:
Attempt to join group connect-elasticsearch-indexer failed due to: The
> group member's supported protocols are incompatible with those of existing
> members.
This is a single kafka-connect process consuming two topics. The brokers
have never changed, and the version of
If too much heap cause problems, would it make sense to run multiple
brokers on a box with lots memory? For example, an EC2 D2 instance types
has way way more ram than kafka could ever use - -but it has fast connected
disks.
Would running a broker per disk make sense in this case?
-barry
Hmm, well CPU is pretty much zero. Heap is barely used. I even made the
task put method be a noop other than to log time-since-last call. No
change. With yourkit I see that ES has a thread that is sleeping, but it's
in a monitor thread pool and clearly not blocking kafka. Anyway, I even
removed
I am running a connect consumer that receives JSON records and indexes into
elasticsearch. The consumer is pushing out 300 messages/s into the a topic
with a single partition. The connect job is configured with 1 task. (This
is all for testing).
What I see is that push is called about every 10s
11 matches
Mail list logo
