Re: How to chose the size of a Kafka broker

[Stephen Powis]

I can't really answer your question, but you don't mention your network
layout/hardware.  May want to add that as a data point in your decision
(wouldn't want to overrun your network device(s) on the brokers).


On Wed, Jan 13, 2016 at 7:09 PM, Vladoiu Catalin 
wrote:

> Hi guys,
>
> I've run into a long conversation with my colleagues when we discussed the
> size of the Brokers for our new Kafka cluster and we still haven't reached
> a final conclusion.
>
> Our main concern is the size of the requests 10-20MB per request (producer
> will send big requests), maybe more and we estimate that we will have 4-5TB
> per day.
>
> Our debate is between:
> 1. Having a smaller cluster(not so many brokers) but big config, something
> like this:
> Disk: 11 x 4TB, CPU: 48 Core, RAM: 252 GB. We chose this configuration
> because our Hadoop cluster has that config and can easily handle that
> amount of data.
> 2. Having a bigger number of brokers but smaller broker config.
>
> I was hopping that somebody with more experience in using Kafka can advice
> on this.
>
> Thanks,
> Catalin
>

How to chose the size of a Kafka broker

[Vladoiu Catalin]

Hi guys,

I've run into a long conversation with my colleagues when we discussed the
size of the Brokers for our new Kafka cluster and we still haven't reached
a final conclusion.

Our main concern is the size of the requests 10-20MB per request (producer
will send big requests), maybe more and we estimate that we will have 4-5TB
per day.

Our debate is between:
1. Having a smaller cluster(not so many brokers) but big config, something
like this:
Disk: 11 x 4TB, CPU: 48 Core, RAM: 252 GB. We chose this configuration
because our Hadoop cluster has that config and can easily handle that
amount of data.
2. Having a bigger number of brokers but smaller broker config.

I was hopping that somebody with more experience in using Kafka can advice
on this.

Thanks,
Catalin

deleteConfig not working in Kafka 0.9

[Mhaskar, Tushar]

Hi All,

I am facing issues deleting config for a topic in Kafka 0.9. Anybody facing the 
same issue?


./kafka-topics.sh —zookeeper XX.XX.XX.XXX:2181 --alter --topic testTopic 
--deleteConfig retention.ms


Exception in thread "main" joptsimple.UnrecognizedOptionException: 
'deleteConfig' is not a recognized option

at joptsimple.OptionException.unrecognizedOption(OptionException.java:93)

at joptsimple.OptionParser.handleLongOptionToken(OptionParser.java:402)

at joptsimple.OptionParserState$2.handleArgument(OptionParserState.java:55)

at joptsimple.OptionParser.parse(OptionParser.java:392)

at kafka.admin.TopicCommand$TopicCommandOptions.(TopicCommand.scala:311)

at kafka.admin.TopicCommand$.main(TopicCommand.scala:41)

at kafka.admin.TopicCommand.main(TopicCommand.scala)

Thanks,
Tushar

RE: 409 Conflict

[Heath Ivie]

Hi Ewen,

When I follow the exact sequence with the curl commands below I get this error.

It seems to register fine, because I get the baseuri and the instance id.

This is the error that I get when I try to read from the topic:
{
  "error_code": 40901,
  "message": "Consumer cannot subscribe the the specified target because it has 
already subscribed to other topics."
}

I am making sure that each time I try this I am using a new group, instance and 
topic so that it shouldn't be duplicated.

Could there be a conflict between this latest version and the previous, I just 
upgraded yesterday?

-Original Message-
From: Ewen Cheslack-Postava [mailto:e...@confluent.io] 
Sent: Tuesday, January 12, 2016 10:38 PM
To: users@kafka.apache.org
Subject: Re: 409 Conflict

Is the consumer registration failing, or the subsequent calls to read from the 
topic? From the error, it sounds like the latter -- a conflict during 
registration should generate a 40902 error.

Can you give more info about the sequence of requests that causes the error? 
The set of commands you gave looks ok at first glance, but since there's only 
one consumer, it shouldn't be possible for it to generate a
409 (conflict) error.

-Ewen

On Tue, Jan 12, 2016 at 4:06 PM, Heath Ivie  wrote:

> Additional Info:
>
> When I enter the curl commands from the 2.0 document, I get the same error:
> $ curl -X POST -H "Content-Type: application/vnd.kafka.json.v1+json"
>  --data '{"records":[{"value":{"foo":"bar"}}]}' "
> http://10.1.30.48:8082/topics/jsontest;
> $ curl -X POST -H "Content-Type: application/vnd.kafka.v1+json"  
> --data
> '{"name": "my_consumer_instance", "format": "json", "auto.offset.reset":
> "smallest"}'   http://10.1.30.48:8082/consumers/my_json_consumer
>  $ curl -X GET -H "Accept: application/vnd.kafka.json.v1+json"
> http://10.1.30.48:8082/consumers/my_json_consumer/instances/my_consume
> r_instance/topics/jsontest
>  $ curl -X DELETE
> http://10.1.30.48:8082/consumers/my_json_consumer/instances/my_consume
> r_instance
>
>
>
> http://docs.confluent.io/2.0.0/kafka-rest/docs/intro.html#produce-and-
> consume-json-messages
>
> -Original Message-
> From: Heath Ivie [mailto:hi...@autoanything.com]
> Sent: Tuesday, January 12, 2016 3:08 PM
> To: users@kafka.apache.org
> Subject: 409 Conflict
>
> Hi ,
>
> I am running into an issue where I cannot register new consumers.
>
> The server is consistently return error code 40901: "Consumer cannot 
> subscribe the the specified target because it has already subscribed 
> to other topics".
>
> I am using different groups, different topics and different names but 
> I cannot figure out what I am doing wrong.
>
> I am using the REST proxy for all of my communication.
>
> I am also letting Kafka select the instance name for me so that it is 
> unique.
>
> Can someone please point me in the right direction?
> Thanks
> Heath
>
>
> Warning: This e-mail may contain information proprietary to 
> AutoAnything Inc. and is intended only for the use of the intended 
> recipient(s). If the reader of this message is not the intended 
> recipient(s), you have received this message in error and any review, 
> dissemination, distribution or copying of this message is strictly 
> prohibited. If you have received this message in error, please notify 
> the sender immediately and delete all copies.
>



--
Thanks,
Ewen

RE: 409 Conflict

[Heath Ivie]

Update: I have completely uninstall kafka v10 and v17 and reinstalled and all 
is right with the world.

-Original Message-
From: Heath Ivie [mailto:hi...@autoanything.com] 
Sent: Wednesday, January 13, 2016 11:59 AM
To: users@kafka.apache.org
Subject: RE: 409 Conflict

Hi Ewen,

When I follow the exact sequence with the curl commands below I get this error.

It seems to register fine, because I get the baseuri and the instance id.

This is the error that I get when I try to read from the topic:
{
  "error_code": 40901,
  "message": "Consumer cannot subscribe the the specified target because it has 
already subscribed to other topics."
}

I am making sure that each time I try this I am using a new group, instance and 
topic so that it shouldn't be duplicated.

Could there be a conflict between this latest version and the previous, I just 
upgraded yesterday?

-Original Message-
From: Ewen Cheslack-Postava [mailto:e...@confluent.io]
Sent: Tuesday, January 12, 2016 10:38 PM
To: users@kafka.apache.org
Subject: Re: 409 Conflict

Is the consumer registration failing, or the subsequent calls to read from the 
topic? From the error, it sounds like the latter -- a conflict during 
registration should generate a 40902 error.

Can you give more info about the sequence of requests that causes the error? 
The set of commands you gave looks ok at first glance, but since there's only 
one consumer, it shouldn't be possible for it to generate a
409 (conflict) error.

-Ewen

On Tue, Jan 12, 2016 at 4:06 PM, Heath Ivie  wrote:

> Additional Info:
>
> When I enter the curl commands from the 2.0 document, I get the same error:
> $ curl -X POST -H "Content-Type: application/vnd.kafka.json.v1+json"
>  --data '{"records":[{"value":{"foo":"bar"}}]}' "
> http://10.1.30.48:8082/topics/jsontest;
> $ curl -X POST -H "Content-Type: application/vnd.kafka.v1+json"  
> --data
> '{"name": "my_consumer_instance", "format": "json", "auto.offset.reset":
> "smallest"}'   http://10.1.30.48:8082/consumers/my_json_consumer
>  $ curl -X GET -H "Accept: application/vnd.kafka.json.v1+json"
> http://10.1.30.48:8082/consumers/my_json_consumer/instances/my_consume
> r_instance/topics/jsontest
>  $ curl -X DELETE
> http://10.1.30.48:8082/consumers/my_json_consumer/instances/my_consume
> r_instance
>
>
>
> http://docs.confluent.io/2.0.0/kafka-rest/docs/intro.html#produce-and-
> consume-json-messages
>
> -Original Message-
> From: Heath Ivie [mailto:hi...@autoanything.com]
> Sent: Tuesday, January 12, 2016 3:08 PM
> To: users@kafka.apache.org
> Subject: 409 Conflict
>
> Hi ,
>
> I am running into an issue where I cannot register new consumers.
>
> The server is consistently return error code 40901: "Consumer cannot 
> subscribe the the specified target because it has already subscribed 
> to other topics".
>
> I am using different groups, different topics and different names but 
> I cannot figure out what I am doing wrong.
>
> I am using the REST proxy for all of my communication.
>
> I am also letting Kafka select the instance name for me so that it is 
> unique.
>
> Can someone please point me in the right direction?
> Thanks
> Heath
>
>
> Warning: This e-mail may contain information proprietary to 
> AutoAnything Inc. and is intended only for the use of the intended 
> recipient(s). If the reader of this message is not the intended 
> recipient(s), you have received this message in error and any review, 
> dissemination, distribution or copying of this message is strictly 
> prohibited. If you have received this message in error, please notify 
> the sender immediately and delete all copies.
>



--
Thanks,
Ewen

Re: 0.8.2 How do I suppress INFO Closing socket connection to

[Dillian Murphey]

Oh, great, I get it. Thank you.

On Mon, Jan 4, 2016 at 6:26 PM, tao xiao  wrote:

> You can bump the log level to warn for a particular class
>
> log4j.logger.kafka.network.Processor=WARN
>
> On Tue, 5 Jan 2016 at 08:33 Dillian Murphey 
> wrote:
>
> > Constant spam of this INFO on my log.
> >
> > [2016-01-05 00:31:15,887] INFO Closing socket connection to /10.9.255.67
> .
> > (kafka.network.Processor)
> > [2016-01-05 00:31:15,917] INFO Closing socket connection to /10.9.255.67
> .
> > (kafka.network.Proces
> >
> > Anyone know what I need to modify (assuming log4j.properties) to disable
> > this but still be informed of issues?
> >
> > Thank you!
> >
>

Kafka 0.9 client producer compatibility with Kafka 0.8.2 broker

[Rajiv Kurian]

We just upgraded one of our Kafka client producers from 0.8.2 to 0.9. Our
broker is still running 0.8.2. I knew that the new 0.9 consumer requires
the new broker and I was under the impression that the new producer would
still work with the old broker. However this doesn't seem to be the case.

I kept getting this error on my client:

 ERROR [roducer-network-thread | producer-5]
[s.o.a.k.c.producer.internals.Sender ] {}: Uncaught error in kafka producer
I/O thread:

org.apache.kafka.common.protocol.types.SchemaException: Error reading field
'throttle_time_ms': java.nio.BufferUnderflowException

at
org.apache.kafka.common.protocol.types.Schema.read(Schema.java:71)

at
org.apache.kafka.clients.NetworkClient.handleCompletedReceives(NetworkClient.java:464)

at
org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:279)

at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:216)

at
org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:128)

at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]


Is this a known problem. My 0.9 client jar is from Maven.


Thanks,

Rajiv

Re: Kafka 0.9 client producer compatibility with Kafka 0.8.2 broker

[Ismael Juma]

Hi Rajiv,

This is expected. Newer broker versions support older client versions, but
newer client versions don't support older broker versions.

Ismael

On Wed, Jan 13, 2016 at 10:54 PM, Rajiv Kurian  wrote:

> We just upgraded one of our Kafka client producers from 0.8.2 to 0.9. Our
> broker is still running 0.8.2. I knew that the new 0.9 consumer requires
> the new broker and I was under the impression that the new producer would
> still work with the old broker. However this doesn't seem to be the case.
>
> I kept getting this error on my client:
>
>  ERROR [roducer-network-thread | producer-5]
> [s.o.a.k.c.producer.internals.Sender ] {}: Uncaught error in kafka producer
> I/O thread:
>
> org.apache.kafka.common.protocol.types.SchemaException: Error reading field
> 'throttle_time_ms': java.nio.BufferUnderflowException
>
> at
> org.apache.kafka.common.protocol.types.Schema.read(Schema.java:71)
>
> at
>
> org.apache.kafka.clients.NetworkClient.handleCompletedReceives(NetworkClient.java:464)
>
> at
> org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:279)
>
> at
> org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:216)
>
> at
> org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:128)
>
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
>
>
> Is this a known problem. My 0.9 client jar is from Maven.
>
>
> Thanks,
>
> Rajiv
>

Brokers experience continuous ISR shrinks resulting in most partitions having only on broker in ISR

[Ravi Kiran Chiruvolu]

We have a kafka cluster with 22 nodes, which host  ~3700 topics and ~15000 
partitions.
We ran fine for a long time but, one fine day a bunch of brokers (around half 
of the cluster) started getting out of ISRs with the following messages in the 
leaders:A) 

[2016-01-12 19:01:19,363] INFO Partition [RADM_3600_7,0] on broker 18: 
Shrinking ISR for partition [RADM_3600_7,0] from 18,25 to 18 
(kafka.cluster.Partition)
[2016-01-12 19:01:19,367] INFO Partition [RADM_3600_7,0] on broker 18: Cached 
zkVersion [5] not equal to that in zookeeper, skip updating ISR 
(kafka.cluster.Partition)

B) Correspondingly, we had messages in Zookeeper Leader which looked like:
Tue Jan 12 19:01:19 2016: 2016-01-12 19:01:19,364 - INFO  [ProcessThread(sid:2 
cport:-1)::PrepRequestProcessor@627] - Got user-level KeeperException when 
processing sessionid:0x251a8968b80f32d type:setData cxid:0x882ade 
zxid:0x501b0a9d1 txntype:-1 reqpath:n/a Error 
Path:/brokers/topics/RADM_3600_7/partitions/0/state Error:KeeperErrorCode = 
BadVersion for /brokers/topics/RADM_3600_7/partitions/0/state


C) In the controller, we were getting messages like: 

[2016-01-12 17:50:15,908] INFO [PreferredReplicaPartitionLeaderSelector]: 
Current leader 25 for partition [RADM_3600_7,0] is not the preferred replica. 
Trigerring preferred replica leader election 
(kafka.controller.PreferredReplicaPartitionLeaderSelector)
[2016-01-12 17:50:15,908] WARN [Controller 17]: Partition [RADM_3600_7,0] 
failed to complete preferred replica leader election. Leader is 25 
(kafka.controller.KafkaController)
before the above shrinking in A) .
Around 70 - 80% of the partitions were operating with only one broker in the 
ISR.We had to clean the state - the data, the topics, everything to finally fix 
this.
Also, we have another deployment which mirrors this one and which has been 
running fine.

G'day,Chiru

New mirror maker unable to commit offset with inactive topic

[tao xiao]

Hi,

I found that the latest mirror maker with new consumer enabled was unable
to commit offset in time when mirroring a topic with very infrequent
messages.

I have a topic with a few of messages produced every half hour. I setup
mirror maker to mirror this topic with default config. I observed that
mirror maker didn't commit offset until the next messages came in even
though the default commit interval was set to 60 seconds.

I think this is due to a while loop in mirror maker before calling commit.
It basically calling the poll indefinitely until new messages come in and
then commit

https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/tools/MirrorMaker.scala#L527

Is there a way to get around this problem?

Re: Controlled shutdown not relinquishing leadership of all partitions

[Luke Steensen]

Yes, that was my intention and we have both of those configs turned on. For
some reason, however, the controlled shutdown wasn't transferring
leadership of all partitions, which caused the issues I described in my
initial email.


On Wed, Jan 13, 2016 at 12:05 AM, Ján Koščo <3k.stan...@gmail.com> wrote:

> Not sure, but should combination of auto.leader.rebalance.enable=true
> and controlled.shutdown.enable=true sort this out for you?
>
> 2016-01-13 1:13 GMT+01:00 Scott Reynolds :
>
> > we use 0.9.0.0 and it is working fine. Not all the features work and a
> few
> > things make a few assumptions about how zookeeper is used. But as a tool
> > for provisioning, expanding and failure recovery it is working fine so
> far.
> >
> > *knocks on wood*
> >
> > On Tue, Jan 12, 2016 at 4:08 PM, Luke Steensen <
> > luke.steen...@braintreepayments.com> wrote:
> >
> > > Ah, that's a good idea. Do you know if kafka-manager works with kafka
> 0.9
> > > by chance? That would be a nice improvement of the cli tools.
> > >
> > > Thanks,
> > > Luke
> > >
> > >
> > > On Tue, Jan 12, 2016 at 4:53 PM, Scott Reynolds 
> > > wrote:
> > >
> > > > Luke,
> > > >
> > > > We practice the same immutable pattern on AWS. To decommission a
> > broker,
> > > we
> > > > use partition reassignment first to move the partitions off of the
> node
> > > and
> > > > preferred leadership election. To do this with a web ui, so that you
> > can
> > > > handle it on lizard brain at 3 am, we have the Yahoo Kafka Manager
> > > running
> > > > on the broker hosts.
> > > >
> > > > https://github.com/yahoo/kafka-manager
> > > >
> > > > On Tue, Jan 12, 2016 at 2:50 PM, Luke Steensen <
> > > > luke.steen...@braintreepayments.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > We've run into a bit of a head-scratcher with a new kafka
> deployment
> > > and
> > > > > I'm curious if anyone has any ideas.
> > > > >
> > > > > A little bit of background: this deployment uses "immutable
> > > > infrastructure"
> > > > > on AWS, so instead of configuring the host in-place, we stop the
> > > broker,
> > > > > tear down the instance, and replace it wholesale. My understanding
> > was
> > > > that
> > > > > controlled shutdown combined with producer retries would allow this
> > > > > operation to be zero-downtime. Unfortunately, things aren't working
> > > quite
> > > > > as I expected.
> > > > >
> > > > > After poring over the logs, I pieced together to following chain of
> > > > events:
> > > > >
> > > > >1. our operations script stops the broker process and proceeds
> to
> > > > >terminate the instance
> > > > >2. our producer application detects the disconnect and requests
> > > > updated
> > > > >metadata from another node
> > > > >3. updated metadata is returned successfully, but the downed
> > broker
> > > is
> > > > >still listed as leader for a single partition of the given topic
> > > > >4. on the next produce request bound for that partition, the
> > > producer
> > > > >attempts to initiate a connection to the downed host
> > > > >5. because the instance has been terminated, the node is now in
> > the
> > > > >"connecting" state until the system-level tcp timeout expires
> (2-3
> > > > > minutes)
> > > > >6. during this time, all produce requests to the given partition
> > sit
> > > > in
> > > > >the record accumulator until they expire and are immediately
> > failed
> > > > > without
> > > > >retries
> > > > >7. the tcp timeout finally fires, the node is recognized as
> > > > >disconnected, more metadata is fetched, and things return to
> > sanity
> > > > >
> > > > > I was able to work around the issue by waiting 60 seconds between
> > > > shutting
> > > > > down the broker and terminating that instance, as well as raising
> > > > > request.timeout.ms on the producer to 2x our zookeeper timeout.
> This
> > > > gives
> > > > > the broker a much quicker "connection refused" error instead of the
> > > > > connection timeout and seems to give enough time for normal failure
> > > > > detection and leader election to kick in before requests are timed
> > out.
> > > > >
> > > > > So two questions really: (1) are there any known issues that would
> > > cause
> > > > a
> > > > > controlled shutdown to fail to release leadership of all
> partitions?
> > > and
> > > > > (2) should the producer be timing out connection attempts more
> > > > proactively?
> > > > >
> > > > > Thanks,
> > > > > Luke
> > > > >
> > > >
> > >
> >
>

Re: fallout from upgrading to the new Kafka producers

[Rajiv Kurian]

Thanks!

On Wed, Jan 13, 2016 at 9:06 AM, Guozhang Wang  wrote:

> Rajiv,
>
> 0.9.0 Java producers have a few minor bug fixes from 0.8.2, and add another
> API function "flush()": https://issues.apache.org/jira/browse/KAFKA-1865
>
> You can look through its changes by just searching "producer" in the
> release notes:
>
> http://mirror.stjschools.org/public/apache/kafka/0.9.0.0/RELEASE_NOTES.html
>
>
> Guozhang
>
>
> On Tue, Jan 12, 2016 at 6:00 PM, Rajiv Kurian  wrote:
>
> > Thanks Guozhan. I have upgraded to 0.9.0 now. Are there are any other
> > producer changes to be aware of? My understanding is there were no big
> > producer changes made from 0.8.2 to 0.9.0.
> >
> > Thanks,
> > Rajiv
> >
> > On Mon, Jan 11, 2016 at 5:52 PM, Guozhang Wang 
> wrote:
> >
> > > Hi Rajiv,
> > >
> > > This warning could be ignored and is indeed done in 0.9.0, where we
> > > downgrade the logging level for it from WARN to DEBUG. So if you
> upgrade
> > to
> > > 0.9.0 Java producer you should not see this warning.
> > >
> > > A bit more context on the EOFException, a socket closure could result
> > this;
> > > and a server could actively close a socket under some cases, for
> example
> > 1)
> > > if it is idle for some time and server would decide to close it based
> on
> > > the idle management config, or 2) if producer use ack=0 and there is an
> > > error processing the request, so server just close the socket to
> "notify"
> > > the client, etc.
> > >
> > > Guozhang
> > >
> > >
> > >
> > >
> > > On Mon, Jan 11, 2016 at 1:08 PM, Rajiv Kurian 
> > wrote:
> > >
> > > > We have recently upgraded some of our applications to use the Kafka
> > 0.8.2
> > > > Java producers from the old Java wrappers over Scala producers.
> > > >
> > > > We've noticed these log messages on our application since the
> upgrade:
> > > >
> > > > 2016-01-11T20:56:43.023Z WARN  [roducer-network-thread | producer-2]
> > > > [s.o.a.kafka.common.network.Selector ] {}: Error in I/O with
> > > > my_kafka_host/some_ip
> > > >
> > > > java.io.EOFException: null
> > > >
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.kafka.common.network.NetworkReceive.readFrom(NetworkReceive.java:62)
> > > > ~[kafka_2.10-0.8.2.2.jar:na]
> > > >
> > > > at
> > > org.apache.kafka.common.network.Selector.poll(Selector.java:248)
> > > > ~[kafka_2.10-0.8.2.2.jar:na]
> > > >
> > > > at
> > > > org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:192)
> > > > [kafka_2.10-0.8.2.2jar:na]
> > > >
> > > > at
> > > >
> org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:191)
> > > > [kafka_2.10-0.8.2.2.jar:na]
> > > >
> > > > at
> > > >
> org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:122)
> > > > [kafka_2.10-0.8.2.2.jar:na]
> > > >
> > > > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> > > >
> > > > They don't occur too often and may be harmless but it is pretty
> > alarming
> > > to
> > > > see these. It happens with all the brokers we connect to so it
> doesn't
> > > seem
> > > > like a problem with a single broker. Our producer config looks a bit
> > like
> > > > this:
> > > >
> > > > final Properties config = new Properties();
> > > >
> > > >  config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,
> > > > OUR_KAFKA_CONNECT_STRING);
> > > >
> > > >  config.put(ProducerConfig.BLOCK_ON_BUFFER_FULL_CONFIG, false);  //
> non
> > > > blocking
> > > >
> > > >  config.put(ProducerConfig.BUFFER_MEMORY_CONFIG,  10 * 1024 * 1024);
> > //
> > > 10
> > > > MB
> > > >
> > > >  config.put(ProducerConfig.BATCH_SIZE_CONFIG,  16384);  // 16 KB
> > > >
> > > >  config.put(ProducerConfig.LINGER_MS_CONFIG, 50);  // 50 ms
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Rajiv
> > > >
> > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>
>
>
> --
> -- Guozhang
>

Re: fallout from upgrading to the new Kafka producers

[Guozhang Wang]

Rajiv,

0.9.0 Java producers have a few minor bug fixes from 0.8.2, and add another
API function "flush()": https://issues.apache.org/jira/browse/KAFKA-1865

You can look through its changes by just searching "producer" in the
release notes:

http://mirror.stjschools.org/public/apache/kafka/0.9.0.0/RELEASE_NOTES.html


Guozhang


On Tue, Jan 12, 2016 at 6:00 PM, Rajiv Kurian  wrote:

> Thanks Guozhan. I have upgraded to 0.9.0 now. Are there are any other
> producer changes to be aware of? My understanding is there were no big
> producer changes made from 0.8.2 to 0.9.0.
>
> Thanks,
> Rajiv
>
> On Mon, Jan 11, 2016 at 5:52 PM, Guozhang Wang  wrote:
>
> > Hi Rajiv,
> >
> > This warning could be ignored and is indeed done in 0.9.0, where we
> > downgrade the logging level for it from WARN to DEBUG. So if you upgrade
> to
> > 0.9.0 Java producer you should not see this warning.
> >
> > A bit more context on the EOFException, a socket closure could result
> this;
> > and a server could actively close a socket under some cases, for example
> 1)
> > if it is idle for some time and server would decide to close it based on
> > the idle management config, or 2) if producer use ack=0 and there is an
> > error processing the request, so server just close the socket to "notify"
> > the client, etc.
> >
> > Guozhang
> >
> >
> >
> >
> > On Mon, Jan 11, 2016 at 1:08 PM, Rajiv Kurian 
> wrote:
> >
> > > We have recently upgraded some of our applications to use the Kafka
> 0.8.2
> > > Java producers from the old Java wrappers over Scala producers.
> > >
> > > We've noticed these log messages on our application since the upgrade:
> > >
> > > 2016-01-11T20:56:43.023Z WARN  [roducer-network-thread | producer-2]
> > > [s.o.a.kafka.common.network.Selector ] {}: Error in I/O with
> > > my_kafka_host/some_ip
> > >
> > > java.io.EOFException: null
> > >
> > > at
> > >
> > >
> >
> org.apache.kafka.common.network.NetworkReceive.readFrom(NetworkReceive.java:62)
> > > ~[kafka_2.10-0.8.2.2.jar:na]
> > >
> > > at
> > org.apache.kafka.common.network.Selector.poll(Selector.java:248)
> > > ~[kafka_2.10-0.8.2.2.jar:na]
> > >
> > > at
> > > org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:192)
> > > [kafka_2.10-0.8.2.2jar:na]
> > >
> > > at
> > > org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:191)
> > > [kafka_2.10-0.8.2.2.jar:na]
> > >
> > > at
> > > org.apache.kafka.clients.producer.internals.Sender.run(Sender.java:122)
> > > [kafka_2.10-0.8.2.2.jar:na]
> > >
> > > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66]
> > >
> > > They don't occur too often and may be harmless but it is pretty
> alarming
> > to
> > > see these. It happens with all the brokers we connect to so it doesn't
> > seem
> > > like a problem with a single broker. Our producer config looks a bit
> like
> > > this:
> > >
> > > final Properties config = new Properties();
> > >
> > >  config.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,
> > > OUR_KAFKA_CONNECT_STRING);
> > >
> > >  config.put(ProducerConfig.BLOCK_ON_BUFFER_FULL_CONFIG, false);  // non
> > > blocking
> > >
> > >  config.put(ProducerConfig.BUFFER_MEMORY_CONFIG,  10 * 1024 * 1024);
> //
> > 10
> > > MB
> > >
> > >  config.put(ProducerConfig.BATCH_SIZE_CONFIG,  16384);  // 16 KB
> > >
> > >  config.put(ProducerConfig.LINGER_MS_CONFIG, 50);  // 50 ms
> > >
> > >
> > > Thanks,
> > >
> > > Rajiv
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>



-- 
-- Guozhang