Re: Fwd: Unexpected end of ZLIB input stream

2012-11-30 Thread Jun Rao
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

Re: Fwd: Unexpected end of ZLIB input stream

2012-11-30 Thread Dmitri Priimak
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

Re: Java API documentation

2012-11-30 Thread Jason Rosenberg
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

Re: Unexpected end of ZLIB input stream

2012-11-30 Thread Dmitri Priimak
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

Re: steps to mitigate hardware failure in a replicate

2012-11-30 Thread Neha Narkhede
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

Re: steps to mitigate hardware failure in a replicate

2012-11-30 Thread S Ahmed
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

Re: steps to mitigate hardware failure in a replicate

2012-11-30 Thread Joel Koshy
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

Re: Security measure

2012-11-30 Thread Joel Koshy
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

Security measure

2012-11-30 Thread Jamie Wang
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