Dmitri,
Snappy tends to be much faster than gzip with a slightly lower compression
ratio. Not sure how stable it is though.
Thanks,
Jun
On Fri, Nov 30, 2012 at 1:33 PM, Dmitri Priimak <
prii...@highwire.stanford.edu> wrote:
> Well, the files that I am sending are themselves not compressed, but
Well, the files that I am sending are themselves not compressed, but I do use
gzip compression when
sending data. kafka client is configured with option
compression.codec=1
which implies gzip compression. Setting that value to 2 means "Snappy
compression". What compression
would you recomme
It seems I often call api code not under the javaapi package as well
(primarily in our container code which embeds a KafkaServer instance), but
also in some client code. Thus, it seems the javaapi is not meant to be a
single-point of entry, no?
Jason
On Thu, Nov 29, 2012 at 4:31 PM, Jay Kreps w
Well, it does not look like I can reproduce it anymore. While I was able to
consistently crash it
yesterday, today kafka broker runs without any problems.
--
Dmitri Priimak
On 11/29/2012 02:10 PM, Dmitri Priimak wrote:
> On 11/29/2012 02:06 PM, Neha Narkhede wrote:
>> That just meant that we cou
When a broker shuts down due to hardware failure or otherwise, the
leader/master replica removes that broker from the list of in sync
replicas for that partition.
This is important if you have producers that are using
producer.num.acks=-1 that requires the produce request to reach all in
sync repli
Yes, I'm referring to increase the # of replicas (new broker id)
Thanks, i'll look into that.
On Fri, Nov 30, 2012 at 2:59 PM, Joel Koshy wrote:
> Node replacement does not require anything special - i.e., as long as it
> has the same broker id, just bringing it back into the cluster would
> s
Node replacement does not require anything special - i.e., as long as it
has the same broker id, just bringing it back into the cluster would
suffice, and it should catch up on partitions that are assigned to it. Not
sure what you mean by "increase a replica" - or you mean increase the
number of re
Right now, no - clients can of course send/store only encrypted messages to
help mitigate that limitation.
On Fri, Nov 30, 2012 at 11:28 AM, Jamie Wang wrote:
> Hi,
>
> Is there any security enforcement built into Kafka broker that the system
> can have control who can send and consume messag
Hi,
Is there any security enforcement built into Kafka broker that the system can
have control who can send and consume messages? I understand kafka is most
likely installed/deployed behind firewalls. But even with that, someone with
knowledge of topic can potentially sabotage or sniffing in