Hi, Can anyone give me an example? Or the props settings ? I am using the
latest version of Kafka.
Appreciate!
Sent from my iPhone
On 2013-10-05, at 15:05, Jiang Jacky wrote:
> Hi, I tried to setup the host.name in servier.properties, it doesn't work.
> I believe it is the network security is
Kafka is designed to have of the order of few thousands of partitions
roughly less than 10,000. And the main bottleneck is zookeeper. A better
way to design such a system is to have fewer partitions and use keyed
messages to distribute the data over a fixed set of partitions.
Thanks,
Neha
On Oct 5
Does the
leader just wait for the followers in the ISR to consume?
That's right. Until that is done, the producer does not get an ack back. It
has an option of retrying if the previous request times out or fails.
A separate question, can the request.required.acks be set to a higher
positive integ
On Sun, Oct 6, 2013 at 4:08 AM, Neha Narkhede wrote:
> Does the
> leader just wait for the followers in the ISR to consume?
>
> That's right. Until that is done, the producer does not get an ack back. It
> has an option of retrying if the previous request times out or fails.
>
>
Ok, so if I initia
Ok, so if I initiate a controlled shutdown, in which all partitions that a
shutting down broker is leader of get transferred to another broker, why
can't part of that controlled transfer of leadership include ISR
synchronization, such that no data is lost? Is there a fundamental reason
why that is
Thanks a lot Neha!
Actually, using keyed messages(with Simple Consumers) was the approach we
took. But it seems we can't map each user to a new partition due to
Zookeeper limitations. Rather, we will have to map a "group" of users on
one partition. Then we can't fetch the messages for only one use
What you are discovering is that Kafka is a message broker, not a database.
On Sun, Oct 6, 2013 at 5:34 PM, Ravindranath Akila <
ravindranathak...@gmail.com> wrote:
> Thanks a lot Neha!
>
> Actually, using keyed messages(with Simple Consumers) was the approach we
> took. But it seems we can't ma
Actually, we need a broker. But a more stateful one. Hence the decision to
use TTL on hbase.
On 7 Oct 2013 08:38, "Benjamin Black" wrote:
> What you are discovering is that Kafka is a message broker, not a database.
>
>
> On Sun, Oct 6, 2013 at 5:34 PM, Ravindranath Akila <
> ravindranathak...@gm
Ha ha, yes, exactly, you need a database. Kafka is a wonderful tool, but
not the right one for a job like that.
On Sun, Oct 6, 2013 at 7:03 PM, Ravindranath Akila <
ravindranathak...@gmail.com> wrote:
> Actually, we need a broker. But a more stateful one. Hence the decision to
> use TTL on hbase
Thanks Neha for continued insight
What you describe as a possible solution is what I was thinking (although I
wasn't as concerned as maybe I should be with the added delay of the new
leader delaying processing new requests while it finishes consuming from
the old leader, and communicates back
Seems the default for this is no 1
Online doc shows 1500
Just curious, why was this value updated?
Jason
11 matches
Mail list logo
