Re: Monitoring connection with kafka client
@Otis thanks for your answer. Of course it is not about manually watching connection. We already have monitoring tools in place. But I would expect the kafka client to provide means for get notified about potential connectivity issues. Actual behavior is this: the client retries to reconnect indefinitely (I see errors in logs). What I need, is a kind of listener which would be invoked when the connection state change. In other words, once the client notice the problem and is trying to reconnect, our monitoring tools would reflect the connection state as soon as the problem appears. Thanks, Alex On 16 October 2014 13:09, Alex Objelean wrote: > Hi, > > I'm trying to monitor the kafka connection on the consumer side. In other > words, if the broker cluster is unavailable (or zookeer dies), I would like > to know about that problem as soon as possible. > Unfortunately, I didn't find anything useful to achieve that when using > kafka library. > Are there any suggestions about how to fix this issue? > > Thanks, > Alex >
Re: Monitoring connection with kafka client
@Neha Narkede Though monitoring the health of Kafka & Zookeeper clusters directly is useful, it might not be enough. Consider the following scenario: You have a client consuming messages. Zookeeper and kafka nodes are healthy. The monitor says everything is ok. For some reason, a connection between client and zookeeper fails (new firewall rule or connectivity issues between different data centers, doesn't really matter). Since the zookeeper and kafka nodes are still healthy, the monitor is still reporting OK. The client retries to reconnect indefinitely, but unless a human is watching the logs, the problem is not visible by anybody. Having a listener which is invoked when the connection state is changed is something that is provided by other messaging frameworks. Having this feature added to kafka would be a nice addition. Thanks, Alex On 17 October 2014 10:55, Alex Objelean wrote: > @Otis thanks for your answer. > > Of course it is not about manually watching connection. We already have > monitoring tools in place. But I would expect the kafka client to provide > means for get notified about potential connectivity issues. > Actual behavior is this: the client retries to reconnect indefinitely (I > see errors in logs). What I need, is a kind of listener which would be > invoked when the connection state change. In other words, once the client > notice the problem and is trying to reconnect, our monitoring tools would > reflect the connection state as soon as the problem appears. > > Thanks, > Alex > > > > On 16 October 2014 13:09, Alex Objelean wrote: > >> Hi, >> >> I'm trying to monitor the kafka connection on the consumer side. In other >> words, if the broker cluster is unavailable (or zookeer dies), I would like >> to know about that problem as soon as possible. >> Unfortunately, I didn't find anything useful to achieve that when using >> kafka library. >> Are there any suggestions about how to fix this issue? >> >> Thanks, >> Alex >> > >
Re: getOffsetsBefore(...) => kafka.common.UnknownException
Yes, I used TopicMetaDataRequest to determine the lead broker for the partition.
I’ve also compared the broker selected by my code with the output from
"bin/kafka-topics.sh --describe[...]" and as far as I can tell, it’s using the
broker which is described as leader for the topic.
/Magnus
On 17 Oct 2014, at 05:55, Jun Rao wrote:
> The OffsetRequest can only be answered by the leader of the partition. Did
> you connect the SimpleConsumer to the leader broker? If not, you need to
> use TopicMetadataRequest to find out the leader broker first.
>
> Thanks,
>
> Jun
>
> On Thu, Oct 16, 2014 at 3:56 AM, Magnus Vojbacke <
> magnus.vojba...@digitalroute.com> wrote:
>
>> Hi,
>>
>> I’m trying to make a request for offset information from my broker, and I
>> get a kafka.common.UnknownException as the result.
>>
>> I’m trying to use the Simple Consumer API
>>
>>
>>
>>val topicAndPartition = new TopicAndPartition(“topic3”, 0)
>>val requestInfo = new java.util.HashMap[TopicAndPartition,
>> PartitionOffsetRequestInfo]()
>>requestInfo.put(topicAndPartition, new
>> PartitionOffsetRequestInfo(kafka.api.OffsetRequest.EarliestTime, 1))
>>
>>val request = new kafka.javaapi.OffsetRequest(requestInfo,
>> kafka.api.OffsetRequest.CurrentVersion, clientName)
>>
>>import kafka.javaapi._
>>// conn: kafka.javaapi.consumer.SimpleConsumer
>>val response: OffsetResponse = conn.getOffsetsBefore(request)
>>
>>println("got response [" + response + “]")
>>
>>
>>
>> Output:
>> got response [OffsetResponse(0,Map([test3,1] -> error:
>> kafka.common.UnknownException offsets: 0))]
>>
>>
>> I really can’t figure out why I’m getting this response. As far as I know,
>> “topic3” with partition “0” exists on the broker, and I can use
>> bin/kafka-console-consumer.sh to consume from it without any problems.
>>
>>
>> Is there any idea of what could cause this exception?
>>
>> As it is right now, I’m not even sure if the request gets to the broker.
>> Is there any way of activating more verbose logs on the broker?
>>
>> I think I’m using a trunk build (2.10-0.8.3-SNAPSHOT)
>>
>>
>> BR
>> /Magnus
>>
>>
Re: getOffsetsBefore(...) => kafka.common.UnknownException
Hi,
I’m not sure if I’m confusing the concepts here, because I don’t understand
your answer?
I thought that the reason for making a PartitionOffsetRequest was to determine
which offset to use when fetching messages? Also, how is message.max.bytes
related?
I’m using the simple consumer api, and I'm at the point where I want to start
consuming a partition, and I want to determine which is the latest offset (I’m
not taking into consideration what my consumer has consumed previously, I just
want to start at the tail of the partition) before I make my first message
fetch request.
/Magnus
On 16 Oct 2014, at 19:11, Neha Narkhede wrote:
> Do you see any errors on the broker?
> Are you sure that the consumer's fetch offset is set higher than the
> largest message in your topic? It should be higher than message.max.bytes
> on the broker (which defaults to 1MB).
>
> On Thu, Oct 16, 2014 at 3:56 AM, Magnus Vojbacke <
> magnus.vojba...@digitalroute.com> wrote:
>
>> Hi,
>>
>> I’m trying to make a request for offset information from my broker, and I
>> get a kafka.common.UnknownException as the result.
>>
>> I’m trying to use the Simple Consumer API
>>
>>
>>
>>val topicAndPartition = new TopicAndPartition(“topic3”, 0)
>>val requestInfo = new java.util.HashMap[TopicAndPartition,
>> PartitionOffsetRequestInfo]()
>>requestInfo.put(topicAndPartition, new
>> PartitionOffsetRequestInfo(kafka.api.OffsetRequest.EarliestTime, 1))
>>
>>val request = new kafka.javaapi.OffsetRequest(requestInfo,
>> kafka.api.OffsetRequest.CurrentVersion, clientName)
>>
>>import kafka.javaapi._
>>// conn: kafka.javaapi.consumer.SimpleConsumer
>>val response: OffsetResponse = conn.getOffsetsBefore(request)
>>
>>println("got response [" + response + “]")
>>
>>
>>
>> Output:
>> got response [OffsetResponse(0,Map([test3,1] -> error:
>> kafka.common.UnknownException offsets: 0))]
>>
>>
>> I really can’t figure out why I’m getting this response. As far as I know,
>> “topic3” with partition “0” exists on the broker, and I can use
>> bin/kafka-console-consumer.sh to consume from it without any problems.
>>
>>
>> Is there any idea of what could cause this exception?
>>
>> As it is right now, I’m not even sure if the request gets to the broker.
>> Is there any way of activating more verbose logs on the broker?
>>
>> I think I’m using a trunk build (2.10-0.8.3-SNAPSHOT)
>>
>>
>> BR
>> /Magnus
>>
>>
RE: Kafka/Zookeeper deployment Questions
Neha, Thanks. I'd still love to know if anyone has used Consul and/or Confd to manage a cluster. Casey From: Neha Narkhede [neha.narkh...@gmail.com] Sent: Thursday, October 16, 2014 9:54 AM To: users@kafka.apache.org Subject: Re: Kafka/Zookeeper deployment Questions In other words, if I change the number of partitions, can I restart the brokers one at a time so that I can continue processing data? Changing the # of partitions is an online operation and doesn't require restarting the brokers. However, any other configuration (with the exception of a few operations) that requires a broker restart can be done in a rolling manner. On Wed, Oct 15, 2014 at 7:16 PM, Sybrandy, Casey < casey.sybra...@six3systems.com> wrote: > Hello, > > We're looking into deploying Kafka and Zookeeper into an environment where > we want things to be as easy to stand up and administer. To do this, we're > looking into using Consul, or similar, and Confd to try to make this as > automatic as possible. I was wondering if anyone had an experience in this > area. My major concern is reconfiguring Kafka as, in my experience, is > making sure we don't end up losing messages. > > Also, can kafka and zookeeper be reconfigured in a rolling manner? In > other words, if I change the number of partitions, can I restart the > brokers one at a time so that I can continue processing data? > > Thanks.
FetchRequestBuilder.maxWait: request for clarification
Hi, The method kafka.api.FetchRequestBuilder.maxWait(maxwait: Int) does not give the result I would have expected. I have not been able to find any documentation or clarification on the method’s meaning. My assumption is: If I send a fetch request for messages after offset X for a partition where there are currently no messages with offsets after X, I would expect that a Fetch request built with the maxwait option should block on the broker side for $maxwait milliseconds for a new message to arrive. Is this a correct assumption? Currently, the request appears to return immediately, which is not what I expected. Regards /Magnus
Re: Monitoring connection with kafka client
Alex, In the above mentioned case I think monitoring the consumer lag will be helpful "kafka.consumer":name="([-.\w]+)-MaxLag",type="ConsumerFetcherManager". Another approach I used before was to use metrics library to send consumer stats to ganglia and use nagios alert on those stats, If the consumed messages drops below certain threshold . -Harsha On Fri, Oct 17, 2014, at 01:08 AM, Alex Objelean wrote: > @Neha Narkede > > Though monitoring the health of Kafka & Zookeeper clusters directly is > useful, it might not be enough. > Consider the following scenario: > > You have a client consuming messages. Zookeeper and kafka nodes are > healthy. The monitor says everything is ok. For some reason, a connection > between client and zookeeper fails (new firewall rule or connectivity > issues between different data centers, doesn't really matter). Since the > zookeeper and kafka nodes are still healthy, the monitor is still > reporting > OK. The client retries to reconnect indefinitely, but unless a human is > watching the logs, the problem is not visible by anybody. > > Having a listener which is invoked when the connection state is changed > is > something that is provided by other messaging frameworks. Having this > feature added to kafka would be a nice addition. > > Thanks, > Alex > > On 17 October 2014 10:55, Alex Objelean wrote: > > > @Otis thanks for your answer. > > > > Of course it is not about manually watching connection. We already have > > monitoring tools in place. But I would expect the kafka client to provide > > means for get notified about potential connectivity issues. > > Actual behavior is this: the client retries to reconnect indefinitely (I > > see errors in logs). What I need, is a kind of listener which would be > > invoked when the connection state change. In other words, once the client > > notice the problem and is trying to reconnect, our monitoring tools would > > reflect the connection state as soon as the problem appears. > > > > Thanks, > > Alex > > > > > > > > On 16 October 2014 13:09, Alex Objelean wrote: > > > >> Hi, > >> > >> I'm trying to monitor the kafka connection on the consumer side. In other > >> words, if the broker cluster is unavailable (or zookeer dies), I would like > >> to know about that problem as soon as possible. > >> Unfortunately, I didn't find anything useful to achieve that when using > >> kafka library. > >> Are there any suggestions about how to fix this issue? > >> > >> Thanks, > >> Alex > >> > > > >
Re: Live Upgrade
Hi Balaji, You could do a rolling bounce of the brokers to do the in-place upgrade if your partitions have at least two replicas. After that you may probably need to rebalance the leaders if they are not balanced any more. Guozhang On Wed, Oct 15, 2014 at 10:53 AM, Seshadri, Balaji wrote: > Hi Guys, > > Can you guys share any experiences you had with Live Upgrade ?. > > How reliable is it ?.Did we lose messages ?. > > What issues did you guys face when doing live upgrade. > > We are planning to upgrade to 0.8.2 from 0.8-beta before we move our web > methods broker based messaging layer to Kafka. > > We would like to get your inputs. > > Thanks, > > Balaji > -- -- Guozhang
Re: Live Upgrade
At least two including the leader? On Fri, Oct 17, 2014 at 8:12 AM, Guozhang Wang wrote: > Hi Balaji, > > You could do a rolling bounce of the brokers to do the in-place upgrade if > your partitions have at least two replicas. After that you may probably > need to rebalance the leaders if they are not balanced any more. > > Guozhang > > On Wed, Oct 15, 2014 at 10:53 AM, Seshadri, Balaji < > balaji.sesha...@dish.com > > wrote: > > > Hi Guys, > > > > Can you guys share any experiences you had with Live Upgrade ?. > > > > How reliable is it ?.Did we lose messages ?. > > > > What issues did you guys face when doing live upgrade. > > > > We are planning to upgrade to 0.8.2 from 0.8-beta before we move our web > > methods broker based messaging layer to Kafka. > > > > We would like to get your inputs. > > > > Thanks, > > > > Balaji > > > > > > -- > -- Guozhang >
Re: Kafka/Zookeeper deployment Questions
Casey, Could you describe a little more about how these would help manage a cluster? My understanding is that Consul provides service discovery and leader election. Kafka already uses ZooKeeper for brokers to discover each other and elect partition leaders. Kafka high-level consumers use ZK to divide up topic partitions amongst themselves. I'm not able to see how Consul +/or confd will help. Cheers, Roger On Fri, Oct 17, 2014 at 5:16 AM, Sybrandy, Casey < casey.sybra...@six3systems.com> wrote: > Neha, > > Thanks. I'd still love to know if anyone has used Consul and/or Confd to > manage a cluster. > > Casey > > > From: Neha Narkhede [neha.narkh...@gmail.com] > Sent: Thursday, October 16, 2014 9:54 AM > To: users@kafka.apache.org > Subject: Re: Kafka/Zookeeper deployment Questions > > In other words, if I change the number of partitions, can I restart the > brokers one at a time so that I can continue processing data? > > Changing the # of partitions is an online operation and doesn't require > restarting the brokers. However, any other configuration (with the > exception of a few operations) that requires a broker restart can be done > in a rolling manner. > > On Wed, Oct 15, 2014 at 7:16 PM, Sybrandy, Casey < > casey.sybra...@six3systems.com> wrote: > > > Hello, > > > > We're looking into deploying Kafka and Zookeeper into an environment > where > > we want things to be as easy to stand up and administer. To do this, > we're > > looking into using Consul, or similar, and Confd to try to make this as > > automatic as possible. I was wondering if anyone had an experience in > this > > area. My major concern is reconfiguring Kafka as, in my experience, is > > making sure we don't end up losing messages. > > > > Also, can kafka and zookeeper be reconfigured in a rolling manner? In > > other words, if I change the number of partitions, can I restart the > > brokers one at a time so that I can continue processing data? > > > > Thanks. >
Re: Live Upgrade
Yes. On Fri, Oct 17, 2014 at 8:52 AM, Roger Hoover wrote: > At least two including the leader? > > On Fri, Oct 17, 2014 at 8:12 AM, Guozhang Wang wrote: > > > Hi Balaji, > > > > You could do a rolling bounce of the brokers to do the in-place upgrade > if > > your partitions have at least two replicas. After that you may probably > > need to rebalance the leaders if they are not balanced any more. > > > > Guozhang > > > > On Wed, Oct 15, 2014 at 10:53 AM, Seshadri, Balaji < > > balaji.sesha...@dish.com > > > wrote: > > > > > Hi Guys, > > > > > > Can you guys share any experiences you had with Live Upgrade ?. > > > > > > How reliable is it ?.Did we lose messages ?. > > > > > > What issues did you guys face when doing live upgrade. > > > > > > We are planning to upgrade to 0.8.2 from 0.8-beta before we move our > web > > > methods broker based messaging layer to Kafka. > > > > > > We would like to get your inputs. > > > > > > Thanks, > > > > > > Balaji > > > > > > > > > > > -- > > -- Guozhang > > > -- -- Guozhang
Topic doesn't exist exception
Is Kafka supposed to throw exception if topic doesn't exist? It appears that there is no exception thrown even though no messages are delivered and there are errors logged in Kafka logs.
RE: Kafka/Zookeeper deployment Questions
Roger, My understanding of both, beyond what Zookeeper already does, are: 1. Consul can be used to monitor a service and report it's status. This can be very useful for knowing if a service, such as Zookeeper of Kafka, goes down. This can be done through a built-in web interface. 2. Confd leverages Consul, or etcd, to propogate changes to a service and restart it if necessary. So, if we change a broker specific setting, we can put the change in Consul and have Confd automatically modify the config files on the broker nodes and restart the service as needed. My knowledge in this area is a bit limited as I haven't used either. I'm working with someone who is and wanted to ask people about this so that we can learn what works and what doesn't. ___ From: Roger Hoover [roger.hoo...@gmail.com] Sent: Friday, October 17, 2014 12:26 PM To: users@kafka.apache.org Subject: Re: Kafka/Zookeeper deployment Questions Casey, Could you describe a little more about how these would help manage a cluster? My understanding is that Consul provides service discovery and leader election. Kafka already uses ZooKeeper for brokers to discover each other and elect partition leaders. Kafka high-level consumers use ZK to divide up topic partitions amongst themselves. I'm not able to see how Consul +/or confd will help. Cheers, Roger
Re: Kafka/Zookeeper deployment Questions
Thank you, Casey. Both of those features sound pretty useful. On Fri, Oct 17, 2014 at 10:16 AM, Sybrandy, Casey < casey.sybra...@six3systems.com> wrote: > Roger, > > My understanding of both, beyond what Zookeeper already does, are: > > 1. Consul can be used to monitor a service and report it's status. This > can be very useful for knowing if a service, such as Zookeeper of Kafka, > goes down. This can be done through a built-in web interface. > 2. Confd leverages Consul, or etcd, to propogate changes to a service and > restart it if necessary. So, if we change a broker specific setting, we > can put the change in Consul and have Confd automatically modify the config > files on the broker nodes and restart the service as needed. > > My knowledge in this area is a bit limited as I haven't used either. I'm > working with someone who is and wanted to ask people about this so that we > can learn what works and what doesn't. > > ___ > From: Roger Hoover [roger.hoo...@gmail.com] > Sent: Friday, October 17, 2014 12:26 PM > To: users@kafka.apache.org > Subject: Re: Kafka/Zookeeper deployment Questions > > Casey, > > Could you describe a little more about how these would help manage a > cluster? > > My understanding is that Consul provides service discovery and leader > election. Kafka already uses ZooKeeper for brokers to discover each other > and elect partition leaders. Kafka high-level consumers use ZK to divide > up topic partitions amongst themselves. > > I'm not able to see how Consul +/or confd will help. > > Cheers, > > Roger >
Re: Topic doesn't exist exception
If you have "auto.create.topics.enable" set to "true" (default), producing to a topic creates it. Its a bit tricky because the "send" that creates the topic can fail with "leader not found" or similar issue. retrying few times will eventually succeed as the topic gets created and the leader gets elected. Is it possible that you are not getting errors because you are using async producer? Also "no messages are delivered" can have many causes. Check if the topic exists using: bin/kafka-topics.sh --list --zookeeper localhost:2181 Perhaps the topic was created and the issue is elsewhere (the consumer is a usual suspect! perhaps look in the FAQ for tips with that issue) Gwen On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia wrote: > Is Kafka supposed to throw exception if topic doesn't exist? It appears > that there is no exception thrown even though no messages are delivered and > there are errors logged in Kafka logs.
Re: MBeans, dashes, underscores, and KAFKA-1481
Hi, everyone, We are fixing the mbean names in kafka-1482, by adding separate explicit tags in the name for things like clientId and topic. Another thing that some people have complained before is that we use quotes in the jmx name. Should we also just get rid of the quotes as part of kafka-1482? So, instead of "kafka.server":type="BrokerTopicMetrics",name="topic-1-BytesInPerSec" we will have kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=topic-1 Thanks, Jun On Thu, Oct 9, 2014 at 11:12 AM, Neha Narkhede wrote: > I am going to vote for 1482 to be included in 0.8.2, if we have a patch > submitted in a week. I think we've had this JIRA opened for too long and we > held people back so it's only fair to release this. > > On Wed, Oct 8, 2014 at 9:40 PM, Jun Rao wrote: > > > Otis, > > > > Just have the patch ready asap. We can make a call then. > > > > Thanks, > > > > Jun > > > > On Wed, Oct 8, 2014 at 6:13 AM, Otis Gospodnetic < > > otis.gospodne...@gmail.com > > > wrote: > > > > > Hi Jun, > > > > > > Would by the end of next week be acceptable for 0.8.2? > > > > > > Thanks, > > > Otis > > > -- > > > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > > > Solr & Elasticsearch Support * http://sematext.com/ > > > > > > > > > On Tue, Oct 7, 2014 at 4:04 PM, Jun Rao wrote: > > > > > > > Otis, > > > > > > > > Yes, if you guys can help provide a patch in a few days, we can > > probably > > > > get it to the 0.8.2 release. > > > > > > > > Thanks, > > > > > > > > Jun > > > > > > > > On Tue, Oct 7, 2014 at 12:10 PM, Otis Gospodnetic < > > > > otis.gospodne...@gmail.com> wrote: > > > > > > > > > Hi Jun, > > > > > > > > > > I think your MBean renaming approach will work. I see > > > > > https://issues.apache.org/jira/browse/KAFKA-1481 has Fix Version > > > 0.8.2, > > > > > but > > > > > is not marked as a Blocker. We'd love to get the MBeans fixed so > > this > > > > > makes it in 0.8.2 release. Do you know if this is on anyone's > plate > > > (the > > > > > issue is currently Unassigned)? If not, should we provide a new > > patch > > > > that > > > > > uses your approach? > > > > > > > > > > Thanks, > > > > > Otis > > > > > -- > > > > > Monitoring * Alerting * Anomaly Detection * Centralized Log > > Management > > > > > Solr & Elasticsearch Support * http://sematext.com/ > > > > > > > > > > > > > > > On Thu, Sep 18, 2014 at 4:49 PM, Jun Rao wrote: > > > > > > > > > > > Otis, > > > > > > > > > > > > In kafka-1481, we will have to change the mbean names (at least > the > > > > ones > > > > > > with clientid and topic) anyway. Using the name/value pair in the > > > mbean > > > > > > name allows us to do this in a cleaner way. Yes, "," is not > allowed > > > in > > > > > > clientid or topic. > > > > > > > > > > > > Bhavesh, > > > > > > > > > > > > Yes, I was thinking of making changes in the new metrics package. > > > > > Something > > > > > > like allowing the sensor names to have name/value pairs. The jmx > > > names > > > > > will > > > > > > just follow accordingly. This is probably cleaner than doing the > > > > > escaping. > > > > > > Also, the metric names are more intuitive (otherwise, you have to > > > know > > > > > > which part is the clientid and which part is the topic). > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jun > > > > > > > > > > > > On Wed, Sep 17, 2014 at 2:32 PM, Otis Gospodnetic < > > > > > > otis.gospodne...@gmail.com> wrote: > > > > > > > > > > > > > Hi Jun, > > > > > > > > > > > > > > On Wed, Sep 17, 2014 at 12:35 PM, Jun Rao > > > wrote: > > > > > > > > > > > > > > > Bhavesh, > > > > > > > > > > > > > > > > Yes, allowing dot in clientId and topic makes it a bit harder > > to > > > > > define > > > > > > > the > > > > > > > > JMX bean names. I see a couple of solutions here. > > > > > > > > > > > > > > > > 1. Disable dot in clientId and topic names. The issue is that > > dot > > > > may > > > > > > > > already be used in existing deployment. > > > > > > > > > > > > > > > > 2. We can represent the JMX bean name differently in the new > > > > > producer. > > > > > > > > Instead of > > > > > > > > kafka.producer.myclientid:type=mytopic > > > > > > > > we could change it to > > > > > > > > kafka.producer:clientId=myclientid,topic=mytopic > > > > > > > > > > > > > > > > I felt that option 2 is probably better since it doesn't > affect > > > > > > existing > > > > > > > > users. > > > > > > > > > > > > > > > > > > > > > > If it doesn't affect existing users, great. > > > > > > > > > > > > > > If you are saying that each "piece" of MBean name could be > > > expressed > > > > as > > > > > > > name=value pair, with something like "," (forbidden in host > > names, > > > > > topic > > > > > > > names, client IDs, etc. I assume?) then yes, I think this would > > be > > > > > easier > > > > > > > to parse and it would be easier for people to understand what > is > > > > what. > > > > > > > > > > > > > > Otis > > > > > > > -- > > > > > >
Re: Topic doesn't exist exception
Thanks! How can I tell if I am using async producer? I thought all the sends are async in nature On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira wrote: > If you have "auto.create.topics.enable" set to "true" (default), > producing to a topic creates it. > > Its a bit tricky because the "send" that creates the topic can fail > with "leader not found" or similar issue. retrying few times will > eventually succeed as the topic gets created and the leader gets > elected. > > Is it possible that you are not getting errors because you are using > async producer? > > Also "no messages are delivered" can have many causes. Check if the > topic exists using: > bin/kafka-topics.sh --list --zookeeper localhost:2181 > > Perhaps the topic was created and the issue is elsewhere (the consumer > is a usual suspect! perhaps look in the FAQ for tips with that issue) > > Gwen > > On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia > wrote: > > Is Kafka supposed to throw exception if topic doesn't exist? It appears > > that there is no exception thrown even though no messages are delivered > and > > there are errors logged in Kafka logs. >
Re: Topic doesn't exist exception
0.8.1.1 producer is Sync by default, and you can set producer.type to async if needed. On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia wrote: > Thanks! How can I tell if I am using async producer? I thought all the > sends are async in nature > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira > wrote: > >> If you have "auto.create.topics.enable" set to "true" (default), >> producing to a topic creates it. >> >> Its a bit tricky because the "send" that creates the topic can fail >> with "leader not found" or similar issue. retrying few times will >> eventually succeed as the topic gets created and the leader gets >> elected. >> >> Is it possible that you are not getting errors because you are using >> async producer? >> >> Also "no messages are delivered" can have many causes. Check if the >> topic exists using: >> bin/kafka-topics.sh --list --zookeeper localhost:2181 >> >> Perhaps the topic was created and the issue is elsewhere (the consumer >> is a usual suspect! perhaps look in the FAQ for tips with that issue) >> >> Gwen >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia >> wrote: >> > Is Kafka supposed to throw exception if topic doesn't exist? It appears >> > that there is no exception thrown even though no messages are delivered >> and >> > there are errors logged in Kafka logs. >>
Re: read N items from topic
btw. I got a blog post where I show how I work around the blocking hasNext() thing. May be helpful: http://ingest.tips/2014/10/12/kafka-high-level-consumer-frequently-missing-pieces/ On Thu, Oct 16, 2014 at 12:52 PM, Neha Narkhede wrote: > Josh, > > The consumer's API doesn't allow you to specify N messages, but you can > invoke iter.next() as Gwen suggested and count the messages. Note that the > iterator can block if you have less than N messages so you will have to > careful design around it. The new consumer's API provides a non blocking > poll() API so this sort of use case is better handled. In any case, getting > messages based on a count is something that has to happen on the consumer > side since the server sends the bytes using the sendfile API that doesn't > allow it to inspect the bytes. > > Thanks, > Neha > > On Thu, Oct 16, 2014 at 8:37 AM, wrote: > >> Using the high level consumer, each consumer in the group can call >> iter.next () in a loop until they get the number of messages you need. >> >> — >> Sent from Mailbox >> >> On Thu, Oct 16, 2014 at 10:18 AM, Josh J wrote: >> >> > hi, >> > How do I read N items from a topic? I also would like to do this for a >> > consumer group, so that each consumer can specify an N number of tuples >> to >> > read, and each consumer reads distinct tuples. >> > Thanks, >> > Josh >>
Re: Topic doesn't exist exception
Little confused :) From one of the examples I am using property request.required.acks=0, I thought this sets the producer to be async? On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira wrote: > 0.8.1.1 producer is Sync by default, and you can set producer.type to > async if needed. > > On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia > wrote: > > Thanks! How can I tell if I am using async producer? I thought all the > > sends are async in nature > > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira > > wrote: > > > >> If you have "auto.create.topics.enable" set to "true" (default), > >> producing to a topic creates it. > >> > >> Its a bit tricky because the "send" that creates the topic can fail > >> with "leader not found" or similar issue. retrying few times will > >> eventually succeed as the topic gets created and the leader gets > >> elected. > >> > >> Is it possible that you are not getting errors because you are using > >> async producer? > >> > >> Also "no messages are delivered" can have many causes. Check if the > >> topic exists using: > >> bin/kafka-topics.sh --list --zookeeper localhost:2181 > >> > >> Perhaps the topic was created and the issue is elsewhere (the consumer > >> is a usual suspect! perhaps look in the FAQ for tips with that issue) > >> > >> Gwen > >> > >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia > > >> wrote: > >> > Is Kafka supposed to throw exception if topic doesn't exist? It > appears > >> > that there is no exception thrown even though no messages are > delivered > >> and > >> > there are errors logged in Kafka logs. > >> >
Re: MBeans, dashes, underscores, and KAFKA-1481
+1 to get rid of quotes, thanks! — Sent from Mailbox On Fri, Oct 17, 2014 at 8:54 PM, Jun Rao wrote: > Hi, everyone, > We are fixing the mbean names in kafka-1482, by adding separate explicit > tags in the name for things like clientId and topic. Another thing that > some people have complained before is that we use quotes in the jmx name. > Should we also just get rid of the quotes as part of kafka-1482? So, > instead of >"kafka.server":type="BrokerTopicMetrics",name="topic-1-BytesInPerSec" > we will have >kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=topic-1 > Thanks, > Jun > On Thu, Oct 9, 2014 at 11:12 AM, Neha Narkhede > wrote: >> I am going to vote for 1482 to be included in 0.8.2, if we have a patch >> submitted in a week. I think we've had this JIRA opened for too long and we >> held people back so it's only fair to release this. >> >> On Wed, Oct 8, 2014 at 9:40 PM, Jun Rao wrote: >> >> > Otis, >> > >> > Just have the patch ready asap. We can make a call then. >> > >> > Thanks, >> > >> > Jun >> > >> > On Wed, Oct 8, 2014 at 6:13 AM, Otis Gospodnetic < >> > otis.gospodne...@gmail.com >> > > wrote: >> > >> > > Hi Jun, >> > > >> > > Would by the end of next week be acceptable for 0.8.2? >> > > >> > > Thanks, >> > > Otis >> > > -- >> > > Monitoring * Alerting * Anomaly Detection * Centralized Log Management >> > > Solr & Elasticsearch Support * http://sematext.com/ >> > > >> > > >> > > On Tue, Oct 7, 2014 at 4:04 PM, Jun Rao wrote: >> > > >> > > > Otis, >> > > > >> > > > Yes, if you guys can help provide a patch in a few days, we can >> > probably >> > > > get it to the 0.8.2 release. >> > > > >> > > > Thanks, >> > > > >> > > > Jun >> > > > >> > > > On Tue, Oct 7, 2014 at 12:10 PM, Otis Gospodnetic < >> > > > otis.gospodne...@gmail.com> wrote: >> > > > >> > > > > Hi Jun, >> > > > > >> > > > > I think your MBean renaming approach will work. I see >> > > > > https://issues.apache.org/jira/browse/KAFKA-1481 has Fix Version >> > > 0.8.2, >> > > > > but >> > > > > is not marked as a Blocker. We'd love to get the MBeans fixed so >> > this >> > > > > makes it in 0.8.2 release. Do you know if this is on anyone's >> plate >> > > (the >> > > > > issue is currently Unassigned)? If not, should we provide a new >> > patch >> > > > that >> > > > > uses your approach? >> > > > > >> > > > > Thanks, >> > > > > Otis >> > > > > -- >> > > > > Monitoring * Alerting * Anomaly Detection * Centralized Log >> > Management >> > > > > Solr & Elasticsearch Support * http://sematext.com/ >> > > > > >> > > > > >> > > > > On Thu, Sep 18, 2014 at 4:49 PM, Jun Rao wrote: >> > > > > >> > > > > > Otis, >> > > > > > >> > > > > > In kafka-1481, we will have to change the mbean names (at least >> the >> > > > ones >> > > > > > with clientid and topic) anyway. Using the name/value pair in the >> > > mbean >> > > > > > name allows us to do this in a cleaner way. Yes, "," is not >> allowed >> > > in >> > > > > > clientid or topic. >> > > > > > >> > > > > > Bhavesh, >> > > > > > >> > > > > > Yes, I was thinking of making changes in the new metrics package. >> > > > > Something >> > > > > > like allowing the sensor names to have name/value pairs. The jmx >> > > names >> > > > > will >> > > > > > just follow accordingly. This is probably cleaner than doing the >> > > > > escaping. >> > > > > > Also, the metric names are more intuitive (otherwise, you have to >> > > know >> > > > > > which part is the clientid and which part is the topic). >> > > > > > >> > > > > > Thanks, >> > > > > > >> > > > > > Jun >> > > > > > >> > > > > > On Wed, Sep 17, 2014 at 2:32 PM, Otis Gospodnetic < >> > > > > > otis.gospodne...@gmail.com> wrote: >> > > > > > >> > > > > > > Hi Jun, >> > > > > > > >> > > > > > > On Wed, Sep 17, 2014 at 12:35 PM, Jun Rao >> > > wrote: >> > > > > > > >> > > > > > > > Bhavesh, >> > > > > > > > >> > > > > > > > Yes, allowing dot in clientId and topic makes it a bit harder >> > to >> > > > > define >> > > > > > > the >> > > > > > > > JMX bean names. I see a couple of solutions here. >> > > > > > > > >> > > > > > > > 1. Disable dot in clientId and topic names. The issue is that >> > dot >> > > > may >> > > > > > > > already be used in existing deployment. >> > > > > > > > >> > > > > > > > 2. We can represent the JMX bean name differently in the new >> > > > > producer. >> > > > > > > > Instead of >> > > > > > > > kafka.producer.myclientid:type=mytopic >> > > > > > > > we could change it to >> > > > > > > > kafka.producer:clientId=myclientid,topic=mytopic >> > > > > > > > >> > > > > > > > I felt that option 2 is probably better since it doesn't >> affect >> > > > > > existing >> > > > > > > > users. >> > > > > > > > >> > > > > > > >> > > > > > > If it doesn't affect existing users, great. >> > > > > > > >> > > > > > > If you are saying that each "piece" of MBean name could be >> > > expressed >> > > > as >> > > > > > > name=value pair, with something like "," (forbidden in host >> > names, >> >
Re: Topic doesn't exist exception
Its using the sync producer without waiting for any broker to acknowledge the write. This explains the lack of errors you are seeing. — Sent from Mailbox On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia wrote: > Little confused :) From one of the examples I am using property > request.required.acks=0, > I thought this sets the producer to be async? > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira > wrote: >> 0.8.1.1 producer is Sync by default, and you can set producer.type to >> async if needed. >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia >> wrote: >> > Thanks! How can I tell if I am using async producer? I thought all the >> > sends are async in nature >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira >> > wrote: >> > >> >> If you have "auto.create.topics.enable" set to "true" (default), >> >> producing to a topic creates it. >> >> >> >> Its a bit tricky because the "send" that creates the topic can fail >> >> with "leader not found" or similar issue. retrying few times will >> >> eventually succeed as the topic gets created and the leader gets >> >> elected. >> >> >> >> Is it possible that you are not getting errors because you are using >> >> async producer? >> >> >> >> Also "no messages are delivered" can have many causes. Check if the >> >> topic exists using: >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 >> >> >> >> Perhaps the topic was created and the issue is elsewhere (the consumer >> >> is a usual suspect! perhaps look in the FAQ for tips with that issue) >> >> >> >> Gwen >> >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia > > >> >> wrote: >> >> > Is Kafka supposed to throw exception if topic doesn't exist? It >> appears >> >> > that there is no exception thrown even though no messages are >> delivered >> >> and >> >> > there are errors logged in Kafka logs. >> >> >>
Re: Topic doesn't exist exception
Still don't understand the difference. If it's not waiting for the ack then doesn't it make async? On Fri, Oct 17, 2014 at 12:55 PM, wrote: > Its using the sync producer without waiting for any broker to acknowledge > the write. This explains the lack of errors you are seeing. > > — > Sent from Mailbox > > On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia > wrote: > > > Little confused :) From one of the examples I am using property > > request.required.acks=0, > > I thought this sets the producer to be async? > > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira > > wrote: > >> 0.8.1.1 producer is Sync by default, and you can set producer.type to > >> async if needed. > >> > >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia > >> wrote: > >> > Thanks! How can I tell if I am using async producer? I thought all the > >> > sends are async in nature > >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira > > >> > wrote: > >> > > >> >> If you have "auto.create.topics.enable" set to "true" (default), > >> >> producing to a topic creates it. > >> >> > >> >> Its a bit tricky because the "send" that creates the topic can fail > >> >> with "leader not found" or similar issue. retrying few times will > >> >> eventually succeed as the topic gets created and the leader gets > >> >> elected. > >> >> > >> >> Is it possible that you are not getting errors because you are using > >> >> async producer? > >> >> > >> >> Also "no messages are delivered" can have many causes. Check if the > >> >> topic exists using: > >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 > >> >> > >> >> Perhaps the topic was created and the issue is elsewhere (the > consumer > >> >> is a usual suspect! perhaps look in the FAQ for tips with that issue) > >> >> > >> >> Gwen > >> >> > >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < > mohitanch...@gmail.com > >> > > >> >> wrote: > >> >> > Is Kafka supposed to throw exception if topic doesn't exist? It > >> appears > >> >> > that there is no exception thrown even though no messages are > >> delivered > >> >> and > >> >> > there are errors logged in Kafka logs. > >> >> > >> >
Re: Topic doesn't exist exception
Sorry if I'm confusing you :) Kafka 0.8.1.1 has two producers sync and async. You are using the sync producer without waiting for acks. I hope this helps? Regardless, did you check if the partition got created? are you able to produce messages? are you able to consume them? Gwen On Fri, Oct 17, 2014 at 4:13 PM, Mohit Anchlia wrote: > Still don't understand the difference. If it's not waiting for the ack then > doesn't it make async? > On Fri, Oct 17, 2014 at 12:55 PM, wrote: > >> Its using the sync producer without waiting for any broker to acknowledge >> the write. This explains the lack of errors you are seeing. >> >> — >> Sent from Mailbox >> >> On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia >> wrote: >> >> > Little confused :) From one of the examples I am using property >> > request.required.acks=0, >> > I thought this sets the producer to be async? >> > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira >> > wrote: >> >> 0.8.1.1 producer is Sync by default, and you can set producer.type to >> >> async if needed. >> >> >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia >> >> wrote: >> >> > Thanks! How can I tell if I am using async producer? I thought all the >> >> > sends are async in nature >> >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira > > >> >> > wrote: >> >> > >> >> >> If you have "auto.create.topics.enable" set to "true" (default), >> >> >> producing to a topic creates it. >> >> >> >> >> >> Its a bit tricky because the "send" that creates the topic can fail >> >> >> with "leader not found" or similar issue. retrying few times will >> >> >> eventually succeed as the topic gets created and the leader gets >> >> >> elected. >> >> >> >> >> >> Is it possible that you are not getting errors because you are using >> >> >> async producer? >> >> >> >> >> >> Also "no messages are delivered" can have many causes. Check if the >> >> >> topic exists using: >> >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 >> >> >> >> >> >> Perhaps the topic was created and the issue is elsewhere (the >> consumer >> >> >> is a usual suspect! perhaps look in the FAQ for tips with that issue) >> >> >> >> >> >> Gwen >> >> >> >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < >> mohitanch...@gmail.com >> >> > >> >> >> wrote: >> >> >> > Is Kafka supposed to throw exception if topic doesn't exist? It >> >> appears >> >> >> > that there is no exception thrown even though no messages are >> >> delivered >> >> >> and >> >> >> > there are errors logged in Kafka logs. >> >> >> >> >> >>
Re: Topic doesn't exist exception
My understanding of sync is that producer waits on .send until Kafka receives the message. And async means it just dispatches the message without any gurantees that message is delivered. Did I get that part right? On Fri, Oct 17, 2014 at 1:28 PM, Gwen Shapira wrote: > Sorry if I'm confusing you :) > > Kafka 0.8.1.1 has two producers sync and async. You are using the sync > producer without waiting for acks. I hope this helps? > > Regardless, did you check if the partition got created? are you able > to produce messages? are you able to consume them? > > Gwen > > On Fri, Oct 17, 2014 at 4:13 PM, Mohit Anchlia > wrote: > > Still don't understand the difference. If it's not waiting for the ack > then > > doesn't it make async? > > On Fri, Oct 17, 2014 at 12:55 PM, wrote: > > > >> Its using the sync producer without waiting for any broker to > acknowledge > >> the write. This explains the lack of errors you are seeing. > >> > >> — > >> Sent from Mailbox > >> > >> On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia > >> wrote: > >> > >> > Little confused :) From one of the examples I am using property > >> > request.required.acks=0, > >> > I thought this sets the producer to be async? > >> > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira > > >> > wrote: > >> >> 0.8.1.1 producer is Sync by default, and you can set producer.type to > >> >> async if needed. > >> >> > >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia < > mohitanch...@gmail.com> > >> >> wrote: > >> >> > Thanks! How can I tell if I am using async producer? I thought all > the > >> >> > sends are async in nature > >> >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira < > gshap...@cloudera.com > >> > > >> >> > wrote: > >> >> > > >> >> >> If you have "auto.create.topics.enable" set to "true" (default), > >> >> >> producing to a topic creates it. > >> >> >> > >> >> >> Its a bit tricky because the "send" that creates the topic can > fail > >> >> >> with "leader not found" or similar issue. retrying few times will > >> >> >> eventually succeed as the topic gets created and the leader gets > >> >> >> elected. > >> >> >> > >> >> >> Is it possible that you are not getting errors because you are > using > >> >> >> async producer? > >> >> >> > >> >> >> Also "no messages are delivered" can have many causes. Check if > the > >> >> >> topic exists using: > >> >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 > >> >> >> > >> >> >> Perhaps the topic was created and the issue is elsewhere (the > >> consumer > >> >> >> is a usual suspect! perhaps look in the FAQ for tips with that > issue) > >> >> >> > >> >> >> Gwen > >> >> >> > >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < > >> mohitanch...@gmail.com > >> >> > > >> >> >> wrote: > >> >> >> > Is Kafka supposed to throw exception if topic doesn't exist? It > >> >> appears > >> >> >> > that there is no exception thrown even though no messages are > >> >> delivered > >> >> >> and > >> >> >> > there are errors logged in Kafka logs. > >> >> >> > >> >> > >> >
Re: MBeans, dashes, underscores, and KAFKA-1481
+1 on getting rid of the quotes. On Fri, Oct 17, 2014 at 12:31 PM, Magnus Spångdal < magnus.spang...@deltaprojects.com> wrote: > +1 to get rid of quotes, thanks! > > > > > > > — > Sent from Mailbox > > On Fri, Oct 17, 2014 at 8:54 PM, Jun Rao wrote: > > > Hi, everyone, > > We are fixing the mbean names in kafka-1482, by adding separate explicit > > tags in the name for things like clientId and topic. Another thing that > > some people have complained before is that we use quotes in the jmx name. > > Should we also just get rid of the quotes as part of kafka-1482? So, > > instead of > >"kafka.server":type="BrokerTopicMetrics",name="topic-1-BytesInPerSec" > > we will have > >kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=topic-1 > > Thanks, > > Jun > > On Thu, Oct 9, 2014 at 11:12 AM, Neha Narkhede > > wrote: > >> I am going to vote for 1482 to be included in 0.8.2, if we have a patch > >> submitted in a week. I think we've had this JIRA opened for too long > and we > >> held people back so it's only fair to release this. > >> > >> On Wed, Oct 8, 2014 at 9:40 PM, Jun Rao wrote: > >> > >> > Otis, > >> > > >> > Just have the patch ready asap. We can make a call then. > >> > > >> > Thanks, > >> > > >> > Jun > >> > > >> > On Wed, Oct 8, 2014 at 6:13 AM, Otis Gospodnetic < > >> > otis.gospodne...@gmail.com > >> > > wrote: > >> > > >> > > Hi Jun, > >> > > > >> > > Would by the end of next week be acceptable for 0.8.2? > >> > > > >> > > Thanks, > >> > > Otis > >> > > -- > >> > > Monitoring * Alerting * Anomaly Detection * Centralized Log > Management > >> > > Solr & Elasticsearch Support * http://sematext.com/ > >> > > > >> > > > >> > > On Tue, Oct 7, 2014 at 4:04 PM, Jun Rao wrote: > >> > > > >> > > > Otis, > >> > > > > >> > > > Yes, if you guys can help provide a patch in a few days, we can > >> > probably > >> > > > get it to the 0.8.2 release. > >> > > > > >> > > > Thanks, > >> > > > > >> > > > Jun > >> > > > > >> > > > On Tue, Oct 7, 2014 at 12:10 PM, Otis Gospodnetic < > >> > > > otis.gospodne...@gmail.com> wrote: > >> > > > > >> > > > > Hi Jun, > >> > > > > > >> > > > > I think your MBean renaming approach will work. I see > >> > > > > https://issues.apache.org/jira/browse/KAFKA-1481 has Fix > Version > >> > > 0.8.2, > >> > > > > but > >> > > > > is not marked as a Blocker. We'd love to get the MBeans fixed > so > >> > this > >> > > > > makes it in 0.8.2 release. Do you know if this is on anyone's > >> plate > >> > > (the > >> > > > > issue is currently Unassigned)? If not, should we provide a new > >> > patch > >> > > > that > >> > > > > uses your approach? > >> > > > > > >> > > > > Thanks, > >> > > > > Otis > >> > > > > -- > >> > > > > Monitoring * Alerting * Anomaly Detection * Centralized Log > >> > Management > >> > > > > Solr & Elasticsearch Support * http://sematext.com/ > >> > > > > > >> > > > > > >> > > > > On Thu, Sep 18, 2014 at 4:49 PM, Jun Rao > wrote: > >> > > > > > >> > > > > > Otis, > >> > > > > > > >> > > > > > In kafka-1481, we will have to change the mbean names (at > least > >> the > >> > > > ones > >> > > > > > with clientid and topic) anyway. Using the name/value pair in > the > >> > > mbean > >> > > > > > name allows us to do this in a cleaner way. Yes, "," is not > >> allowed > >> > > in > >> > > > > > clientid or topic. > >> > > > > > > >> > > > > > Bhavesh, > >> > > > > > > >> > > > > > Yes, I was thinking of making changes in the new metrics > package. > >> > > > > Something > >> > > > > > like allowing the sensor names to have name/value pairs. The > jmx > >> > > names > >> > > > > will > >> > > > > > just follow accordingly. This is probably cleaner than doing > the > >> > > > > escaping. > >> > > > > > Also, the metric names are more intuitive (otherwise, you > have to > >> > > know > >> > > > > > which part is the clientid and which part is the topic). > >> > > > > > > >> > > > > > Thanks, > >> > > > > > > >> > > > > > Jun > >> > > > > > > >> > > > > > On Wed, Sep 17, 2014 at 2:32 PM, Otis Gospodnetic < > >> > > > > > otis.gospodne...@gmail.com> wrote: > >> > > > > > > >> > > > > > > Hi Jun, > >> > > > > > > > >> > > > > > > On Wed, Sep 17, 2014 at 12:35 PM, Jun Rao > > >> > > wrote: > >> > > > > > > > >> > > > > > > > Bhavesh, > >> > > > > > > > > >> > > > > > > > Yes, allowing dot in clientId and topic makes it a bit > harder > >> > to > >> > > > > define > >> > > > > > > the > >> > > > > > > > JMX bean names. I see a couple of solutions here. > >> > > > > > > > > >> > > > > > > > 1. Disable dot in clientId and topic names. The issue is > that > >> > dot > >> > > > may > >> > > > > > > > already be used in existing deployment. > >> > > > > > > > > >> > > > > > > > 2. We can represent the JMX bean name differently in the > new > >> > > > > producer. > >> > > > > > > > Instead of > >> > > > > > > > kafka.producer.myclientid:type=mytopic > >> > > > > > > > we could change it to > >> > > > > > > > kafka.producer:clientId=myclientid,topic=myt
RE: MBeans, dashes, underscores, and KAFKA-1481
+1 as well for getting rid of the quotes. Isn't it an inheritance of metrics-core? Anyway, hope Kafka devs will find a way to get rid of these! Cordialement / Best Regards, Alexandre VERMEERBERGEN R&D Cloud Service Supervision Development Director ––– Office: +33 1 6162 4992 alexandre.vermeerber...@3ds.com http://www.3ds.com ––– Dassault Systèmes | 10 rue Marcel Dassault, CS 40501 | 78946 Vélizy-Villacoublay Cedex | France -Original Message- From: Neha Narkhede [mailto:neha.narkh...@gmail.com] Sent: Friday, October 17, 2014 22:49 To: users@kafka.apache.org Subject: Re: MBeans, dashes, underscores, and KAFKA-1481 +1 on getting rid of the quotes. On Fri, Oct 17, 2014 at 12:31 PM, Magnus Spångdal < magnus.spang...@deltaprojects.com> wrote: > +1 to get rid of quotes, thanks! > > > > > > > — > Sent from Mailbox > > On Fri, Oct 17, 2014 at 8:54 PM, Jun Rao wrote: > > > Hi, everyone, > > We are fixing the mbean names in kafka-1482, by adding separate > > explicit tags in the name for things like clientId and topic. > > Another thing that some people have complained before is that we use quotes > > in the jmx name. > > Should we also just get rid of the quotes as part of kafka-1482? So, > > instead of > >"kafka.server":type="BrokerTopicMetrics",name="topic-1-BytesInPerSec" > > we will have > > > > kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=topic- > > 1 > > Thanks, > > Jun > > On Thu, Oct 9, 2014 at 11:12 AM, Neha Narkhede > > > > wrote: > >> I am going to vote for 1482 to be included in 0.8.2, if we have a > >> patch submitted in a week. I think we've had this JIRA opened for > >> too long > and we > >> held people back so it's only fair to release this. > >> > >> On Wed, Oct 8, 2014 at 9:40 PM, Jun Rao wrote: > >> > >> > Otis, > >> > > >> > Just have the patch ready asap. We can make a call then. > >> > > >> > Thanks, > >> > > >> > Jun > >> > > >> > On Wed, Oct 8, 2014 at 6:13 AM, Otis Gospodnetic < > >> > otis.gospodne...@gmail.com > >> > > wrote: > >> > > >> > > Hi Jun, > >> > > > >> > > Would by the end of next week be acceptable for 0.8.2? > >> > > > >> > > Thanks, > >> > > Otis > >> > > -- > >> > > Monitoring * Alerting * Anomaly Detection * Centralized Log > Management > >> > > Solr & Elasticsearch Support * http://sematext.com/ > >> > > > >> > > > >> > > On Tue, Oct 7, 2014 at 4:04 PM, Jun Rao wrote: > >> > > > >> > > > Otis, > >> > > > > >> > > > Yes, if you guys can help provide a patch in a few days, we > >> > > > can > >> > probably > >> > > > get it to the 0.8.2 release. > >> > > > > >> > > > Thanks, > >> > > > > >> > > > Jun > >> > > > > >> > > > On Tue, Oct 7, 2014 at 12:10 PM, Otis Gospodnetic < > >> > > > otis.gospodne...@gmail.com> wrote: > >> > > > > >> > > > > Hi Jun, > >> > > > > > >> > > > > I think your MBean renaming approach will work. I see > >> > > > > https://issues.apache.org/jira/browse/KAFKA-1481 has Fix > Version > >> > > 0.8.2, > >> > > > > but > >> > > > > is not marked as a Blocker. We'd love to get the MBeans > >> > > > > fixed > so > >> > this > >> > > > > makes it in 0.8.2 release. Do you know if this is on > >> > > > > anyone's > >> plate > >> > > (the > >> > > > > issue is currently Unassigned)? If not, should we provide > >> > > > > a new > >> > patch > >> > > > that > >> > > > > uses your approach? > >> > > > > > >> > > > > Thanks, > >> > > > > Otis > >> > > > > -- > >> > > > > Monitoring * Alerting * Anomaly Detection * Centralized Log > >> > Management > >> > > > > Solr & Elasticsearch Support * http://sematext.com/ > >> > > > > > >> > > > > > >> > > > > On Thu, Sep 18, 2014 at 4:49 PM, Jun Rao > wrote: > >> > > > > > >> > > > > > Otis, > >> > > > > > > >> > > > > > In kafka-1481, we will have to change the mbean names (at > least > >> the > >> > > > ones > >> > > > > > with clientid and topic) anyway. Using the name/value > >> > > > > > pair in > the > >> > > mbean > >> > > > > > name allows us to do this in a cleaner way. Yes, "," is > >> > > > > > not > >> allowed > >> > > in > >> > > > > > clientid or topic. > >> > > > > > > >> > > > > > Bhavesh, > >> > > > > > > >> > > > > > Yes, I was thinking of making changes in the new metrics > package. > >> > > > > Something > >> > > > > > like allowing the sensor names to have name/value pairs. > >> > > > > > The > jmx > >> > > names > >> > > > > will > >> > > > > > just follow accordingly. This is probably cleaner than > >> > > > > > doing > the > >> > > > > escaping. > >> > > > > > Also, the metric names are more intuitive (otherwise, you > have to > >> > > know > >> > > > > > which part is the clientid and which part is the topic). > >> > > > > > > >> > > > > > Thanks, > >> > > > > > > >> > > > > > Jun > >> > > > > > > >> > > > > > On Wed, Sep 17, 2014 at 2:32 PM, Otis Gospodnetic < > >> > > > > > otis.gospodne...@gmail.com> wrote: > >> > > > > > > >> > > > > > > Hi Jun, > >> > > > > > > > >> > > > > > > On Wed, Sep 17, 2014 at 12:3
Re: MBeans, dashes, underscores, and KAFKA-1481
+1 on getting rid of quotes in jmx mbeans. Thanks, Raja. On Fri, Oct 17, 2014 at 4:48 PM, Neha Narkhede wrote: > +1 on getting rid of the quotes. > > On Fri, Oct 17, 2014 at 12:31 PM, Magnus Spångdal < > magnus.spang...@deltaprojects.com> wrote: > > > +1 to get rid of quotes, thanks! > > > > > > > > > > > > > > — > > Sent from Mailbox > > > > On Fri, Oct 17, 2014 at 8:54 PM, Jun Rao wrote: > > > > > Hi, everyone, > > > We are fixing the mbean names in kafka-1482, by adding separate > explicit > > > tags in the name for things like clientId and topic. Another thing that > > > some people have complained before is that we use quotes in the jmx > name. > > > Should we also just get rid of the quotes as part of kafka-1482? So, > > > instead of > > > > "kafka.server":type="BrokerTopicMetrics",name="topic-1-BytesInPerSec" > > > we will have > > > > kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=topic-1 > > > Thanks, > > > Jun > > > On Thu, Oct 9, 2014 at 11:12 AM, Neha Narkhede < > neha.narkh...@gmail.com> > > > wrote: > > >> I am going to vote for 1482 to be included in 0.8.2, if we have a > patch > > >> submitted in a week. I think we've had this JIRA opened for too long > > and we > > >> held people back so it's only fair to release this. > > >> > > >> On Wed, Oct 8, 2014 at 9:40 PM, Jun Rao wrote: > > >> > > >> > Otis, > > >> > > > >> > Just have the patch ready asap. We can make a call then. > > >> > > > >> > Thanks, > > >> > > > >> > Jun > > >> > > > >> > On Wed, Oct 8, 2014 at 6:13 AM, Otis Gospodnetic < > > >> > otis.gospodne...@gmail.com > > >> > > wrote: > > >> > > > >> > > Hi Jun, > > >> > > > > >> > > Would by the end of next week be acceptable for 0.8.2? > > >> > > > > >> > > Thanks, > > >> > > Otis > > >> > > -- > > >> > > Monitoring * Alerting * Anomaly Detection * Centralized Log > > Management > > >> > > Solr & Elasticsearch Support * http://sematext.com/ > > >> > > > > >> > > > > >> > > On Tue, Oct 7, 2014 at 4:04 PM, Jun Rao wrote: > > >> > > > > >> > > > Otis, > > >> > > > > > >> > > > Yes, if you guys can help provide a patch in a few days, we can > > >> > probably > > >> > > > get it to the 0.8.2 release. > > >> > > > > > >> > > > Thanks, > > >> > > > > > >> > > > Jun > > >> > > > > > >> > > > On Tue, Oct 7, 2014 at 12:10 PM, Otis Gospodnetic < > > >> > > > otis.gospodne...@gmail.com> wrote: > > >> > > > > > >> > > > > Hi Jun, > > >> > > > > > > >> > > > > I think your MBean renaming approach will work. I see > > >> > > > > https://issues.apache.org/jira/browse/KAFKA-1481 has Fix > > Version > > >> > > 0.8.2, > > >> > > > > but > > >> > > > > is not marked as a Blocker. We'd love to get the MBeans fixed > > so > > >> > this > > >> > > > > makes it in 0.8.2 release. Do you know if this is on anyone's > > >> plate > > >> > > (the > > >> > > > > issue is currently Unassigned)? If not, should we provide a > new > > >> > patch > > >> > > > that > > >> > > > > uses your approach? > > >> > > > > > > >> > > > > Thanks, > > >> > > > > Otis > > >> > > > > -- > > >> > > > > Monitoring * Alerting * Anomaly Detection * Centralized Log > > >> > Management > > >> > > > > Solr & Elasticsearch Support * http://sematext.com/ > > >> > > > > > > >> > > > > > > >> > > > > On Thu, Sep 18, 2014 at 4:49 PM, Jun Rao > > wrote: > > >> > > > > > > >> > > > > > Otis, > > >> > > > > > > > >> > > > > > In kafka-1481, we will have to change the mbean names (at > > least > > >> the > > >> > > > ones > > >> > > > > > with clientid and topic) anyway. Using the name/value pair > in > > the > > >> > > mbean > > >> > > > > > name allows us to do this in a cleaner way. Yes, "," is not > > >> allowed > > >> > > in > > >> > > > > > clientid or topic. > > >> > > > > > > > >> > > > > > Bhavesh, > > >> > > > > > > > >> > > > > > Yes, I was thinking of making changes in the new metrics > > package. > > >> > > > > Something > > >> > > > > > like allowing the sensor names to have name/value pairs. The > > jmx > > >> > > names > > >> > > > > will > > >> > > > > > just follow accordingly. This is probably cleaner than doing > > the > > >> > > > > escaping. > > >> > > > > > Also, the metric names are more intuitive (otherwise, you > > have to > > >> > > know > > >> > > > > > which part is the clientid and which part is the topic). > > >> > > > > > > > >> > > > > > Thanks, > > >> > > > > > > > >> > > > > > Jun > > >> > > > > > > > >> > > > > > On Wed, Sep 17, 2014 at 2:32 PM, Otis Gospodnetic < > > >> > > > > > otis.gospodne...@gmail.com> wrote: > > >> > > > > > > > >> > > > > > > Hi Jun, > > >> > > > > > > > > >> > > > > > > On Wed, Sep 17, 2014 at 12:35 PM, Jun Rao < > jun...@gmail.com > > > > > >> > > wrote: > > >> > > > > > > > > >> > > > > > > > Bhavesh, > > >> > > > > > > > > > >> > > > > > > > Yes, allowing dot in clientId and topic makes it a bit > > harder > > >> > to > > >> > > > > define > > >> > > > > > > the > > >> > > > > > > > JMX bean names. I see a couple of solutions here. > > >> > > > > > > > >
Re: Topic doesn't exist exception
If I understand correctly (and I'll be happy if someone who knows more will jump in and correct me): The Sync/Async part is not between the producer and the broker. Its between you and the producer. The Sync producer takes your message and immediately contacts the broker, sends the message, either wait for acks or not and returns. The Async producer takes your message and immediately returns. The producer will send the message to the broker at some time later, batching multiple requests for efficiency and throughput. So yeah, I think you got it mostly right. Just note that the producer doesn't wait on .send, the producer executes the send - either returning immediately (if async) or when it managed to contact the broker (if sync). Gwen On Fri, Oct 17, 2014 at 4:38 PM, Mohit Anchlia wrote: > My understanding of sync is that producer waits on .send until Kafka > receives the message. And async means it just dispatches the message > without any gurantees that message is delivered. Did I get that part right? > On Fri, Oct 17, 2014 at 1:28 PM, Gwen Shapira wrote: > >> Sorry if I'm confusing you :) >> >> Kafka 0.8.1.1 has two producers sync and async. You are using the sync >> producer without waiting for acks. I hope this helps? >> >> Regardless, did you check if the partition got created? are you able >> to produce messages? are you able to consume them? >> >> Gwen >> >> On Fri, Oct 17, 2014 at 4:13 PM, Mohit Anchlia >> wrote: >> > Still don't understand the difference. If it's not waiting for the ack >> then >> > doesn't it make async? >> > On Fri, Oct 17, 2014 at 12:55 PM, wrote: >> > >> >> Its using the sync producer without waiting for any broker to >> acknowledge >> >> the write. This explains the lack of errors you are seeing. >> >> >> >> — >> >> Sent from Mailbox >> >> >> >> On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia >> >> wrote: >> >> >> >> > Little confused :) From one of the examples I am using property >> >> > request.required.acks=0, >> >> > I thought this sets the producer to be async? >> >> > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira > > >> >> > wrote: >> >> >> 0.8.1.1 producer is Sync by default, and you can set producer.type to >> >> >> async if needed. >> >> >> >> >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia < >> mohitanch...@gmail.com> >> >> >> wrote: >> >> >> > Thanks! How can I tell if I am using async producer? I thought all >> the >> >> >> > sends are async in nature >> >> >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira < >> gshap...@cloudera.com >> >> > >> >> >> > wrote: >> >> >> > >> >> >> >> If you have "auto.create.topics.enable" set to "true" (default), >> >> >> >> producing to a topic creates it. >> >> >> >> >> >> >> >> Its a bit tricky because the "send" that creates the topic can >> fail >> >> >> >> with "leader not found" or similar issue. retrying few times will >> >> >> >> eventually succeed as the topic gets created and the leader gets >> >> >> >> elected. >> >> >> >> >> >> >> >> Is it possible that you are not getting errors because you are >> using >> >> >> >> async producer? >> >> >> >> >> >> >> >> Also "no messages are delivered" can have many causes. Check if >> the >> >> >> >> topic exists using: >> >> >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 >> >> >> >> >> >> >> >> Perhaps the topic was created and the issue is elsewhere (the >> >> consumer >> >> >> >> is a usual suspect! perhaps look in the FAQ for tips with that >> issue) >> >> >> >> >> >> >> >> Gwen >> >> >> >> >> >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < >> >> mohitanch...@gmail.com >> >> >> > >> >> >> >> wrote: >> >> >> >> > Is Kafka supposed to throw exception if topic doesn't exist? It >> >> >> appears >> >> >> >> > that there is no exception thrown even though no messages are >> >> >> delivered >> >> >> >> and >> >> >> >> > there are errors logged in Kafka logs. >> >> >> >> >> >> >> >> >> >>
Re: Topic doesn't exist exception
Thanks for the info. I see there are tons of parameters but is there a place that lists some important performance specific parameters? On Fri, Oct 17, 2014 at 2:43 PM, Gwen Shapira wrote: > If I understand correctly (and I'll be happy if someone who knows more > will jump in and correct me): > > The Sync/Async part is not between the producer and the broker. Its > between you and the producer. The Sync producer takes your message and > immediately contacts the broker, sends the message, either wait for > acks or not and returns. The Async producer takes your message and > immediately returns. The producer will send the message to the broker > at some time later, batching multiple requests for efficiency and > throughput. > > So yeah, I think you got it mostly right. Just note that the producer > doesn't wait on .send, the producer executes the send - either > returning immediately (if async) or when it managed to contact the > broker (if sync). > > Gwen > > On Fri, Oct 17, 2014 at 4:38 PM, Mohit Anchlia > wrote: > > My understanding of sync is that producer waits on .send until Kafka > > receives the message. And async means it just dispatches the message > > without any gurantees that message is delivered. Did I get that part > right? > > On Fri, Oct 17, 2014 at 1:28 PM, Gwen Shapira > wrote: > > > >> Sorry if I'm confusing you :) > >> > >> Kafka 0.8.1.1 has two producers sync and async. You are using the sync > >> producer without waiting for acks. I hope this helps? > >> > >> Regardless, did you check if the partition got created? are you able > >> to produce messages? are you able to consume them? > >> > >> Gwen > >> > >> On Fri, Oct 17, 2014 at 4:13 PM, Mohit Anchlia > >> wrote: > >> > Still don't understand the difference. If it's not waiting for the ack > >> then > >> > doesn't it make async? > >> > On Fri, Oct 17, 2014 at 12:55 PM, wrote: > >> > > >> >> Its using the sync producer without waiting for any broker to > >> acknowledge > >> >> the write. This explains the lack of errors you are seeing. > >> >> > >> >> — > >> >> Sent from Mailbox > >> >> > >> >> On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia < > mohitanch...@gmail.com> > >> >> wrote: > >> >> > >> >> > Little confused :) From one of the examples I am using property > >> >> > request.required.acks=0, > >> >> > I thought this sets the producer to be async? > >> >> > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira < > gshap...@cloudera.com > >> > > >> >> > wrote: > >> >> >> 0.8.1.1 producer is Sync by default, and you can set > producer.type to > >> >> >> async if needed. > >> >> >> > >> >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia < > >> mohitanch...@gmail.com> > >> >> >> wrote: > >> >> >> > Thanks! How can I tell if I am using async producer? I thought > all > >> the > >> >> >> > sends are async in nature > >> >> >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira < > >> gshap...@cloudera.com > >> >> > > >> >> >> > wrote: > >> >> >> > > >> >> >> >> If you have "auto.create.topics.enable" set to "true" > (default), > >> >> >> >> producing to a topic creates it. > >> >> >> >> > >> >> >> >> Its a bit tricky because the "send" that creates the topic can > >> fail > >> >> >> >> with "leader not found" or similar issue. retrying few times > will > >> >> >> >> eventually succeed as the topic gets created and the leader > gets > >> >> >> >> elected. > >> >> >> >> > >> >> >> >> Is it possible that you are not getting errors because you are > >> using > >> >> >> >> async producer? > >> >> >> >> > >> >> >> >> Also "no messages are delivered" can have many causes. Check if > >> the > >> >> >> >> topic exists using: > >> >> >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 > >> >> >> >> > >> >> >> >> Perhaps the topic was created and the issue is elsewhere (the > >> >> consumer > >> >> >> >> is a usual suspect! perhaps look in the FAQ for tips with that > >> issue) > >> >> >> >> > >> >> >> >> Gwen > >> >> >> >> > >> >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < > >> >> mohitanch...@gmail.com > >> >> >> > > >> >> >> >> wrote: > >> >> >> >> > Is Kafka supposed to throw exception if topic doesn't exist? > It > >> >> >> appears > >> >> >> >> > that there is no exception thrown even though no messages are > >> >> >> delivered > >> >> >> >> and > >> >> >> >> > there are errors logged in Kafka logs. > >> >> >> >> > >> >> >> > >> >> > >> >
Re: Topic doesn't exist exception
There's some good advice here: https://kafka.apache.org/081/ops.html And you may enjoy this post too: http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/ On Fri, Oct 17, 2014 at 5:52 PM, Mohit Anchlia wrote: > Thanks for the info. I see there are tons of parameters but is there a > place that lists some important performance specific parameters? > On Fri, Oct 17, 2014 at 2:43 PM, Gwen Shapira wrote: > >> If I understand correctly (and I'll be happy if someone who knows more >> will jump in and correct me): >> >> The Sync/Async part is not between the producer and the broker. Its >> between you and the producer. The Sync producer takes your message and >> immediately contacts the broker, sends the message, either wait for >> acks or not and returns. The Async producer takes your message and >> immediately returns. The producer will send the message to the broker >> at some time later, batching multiple requests for efficiency and >> throughput. >> >> So yeah, I think you got it mostly right. Just note that the producer >> doesn't wait on .send, the producer executes the send - either >> returning immediately (if async) or when it managed to contact the >> broker (if sync). >> >> Gwen >> >> On Fri, Oct 17, 2014 at 4:38 PM, Mohit Anchlia >> wrote: >> > My understanding of sync is that producer waits on .send until Kafka >> > receives the message. And async means it just dispatches the message >> > without any gurantees that message is delivered. Did I get that part >> right? >> > On Fri, Oct 17, 2014 at 1:28 PM, Gwen Shapira >> wrote: >> > >> >> Sorry if I'm confusing you :) >> >> >> >> Kafka 0.8.1.1 has two producers sync and async. You are using the sync >> >> producer without waiting for acks. I hope this helps? >> >> >> >> Regardless, did you check if the partition got created? are you able >> >> to produce messages? are you able to consume them? >> >> >> >> Gwen >> >> >> >> On Fri, Oct 17, 2014 at 4:13 PM, Mohit Anchlia >> >> wrote: >> >> > Still don't understand the difference. If it's not waiting for the ack >> >> then >> >> > doesn't it make async? >> >> > On Fri, Oct 17, 2014 at 12:55 PM, wrote: >> >> > >> >> >> Its using the sync producer without waiting for any broker to >> >> acknowledge >> >> >> the write. This explains the lack of errors you are seeing. >> >> >> >> >> >> — >> >> >> Sent from Mailbox >> >> >> >> >> >> On Fri, Oct 17, 2014 at 3:15 PM, Mohit Anchlia < >> mohitanch...@gmail.com> >> >> >> wrote: >> >> >> >> >> >> > Little confused :) From one of the examples I am using property >> >> >> > request.required.acks=0, >> >> >> > I thought this sets the producer to be async? >> >> >> > On Fri, Oct 17, 2014 at 11:59 AM, Gwen Shapira < >> gshap...@cloudera.com >> >> > >> >> >> > wrote: >> >> >> >> 0.8.1.1 producer is Sync by default, and you can set >> producer.type to >> >> >> >> async if needed. >> >> >> >> >> >> >> >> On Fri, Oct 17, 2014 at 2:57 PM, Mohit Anchlia < >> >> mohitanch...@gmail.com> >> >> >> >> wrote: >> >> >> >> > Thanks! How can I tell if I am using async producer? I thought >> all >> >> the >> >> >> >> > sends are async in nature >> >> >> >> > On Fri, Oct 17, 2014 at 11:44 AM, Gwen Shapira < >> >> gshap...@cloudera.com >> >> >> > >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> If you have "auto.create.topics.enable" set to "true" >> (default), >> >> >> >> >> producing to a topic creates it. >> >> >> >> >> >> >> >> >> >> Its a bit tricky because the "send" that creates the topic can >> >> fail >> >> >> >> >> with "leader not found" or similar issue. retrying few times >> will >> >> >> >> >> eventually succeed as the topic gets created and the leader >> gets >> >> >> >> >> elected. >> >> >> >> >> >> >> >> >> >> Is it possible that you are not getting errors because you are >> >> using >> >> >> >> >> async producer? >> >> >> >> >> >> >> >> >> >> Also "no messages are delivered" can have many causes. Check if >> >> the >> >> >> >> >> topic exists using: >> >> >> >> >> bin/kafka-topics.sh --list --zookeeper localhost:2181 >> >> >> >> >> >> >> >> >> >> Perhaps the topic was created and the issue is elsewhere (the >> >> >> consumer >> >> >> >> >> is a usual suspect! perhaps look in the FAQ for tips with that >> >> issue) >> >> >> >> >> >> >> >> >> >> Gwen >> >> >> >> >> >> >> >> >> >> On Fri, Oct 17, 2014 at 12:56 PM, Mohit Anchlia < >> >> >> mohitanch...@gmail.com >> >> >> >> > >> >> >> >> >> wrote: >> >> >> >> >> > Is Kafka supposed to throw exception if topic doesn't exist? >> It >> >> >> >> appears >> >> >> >> >> > that there is no exception thrown even though no messages are >> >> >> >> delivered >> >> >> >> >> and >> >> >> >> >> > there are errors logged in Kafka logs. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>
ConsumerOffsetChecker returns negative value for log lag
Hi, I have a Kafka 0.8.1 cluster. I used the ConsumerOffsetChecker tool to check the lag of consumer groups. I found that for some partition, the tool returns negative value for the "lag " column. Is this a known issue that has been seen before? I find that the negative value prevents the consumer consuming the latest events in these partitions. How can we work around the problem? The following is the command: ~/kafka_2.9.2-0.8.1$ bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group topic_partition --zkconnect zk001:2181 --topic the_topic | grep ' -' The following is part of the output. The topic that I am checking has 128 partitions, and the tool returns negative value for 63 partitions. topic_partition event 6 202936733 28822327 * -*174114406 topic_partition_m031_29714_20-0 topic_partition event 10 177322216 36578944 * -*140743272 topic_partition_m032_16773_16-0 topic_partition event 11 187891640 28999350 * -*158892290 topic_partition_m032_16773_17-0 Thanks! -Yu
