New to Kafka

[prabhu v]

Hi,

Can anyone please help me with the video presentations from Kafka experts?

Seems the link provided in Kafka home page
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
is
outdated..

Thanks in advance..

Re: Retry Message Consumption On Database Failure

[Michael Freeman]

Thanks Christian,
  Sending a heartbeat without having to poll would 
also be useful when using a large max.partition.fetch.bytes.

For now I'm just going to shut the consumer down and restart after x period of 
time.

Thanks for your insights. 

Michael

> On 10 Mar 2016, at 18:33, Christian Posta  wrote:
> 
> Yah that's a good point. That was brought up in another thread.
> 
> The granularity of what poll() needs to be addressed. It tries to do too
> many things at once, including heartbeating. Not so sure that's entirely
> necessary.
> 
> On Thu, Mar 10, 2016 at 1:40 AM, Michael Freeman 
> wrote:
> 
>> Thanks Christian,
>>   We would want to retry indefinitely. Or at
>> least for say x minutes. If we don't poll how do we keep the heart beat
>> alive to Kafka. We never want to loose this message and only want to commit
>> to Kafka when the message is in Mongo. That's either as a successful
>> message in a collection or an unsuccessful message in an error collection.
>> 
>> Right now I let the consumer die and don't create a new one for x minutes.
>> This causes a lot of rebalancing.
>> 
>> Michael
>> 
 On 9 Mar 2016, at 21:12, Christian Posta 
>>> wrote:
>>> 
>>> So can you have to decide how long you're willing to "wait" for the mongo
>>> db to come back, and what you'd like to do with that message. So for
>>> example, do you just retry inserting to Mongo for a predefined period of
>>> time? Do you try forever? If you try forever, are you okay with the
>>> consumer threads blocking indefinitely? Or maybe you implement a "circuit
>>> breaker" to shed load to mongo? Or are you willing to stash the message
>>> into a DLQ and move on and try the next message?
>>> 
>>> You don't need to "re-consume" the message do you? Can you just retry
>>> and/or backoff-retry with the message you have? And just do the "commit"
>> of
>>> the offset if successfully?
>>> 
>>> 
>>> 
>>> On Wed, Mar 9, 2016 at 2:00 PM, Michael Freeman 
>>> wrote:
>>> 
 Hey,
  My team is new to Kafka and we are using the examples found at.
>> http://www.confluent.io/blog/tutorial-getting-started-with-the-new-apache-kafka-0.9-consumer-client
 
 We process messages from kafka and persist them to Mongo.
 If Mongo is unavailable we are wondering how we can re-consume the
>> messages
 while we wait for Mongo to come back up.
 
 Right now we commit after the messages for each partition are processed
 (Following the example).
 I have tried a few approaches.
 
 1. Catch the application exception and skip the kafka commit. However
>> the
 next poll does not re consume the messages.
 2. Allow the consumer to fail and restart the consumer. This works but
 causes a rebalance.
 
 Should I attempt to store the offset and parition (in memory) instead
>> and
 attempt to reseek in order to re consume the messages?
 
 Whats the best practice approach in this kind of situation? My priority
>> is
 to never loose a message and to ensure it makes it to Mongo.
>> (Redelivery is
 ok)
 
 Thanks for any help or pointers in the right direction.
 
 Michael
>>> 
>>> 
>>> 
>>> --
>>> *Christian Posta*
>>> twitter: @christianposta
>>> http://www.christianposta.com/blog
>>> http://fabric8.io
> 
> 
> 
> -- 
> *Christian Posta*
> twitter: @christianposta
> http://www.christianposta.com/blog
> http://fabric8.io

Re: Kafka topic deletion still not working well

[Stevo Slavić]

Topic it seems would get deleted but request in ZK to delete topic would
not get cleared even after restarting Kafka cluster.

I'm still investigating why deletion did not complete in the first place
without restarting any nodes. It seems something smelly happens when there
is request to delete more than one topic.

Anyway, I think I found one potential bug in
ReplicaStateMachine.areAllReplicasForTopicDeleted check which could be
cause for not clearing deletion request from ZK even after restart of whole
cluster. Line ReplicaStateMachine.scala#L285


replicaStatesForTopic.forall(_._2 == ReplicaDeletionSuccessful)

which is return value of that function/check, probably should better be
checking for

replicaStatesForTopic.isEmpty || replicaStatesForTopic.forall(_._2 ==
ReplicaDeletionSuccessful)

I noticed it because in controller logs I found entries like:

[2016-03-04 13:27:29,115] DEBUG [Replica state machine on controller 1]:
Are all replicas for topic foo deleted Map()
(kafka.controller.ReplicaStateMachine)

even though normally they look like:

[2016-03-04 09:33:41,036] DEBUG [Replica state machine on controller 1]:
Are all replicas for topic foo deleted
Map([Topic=foo,Partition=0,Replica=0] -> ReplicaDeletionStarted,
[Topic=foo,Partition=0,Replica=3] -> ReplicaDeletionStarted,
[Topic=foo,Partition=0,Replica=1] -> ReplicaDeletionSuccessful)
(kafka.controller.ReplicaStateMachine)

Kind regards,
Stevo Slavic.

On Sun, Mar 6, 2016 at 12:31 AM, Guozhang Wang  wrote:

> Thanks Stevo,
>
> Feel free to paste your findings in KAFKA-2937, we can re-open that ticket
> if necessary.
>
> Guozhang
>
> On Fri, Mar 4, 2016 at 4:38 AM, Stevo Slavić  wrote:
>
> > Hell Apache Kafka community,
> >
> > I'm still investigating an incident; from initial findings topic deletion
> > doesn't seem to work well still with Kafka 0.9.0.1, likely some edge case
> > not covered.
> >
> > Before with 0.8.2.x it used to happen that non-lead replica would be
> stuck
> > in topic deletion process, and workaround was just to restart that node.
> >
> > If I'm not mistaken, that edge case got (or at least is expected to be)
> > fixed in 0.9.0.1 via KAFKA-2937
> > 
> >
> > Request to delete topic continued to be there in ZK even after whole
> > cluster restart - topic seemed not to exist, seemed to actually be
> deleted,
> > but request to delete topic would remain. Had to manually delete request
> > node in ZK.
> >
> > When I have more details, and reproducible use case, will report back.
> >
> > Kind regards,
> > Stevo Slavic.
> >
>
>
>
> --
> -- Guozhang
>

Re: Kafka Streams

[Dick Davies]

Nice - I've read topics on the idea of a database as the 'now' view of a stream
of updates, it's a very powerful concept.

Reminds me of Rich Hickeys talk on DAtomic, if anyone's seen that.



On 10 March 2016 at 21:26, Jay Kreps  wrote:
> Hey all,
>
> Lot's of people have probably seen the ongoing work on Kafka Streams
> happening. There is no real way to design a system like this in a vacuum,
> so we put up a blog, some snapshot docs, and something you can download and
> use easily to get feedback:
>
> http://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple
>
> We'd love comments or thoughts from anyone...
>
> -Jay

Re: KafkaConsumer#poll not returning records for all partitions of topic in single call

[Helleren, Erik]

The partitions enable scalability. Consumers and produces know which
partition records belong in based on their key (or manual assignment),
which makes it very easy to scale up your kafka cluster or a consuming
cluster.

The ordering problem is one that I have faced, and have a workaround.
Just keep in mind that it does limit your ability to scale after a certain
point.

So first, lets assume that that ordering only maters per producer.  This
is kind of a standard assumption in most distributed, scaleable, and
performant systems.  Given that assumption, you can either set the key
data of each message to be a producer identifier or use manual partition
assignment to ensure per producer ordering.  The choice here depends on
message volume, and the nature of your producers.  Number Producers must
be >= number of partitions.

On the consumption side, since any consumer subscribes to a full
partition, its guaranteed to read message in the same order that any
specific producer produced those messages.  But there is an implicit
coupling to scaling the consumer and scaling the producer count.  So if
the consumer is slower than the producer you might get in trouble.

On 3/11/16, 1:38 AM, "Gerard Klijs"  wrote:

>I noticed a similar effect with a test tool, which checked if the order
>the
>records were produced in, was the same as the order in which they were
>consumed. Using only one partition it works fine, but using multiple
>partitions the order gets messed up. If I'm right this is by design, but I
>would like to hear some feedback about this. Because messages with the
>same
>key, end up in the same partition, if you have multiple partitions, only
>the order within a partition is the same as the order they where produced
>in. But when consuming form multiple partitions the order could be
>different.
>
>If this is true it would be interesting what you should do when you have a
>topic were the order needs to be kept the same, and needs to be consumed
>by
>more then one consumer at a time?
>
>On Fri, Mar 11, 2016 at 5:50 AM Ewen Cheslack-Postava 
>wrote:
>
>> You definitely *might* see data from multiple partitions, and that
>>won't be
>> uncommon once you start processing data. However, there is no guarantee.
>>
>> In practice, it may be unlikely to see data for both partitions on the
>> first call to poll() for a simple reason: poll() will return as soon as
>>any
>> data for any partition is available. Unless things are timed just right,
>> you're probably making requests to different brokers for data in the
>> different partitions. These requests won't be perfectly aligned -- one
>>of
>> them will get a response first and the poll() will be able to return
>>with
>> some data. Since only the one response will have been received, only one
>> partition will get data.
>>
>> After the first poll, you probably spend some time processing that data
>> before you call poll again. However, another request has been sent out
>>to
>> the broker that returned data faster and the other request also gets
>> returned. So on the next poll, you might be more likely to see data from
>> both partitions.
>>
>> So you're right: there's no hard guarantee, and you shouldn't write your
>> consumer code to assume that data will be returned for all partitions.
>>(And
>> you can't assume that anyway; what if no new data had been published to
>>one
>> of the partitions?). However, many times you will see data from multiple
>> partitions.
>>
>> -Ewen
>>
>> On Thu, Mar 10, 2016 at 11:21 AM, Shrijeet Paliwal <
>> shrijeet.pali...@gmail.com> wrote:
>>
>> > Version: 0.9.0.1
>> >
>> > I have a test which creates two partitions in a topic, writes data to
>> both
>> > partitions. Then a single consumer subscribes to the topic, verifies
>>that
>> > it has got the assignment of both partitions in that topic & finally
>> issues
>> > a poll. The firs poll always comes back with records of only one
>> partition.
>> > I need to poll one more time to get records for the second partition.
>>The
>> > poll timeout has no effect on this.
>> >
>> > Unless I've misunderstood the contract - the first poll *could* have
>> > returned records for the both the partitions. After-all poll
>> > returns ConsumerRecords, which is a map of topic_partitions -->
>> > records
>> >
>> > I acknowledge that API does not make any hard guarantees that align
>>with
>> my
>> > expectation but  looks like API was crafted to support multiple
>> partitions
>> > & topics in single call. Is there an implementation detail which
>> restricts
>> > this? Is there a configuration which is controlling what gets fetched?
>> >
>> > --
>> > Shrijeet
>> >
>>
>>
>>
>> --
>> Thanks,
>> Ewen
>>



NOTICE: This message, and any attachments, are for the intended recipient(s) 
only, may contain information that is privileged, confidential and/or 
proprietary and subject to important terms and conditions available at 
E-Communication 
Disclaimer

New to Kafka

[prabhu v]

Hi,

Can anyone please help me with the video presentations from Kafka experts?

Seems the link provided in Kafka home page
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
is outdated..

Thanks in advance..

Re: Kafka topic deletion still not working well

[Mayuresh Gharat]

kafka-2937 is different from this I think. Kafka-2937 deals with the delete
topic getting stuck because the LeaderAndISR in ZK was updated by a
controller and then the controller dies and the new controller gets in to
the exception and never completes deleting the topic. The topic existed in
the cluster and was also marked for delete.
The case reported here is that the topic does not exist in cluster but is
marked for delete.
Am I right in understanding?

Thanks,

Mayuresh

On Fri, Mar 11, 2016 at 5:30 AM, Stevo Slavić  wrote:

> Topic it seems would get deleted but request in ZK to delete topic would
> not get cleared even after restarting Kafka cluster.
>
> I'm still investigating why deletion did not complete in the first place
> without restarting any nodes. It seems something smelly happens when there
> is request to delete more than one topic.
>
> Anyway, I think I found one potential bug in
> ReplicaStateMachine.areAllReplicasForTopicDeleted check which could be
> cause for not clearing deletion request from ZK even after restart of whole
> cluster. Line ReplicaStateMachine.scala#L285
> <
> https://github.com/sslavic/kafka/blob/trunk/core/src/main/scala/kafka/controller/ReplicaStateMachine.scala#L285
> >
>
> replicaStatesForTopic.forall(_._2 == ReplicaDeletionSuccessful)
>
> which is return value of that function/check, probably should better be
> checking for
>
> replicaStatesForTopic.isEmpty || replicaStatesForTopic.forall(_._2 ==
> ReplicaDeletionSuccessful)
>
> I noticed it because in controller logs I found entries like:
>
> [2016-03-04 13:27:29,115] DEBUG [Replica state machine on controller 1]:
> Are all replicas for topic foo deleted Map()
> (kafka.controller.ReplicaStateMachine)
>
> even though normally they look like:
>
> [2016-03-04 09:33:41,036] DEBUG [Replica state machine on controller 1]:
> Are all replicas for topic foo deleted
> Map([Topic=foo,Partition=0,Replica=0] -> ReplicaDeletionStarted,
> [Topic=foo,Partition=0,Replica=3] -> ReplicaDeletionStarted,
> [Topic=foo,Partition=0,Replica=1] -> ReplicaDeletionSuccessful)
> (kafka.controller.ReplicaStateMachine)
>
> Kind regards,
> Stevo Slavic.
>
> On Sun, Mar 6, 2016 at 12:31 AM, Guozhang Wang  wrote:
>
> > Thanks Stevo,
> >
> > Feel free to paste your findings in KAFKA-2937, we can re-open that
> ticket
> > if necessary.
> >
> > Guozhang
> >
> > On Fri, Mar 4, 2016 at 4:38 AM, Stevo Slavić  wrote:
> >
> > > Hell Apache Kafka community,
> > >
> > > I'm still investigating an incident; from initial findings topic
> deletion
> > > doesn't seem to work well still with Kafka 0.9.0.1, likely some edge
> case
> > > not covered.
> > >
> > > Before with 0.8.2.x it used to happen that non-lead replica would be
> > stuck
> > > in topic deletion process, and workaround was just to restart that
> node.
> > >
> > > If I'm not mistaken, that edge case got (or at least is expected to be)
> > > fixed in 0.9.0.1 via KAFKA-2937
> > > 
> > >
> > > Request to delete topic continued to be there in ZK even after whole
> > > cluster restart - topic seemed not to exist, seemed to actually be
> > deleted,
> > > but request to delete topic would remain. Had to manually delete
> request
> > > node in ZK.
> > >
> > > When I have more details, and reproducible use case, will report back.
> > >
> > > Kind regards,
> > > Stevo Slavic.
> > >
> >
> >
> >
> > --
> > -- Guozhang
> >
>



-- 
-Regards,
Mayuresh R. Gharat
(862) 250-7125

Re: Kafka topic deletion still not working well

[Mayuresh Gharat]

Hi Stevo,

Let me know if we want to open Kafka-2937 again. I can include the above
finding in to the patch or you want to create a separate JIra for this.

Thanks,

Mayuresh

On Fri, Mar 11, 2016 at 7:53 AM, Mayuresh Gharat  wrote:

> kafka-2937 is different from this I think. Kafka-2937 deals with the
> delete topic getting stuck because the LeaderAndISR in ZK was updated by a
> controller and then the controller dies and the new controller gets in to
> the exception and never completes deleting the topic. The topic existed in
> the cluster and was also marked for delete.
> The case reported here is that the topic does not exist in cluster but is
> marked for delete.
> Am I right in understanding?
>
> Thanks,
>
> Mayuresh
>
> On Fri, Mar 11, 2016 at 5:30 AM, Stevo Slavić  wrote:
>
>> Topic it seems would get deleted but request in ZK to delete topic would
>> not get cleared even after restarting Kafka cluster.
>>
>> I'm still investigating why deletion did not complete in the first place
>> without restarting any nodes. It seems something smelly happens when there
>> is request to delete more than one topic.
>>
>> Anyway, I think I found one potential bug in
>> ReplicaStateMachine.areAllReplicasForTopicDeleted check which could be
>> cause for not clearing deletion request from ZK even after restart of
>> whole
>> cluster. Line ReplicaStateMachine.scala#L285
>> <
>> https://github.com/sslavic/kafka/blob/trunk/core/src/main/scala/kafka/controller/ReplicaStateMachine.scala#L285
>> >
>>
>> replicaStatesForTopic.forall(_._2 == ReplicaDeletionSuccessful)
>>
>> which is return value of that function/check, probably should better be
>> checking for
>>
>> replicaStatesForTopic.isEmpty || replicaStatesForTopic.forall(_._2 ==
>> ReplicaDeletionSuccessful)
>>
>> I noticed it because in controller logs I found entries like:
>>
>> [2016-03-04 13:27:29,115] DEBUG [Replica state machine on controller 1]:
>> Are all replicas for topic foo deleted Map()
>> (kafka.controller.ReplicaStateMachine)
>>
>> even though normally they look like:
>>
>> [2016-03-04 09:33:41,036] DEBUG [Replica state machine on controller 1]:
>> Are all replicas for topic foo deleted
>> Map([Topic=foo,Partition=0,Replica=0] -> ReplicaDeletionStarted,
>> [Topic=foo,Partition=0,Replica=3] -> ReplicaDeletionStarted,
>> [Topic=foo,Partition=0,Replica=1] -> ReplicaDeletionSuccessful)
>> (kafka.controller.ReplicaStateMachine)
>>
>> Kind regards,
>> Stevo Slavic.
>>
>> On Sun, Mar 6, 2016 at 12:31 AM, Guozhang Wang 
>> wrote:
>>
>> > Thanks Stevo,
>> >
>> > Feel free to paste your findings in KAFKA-2937, we can re-open that
>> ticket
>> > if necessary.
>> >
>> > Guozhang
>> >
>> > On Fri, Mar 4, 2016 at 4:38 AM, Stevo Slavić  wrote:
>> >
>> > > Hell Apache Kafka community,
>> > >
>> > > I'm still investigating an incident; from initial findings topic
>> deletion
>> > > doesn't seem to work well still with Kafka 0.9.0.1, likely some edge
>> case
>> > > not covered.
>> > >
>> > > Before with 0.8.2.x it used to happen that non-lead replica would be
>> > stuck
>> > > in topic deletion process, and workaround was just to restart that
>> node.
>> > >
>> > > If I'm not mistaken, that edge case got (or at least is expected to
>> be)
>> > > fixed in 0.9.0.1 via KAFKA-2937
>> > > 
>> > >
>> > > Request to delete topic continued to be there in ZK even after whole
>> > > cluster restart - topic seemed not to exist, seemed to actually be
>> > deleted,
>> > > but request to delete topic would remain. Had to manually delete
>> request
>> > > node in ZK.
>> > >
>> > > When I have more details, and reproducible use case, will report back.
>> > >
>> > > Kind regards,
>> > > Stevo Slavic.
>> > >
>> >
>> >
>> >
>> > --
>> > -- Guozhang
>> >
>>
>
>
>
> --
> -Regards,
> Mayuresh R. Gharat
> (862) 250-7125
>



-- 
-Regards,
Mayuresh R. Gharat
(862) 250-7125

Re: Kafka topic deletion still not working well

[Stevo Slavić]

Sorry, I do not know if this is related to KAFKA-2937, I let you judge and
decide whether ticket needs to be reopened or new one created.

I'm still missing full picture what was happening but here are more pieces.

1) Topic foo was created (likely with Kafka 0.8.2.x). Topic foo was never
used (no messages published to it ever).
2) Topic bar was created with Kafka 0.9.0.1
3) Deletion for topic foo was requested, and replica deletion got stuck
(see [1] server.log fragment)
4) Deletion for topic bar was requested, one bar replica was on same broker
as replica for foo whose deletion got stuck, and deletion for bar replica
was never even tried
5) Topics got in non-deletable state (see [2] controller.log fragment)

As you can see from [1] replica had one state in cache, while actual in ZK
was different. I'm not sure why /brokers/topics/foo/partitions/0/state did
not

[1] replica server.log fragment
...
[2016-03-04 09:42:03,495] INFO [ReplicaFetcherManager on broker 1] Removed
fetcher for partitions [foo,0] (kafka.server.ReplicaFetcherManager)
[2016-03-04 09:42:03,533] INFO [ReplicaFetcherManager on broker 1] Removed
fetcher for partitions [foo,0] (kafka.server.ReplicaFetcherManager)
[2016-03-04 09:42:13,894] INFO Partition [foo,0] on broker 1: Shrinking ISR
for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
[2016-03-04 09:42:13,897] WARN Conditional update of path
/brokers/topics/foo/partitions/0/state with data
{"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
and expected version 68 failed due to
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
[2016-03-04 09:42:13,898] INFO Partition [foo,0] on broker 1: Cached
zkVersion [68] not equal to that in zookeeper, skip updating ISR
(kafka.cluster.Partition)
[2016-03-04 09:42:23,894] INFO Partition [foo,0] on broker 1: Shrinking ISR
for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
[2016-03-04 09:42:23,897] WARN Conditional update of path
/brokers/topics/foo/partitions/0/state with data
{"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
and expected version 68 failed due to
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
[2016-03-04 09:42:23,897] INFO Partition [foo,0] on broker 1: Cached
zkVersion [68] not equal to that in zookeeper, skip updating ISR
(kafka.cluster.Partition)
[2016-03-04 09:42:33,894] INFO Partition [foo,0] on broker 1: Shrinking ISR
for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
[2016-03-04 09:42:33,897] WARN Conditional update of path
/brokers/topics/foo/partitions/0/state with data
{"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
and expected version 68 failed due to
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
[2016-03-04 09:42:33,897] INFO Partition [foo,0] on broker 1: Cached
zkVersion [68] not equal to that in zookeeper, skip updating ISR
(kafka.cluster.Partition)
...

[2] controller.log fragment
...
[2016-03-04 09:59:06,753] DEBUG [Topic Deletion Manager 1], Deletion failed
for replicas [Topic=bar,Partition=0,Replica=0]. Halting deletion for topics
Set(bar) (kafka.controller.TopicDeletionManager)
[2016-03-04 09:59:06,753] INFO [Replica state machine on controller 1]:
Invoking state change to ReplicaDeletionIneligible for replicas
[Topic=bar,Partition=0,Replica=0] (kafka.controller.ReplicaStateMachine)
[2016-03-04 09:59:06,754] INFO [Topic Deletion Manager 1], Halted deletion
of topics bar (kafka.controller.TopicDeletionManager)
...

On Fri, Mar 11, 2016 at 5:00 PM, Mayuresh Gharat  wrote:

> Hi Stevo,
>
> Let me know if we want to open Kafka-2937 again. I can include the above
> finding in to the patch or you want to create a separate JIra for this.
>
> Thanks,
>
> Mayuresh
>
> On Fri, Mar 11, 2016 at 7:53 AM, Mayuresh Gharat <
> gharatmayures...@gmail.com
> > wrote:
>
> > kafka-2937 is different from this I think. Kafka-2937 deals with the
> > delete topic getting stuck because the LeaderAndISR in ZK was updated by
> a
> > controller and then the controller dies and the new controller gets in to
> > the exception and never completes deleting the topic. The topic existed
> in
> > the cluster and was also marked for delete.
> > The case reported here is that the topic does not exist in cluster but is
> > marked for delete.
> > Am I right in understanding?
> >
> > Thanks,
> >
> > Mayuresh
> >
> > On Fri, Mar 11, 2016 at 5:30 AM, Stevo Slavić  wrote:
> >
> >> Topic it seems would get deleted but request in ZK to delete topic would
> >> not get cleared even after restarting Kafka cluster.
> >>
> >> I'm still investigating why deletion did not complete in the first place
> >> without restarting any nodes. It seems something smelly happens when

Re: Kafka topic deletion still not working well

[Stevo Slavić]

Didn't finish sentence, wanted to change font but managed to hit Send
button instead...


As you can see from [1] replica server.log fragment, replica had one state
in cache, while actual in ZK was different (node didn't exist anymore). I'm
not sure why /brokers/topics/foo/partitions/0/state node did not exist in
ZK. I mentioned that foo was likely created with Kafka 0.8.2.x - maybe
different Kafka versions use different metadata (ZK dir layout), and
0.9.0.1 when deleting expected something to exist in ZK while it didn't
since topic was created with 0.8.2.x.

But I guess this Kafka version difference (during topic creation and at
deletion) is unlikely to be the cause, since replica had state cached so
state node is likely to have existed at some point before deletion request.
Not sure what could have deleted it. Maybe some other part of distributed
topic deletion process deleted the state node. Will check more logs, Kafka
and ZK, if I can find what deleted the state node. Any ideas?

On Fri, Mar 11, 2016 at 5:22 PM, Stevo Slavić  wrote:

> Sorry, I do not know if this is related to KAFKA-2937, I let you judge and
> decide whether ticket needs to be reopened or new one created.
>
> I'm still missing full picture what was happening but here are more pieces.
>
> 1) Topic foo was created (likely with Kafka 0.8.2.x). Topic foo was never
> used (no messages published to it ever).
> 2) Topic bar was created with Kafka 0.9.0.1
> 3) Deletion for topic foo was requested, and replica deletion got stuck
> (see [1] server.log fragment)
> 4) Deletion for topic bar was requested, one bar replica was on same
> broker as replica for foo whose deletion got stuck, and deletion for bar
> replica was never even tried
> 5) Topics got in non-deletable state (see [2] controller.log fragment)
>
> As you can see from [1] replica had one state in cache, while actual in ZK
> was different. I'm not sure why /brokers/topics/foo/partitions/0/state
> did not
>
> [1] replica server.log fragment
> ...
> [2016-03-04 09:42:03,495] INFO [ReplicaFetcherManager on broker 1] Removed
> fetcher for partitions [foo,0] (kafka.server.ReplicaFetcherManager)
> [2016-03-04 09:42:03,533] INFO [ReplicaFetcherManager on broker 1] Removed
> fetcher for partitions [foo,0] (kafka.server.ReplicaFetcherManager)
> [2016-03-04 09:42:13,894] INFO Partition [foo,0] on broker 1: Shrinking
> ISR for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
> [2016-03-04 09:42:13,897] WARN Conditional update of path
> /brokers/topics/foo/partitions/0/state with data
> {"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
> and expected version 68 failed due to
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
> [2016-03-04 09:42:13,898] INFO Partition [foo,0] on broker 1: Cached
> zkVersion [68] not equal to that in zookeeper, skip updating ISR
> (kafka.cluster.Partition)
> [2016-03-04 09:42:23,894] INFO Partition [foo,0] on broker 1: Shrinking
> ISR for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
> [2016-03-04 09:42:23,897] WARN Conditional update of path
> /brokers/topics/foo/partitions/0/state with data
> {"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
> and expected version 68 failed due to
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
> [2016-03-04 09:42:23,897] INFO Partition [foo,0] on broker 1: Cached
> zkVersion [68] not equal to that in zookeeper, skip updating ISR
> (kafka.cluster.Partition)
> [2016-03-04 09:42:33,894] INFO Partition [foo,0] on broker 1: Shrinking
> ISR for partition [foo,0] from 1,3,2 to 1 (kafka.cluster.Partition)
> [2016-03-04 09:42:33,897] WARN Conditional update of path
> /brokers/topics/foo/partitions/0/state with data
> {"controller_epoch":53,"leader":1,"version":1,"leader_epoch":34,"isr":[1]}
> and expected version 68 failed due to
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /brokers/topics/foo/partitions/0/state (kafka.utils.ZkUtils)
> [2016-03-04 09:42:33,897] INFO Partition [foo,0] on broker 1: Cached
> zkVersion [68] not equal to that in zookeeper, skip updating ISR
> (kafka.cluster.Partition)
> ...
>
> [2] controller.log fragment
> ...
> [2016-03-04 09:59:06,753] DEBUG [Topic Deletion Manager 1], Deletion
> failed for replicas [Topic=bar,Partition=0,Replica=0]. Halting deletion for
> topics Set(bar) (kafka.controller.TopicDeletionManager)
> [2016-03-04 09:59:06,753] INFO [Replica state machine on controller 1]:
> Invoking state change to ReplicaDeletionIneligible for replicas
> [Topic=bar,Partition=0,Replica=0] (kafka.controller.ReplicaStateMachine)
> [2016-03-04 09:59:06,754] INFO [Topic Deletion Manager 1], Halted deletion
> of topics bar (kafka.controller.TopicDeletionManager)
> ...
>
> On Fri, Mar 11, 2016 at 5:00 PM, Ma

Re: New to Kafka

[Gaurav Agarwal]

What u need prabhu from presentation, go to YouTube u will get presentation
or search Kafka example u will get .
On Mar 11, 2016 9:12 PM, "prabhu v"  wrote:

> Hi,
>
> Can anyone please help me with the video presentations from Kafka experts?
>
> Seems the link provided in Kafka home page
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
> is outdated..
>
> Thanks in advance..
>

Re: Kafka broker decommission steps

[Alexis Midon]

I think the "scripts for operations" should be APIs that provides higher
level operations. It would be simpler and more powerful.


On Thu, Mar 10, 2016 at 10:54 AM Guozhang Wang  wrote:

> Thanks Alexis, these are good points.
>
> We are aware of the partition assignment json problem and trying to improve
> it; as for packaging / configs etc I think the goal of the OS Kafka package
> itself is to provide universal and simple barebone scripts for operations,
> and users can wrap / customize themselves as they need.
>
> Guozhang
>
> On Sun, Mar 6, 2016 at 10:16 AM, Alexis Midon <
> alexis.mi...@airbnb.com.invalid> wrote:
>
> > also:
> > . the command line tool packaging is not ideal, you have to download the
> > (big) kafka zip, set paths, etc.
> >
> > . the details of the zk cluster and kafka cluster must be repeated on the
> > command line.
> >
> > with kafkat, you can use `gem install`, and a store the cluster details
> in
> > a config file.
> >
> > On Sun, Mar 6, 2016 at 10:12 AM Alexis Midon 
> > wrote:
> >
> > > My recollection is that you have to come up with the partition
> assignment
> > > yourself, and pass the json file as an argument.
> > > This is quite error prone, especially during an outage.
> > >
> > > we quickly wrote kafkat to have a simple commands that would let us
> > > express needs without having to deal with the assignment plan: "move
> > topic
> > > X on these brokers", "retire broker X", "set replication factor of
> topic
> > X
> > > to R", etc
> > >
> > >
> > >
> > >
> > > On Sat, Mar 5, 2016 at 3:33 PM Guozhang Wang 
> wrote:
> > >
> > >> Hello Alexis,
> > >>
> > >> Could you share your findings about the command line tool? We can try
> to
> > >> resolve if there's any issues.
> > >>
> > >> Guozhang
> > >>
> > >> On Fri, Mar 4, 2016 at 3:13 PM, Alexis Midon <
> > >> alexis.mi...@airbnb.com.invalid> wrote:
> > >>
> > >> > The command line tool that ships with Kafka is error prone.
> > >> >
> > >> > Our standard procedure is:
> > >> > 1. spin up the new broker
> > >> > 2. use `kafkat drain  [--brokers ]
> > >> > 3. shut down old broker
> > >> >
> > >> > The `drain` command will generate and submit a partition assignment
> > plan
> > >> > where the new broker id replaces the old one. It's pretty much a
> > >> "gsub(old,
> > >> > new)".
> > >> >
> > >> > We do it regularly. It's almost a mundane operation. The only
> > challenge
> > >> is
> > >> > the volume of data being transferred over the network. Since there
> is
> > no
> > >> > throttling mechanism, the network is sometime saturated which might
> > >> impact
> > >> > other consumers/producers
> > >> >
> > >> > See https://github.com/airbnb/kafkat
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Mar 4, 2016 at 7:28 AM Todd Palino 
> wrote:
> > >> >
> > >> > > To answer your questions…
> > >> > >
> > >> > > 1 - Not in the way you want it to. There is a setting for
> automatic
> > >> > leader
> > >> > > election (which I do not recommend anyone use at this time), but
> all
> > >> that
> > >> > > does is pick which of the currently assigned replicas should be
> the
> > >> > leader.
> > >> > > It does not reassign partitions from one broker to another. Kafka
> > does
> > >> > not
> > >> > > have a facility for doing this automatically.
> > >> > >
> > >> > > 2 - No. The most you can do is move all the partitions off and
> then
> > >> > > immediately shut down the broker process. Any broker that is live
> in
> > >> the
> > >> > > cluster can, and will, get partitions assigned to it by the
> > >> controller.
> > >> > >
> > >> > > For what you want to do, you need you use the partition
> reassignment
> > >> > > command line tool that ships with Kafka to reassign partitions
> from
> > >> the
> > >> > old
> > >> > > broker to the new one. Once that is complete, you can double check
> > >> that
> > >> > the
> > >> > > old broker has no partitions left and shut it down. I have a tool
> > >> that we
> > >> > > use internally to make this a lot easier, and I’m in the process
> of
> > >> > getting
> > >> > > a repository set up to make it available via open source. It
> allows
> > >> for
> > >> > > more easily removing and adding brokers, and rebalancing
> partitions
> > >> in a
> > >> > > cluster without having to craft the reassignments by hand.
> > >> > >
> > >> > > -Todd
> > >> > >
> > >> > >
> > >> > > On Fri, Mar 4, 2016 at 5:07 AM, Muqtafi Akhmad <
> > muqt...@traveloka.com
> > >> >
> > >> > > wrote:
> > >> > >
> > >> > > > dear Kafka users,
> > >> > > >
> > >> > > > I have some questions regarding decommissioning kafka broker
> node
> > >> and
> > >> > > > replacing it with the new one. Lets say that we have three
> broker
> > >> nodes
> > >> > > and
> > >> > > > each topic in Kafka has replication factor = 3, we upgrade one
> > node
> > >> > with
> > >> > > > the following steps :
> > >> > > > 1. add one broker node to cluster
> > >> > > > 2. shutdown old broker node
> > >> > > >
> > >> > > > My questions are
> > >> > > 

Re: New to Kafka

[Christian Posta]

What exactly is outdated? Are you not able to grok Kafka with the current
presentations?

On Fri, Mar 11, 2016 at 1:01 AM, prabhu v  wrote:

> Hi,
>
> Can anyone please help me with the video presentations from Kafka experts?
>
> Seems the link provided in Kafka home page
>
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
> is
> outdated..
>
> Thanks in advance..
>



-- 
*Christian Posta*
twitter: @christianposta
http://www.christianposta.com/blog
http://fabric8.io

Re: seekToBeginning doesn't work without auto.offset.reset

[Guozhang Wang]

Cody, Mansi:

All good points! Let me try to answer them one-by-one.

About this specific issue, as I suggested in the JIRA we can separate the
case about resetting offset upon initializing a partition to fetch, from
the case that fetching offset out-of-range in the auto.offset.reset config.
These two scenarios are indeed quite different and it's reasonable treating
them differently.

About passing a consumer context to the rebalance callback's constructor,
we left it for user's flexibility: if you want to use Kafka to commit
offsets, for example, then you pass the consumer reference to the callback;
if you use an external service to store offsets, you can pass a JDBC
connector, for example, to the callback; for some data mirroring you can
even pass in another producer client into it. Always enforcing the consumer
context could be convenient (i.e. you do not need to pass in the argument
to the constructor yourself) for some use cases, but not necessarily all.

About wrapping coordination protocols (partition assignment, heartbeat)
inside "poll()" behind the scene, we implemented the APIs in this way in
order to abstract the underlying details from the users, and also to
provide a simple "single-thread-poll-loop" design pattern in the new
Consumer. We realized that it does actually make some of the use cases more
awkward, and are working on improving these cases with improved APIs as
well. Let us know if you have any suggestions about this.

Guozhang






On Thu, Mar 10, 2016 at 7:53 AM, Mansi Shah  wrote:

> I second the need for having a consumer context passed to rebalance
> callback. I have ran into issues several times because of that.
>
> About - subscribe vs assign - I have not read through your spark code yet
> (will do by eod), so I am not sure what you mean (other than I do agree
> that new partitions should be consumed automatically). I guess we can
> continue this discussion on the spark list then :-)
>
> Thanks
> Mansi.
>
> On Thu, Mar 10, 2016 at 7:43 AM, Cody Koeninger 
> wrote:
>
> > Mansi, I'd agree that the fact that everything is tied up in poll
> > seems like the source of the awkward behavior.
> >
> > Regarding assign vs subscribe, most people using the spark integration
> > are just going to want to provide a topic name, not go figure out a
> > bunch of partitions.  They're also going to be surprised if things
> > suddenly blow up once a partition is added, or that partition doesn't
> > start being consumed (we already have that second issue today).
> >
> > Thats why separating the behavior of auto offset reset seems like the
> > best idea I've heard so far.
> >
> > Consumer rebalance listeners are still probably going to be necessary
> > for people who are storing offsets externally.
> >
> > On Thu, Mar 10, 2016 at 9:27 AM, Mansi Shah 
> > wrote:
> > > Guozhang
> > >
> > > Sorry for joining the party a little late. I have been thinking about
> > this
> > > whole awkward behavior of having to call poll(0) to actually make the
> > > underlying subscriptions take effect. Is the core reason for this
> design
> > > the fact that poll is also the actual heartbeat and you want to make
> the
> > > listener group assignments through poll - so that timeouts and
> > > reassignments can all go through poll? So I think clubbing liveness
> with
> > > poll (which in effect clubs consumer group assignments and hence
> metadata
> > > fetch with poll) is the real cause of this design. Were there issues
> > where
> > > you were seeing active consumers not calling poll that led to this
> design
> > > choice? I tried to look for a relevant JIRA but could not find one -
> can
> > > you please point me to something if you have it handy?
> > >
> > > Btw this would also means that your proposal to do the actual
> assignments
> > > through seek might not be ideal since there can still be indefinite
> time
> > > between seek and poll (just like between subscribe and poll) and the
> > > consumer could timeout even before the first poll is called?
> > >
> > >
> > > @Cody in your case if you really have only one consumer and it is going
> > to
> > > get all the partitions of the topic anyway - then you might as well
> > > subscribe using "assign" call instead of "subscribe" call. That will
> make
> > > at least your code cleaner and I do not think you are gaining anything
> > with
> > > the listener group functionality anyway?
> > >
> > > - Mansi.
> > >
> > >
> > >
> > > On Wed, Mar 9, 2016 at 8:35 PM, Guozhang Wang 
> > wrote:
> > >
> > >> In order to do anything meaningful with the consumer itself in
> rebalance
> > >> callback (e.g. commit offset), you would need to hold on the consumer
> > >> reference; admittedly it sounds a bit awkward, but by design we choose
> > to
> > >> not enforce it in the interface itself.
> > >>
> > >> Guozhang
> > >>
> > >> On Wed, Mar 9, 2016 at 3:39 PM, Cody Koeninger 
> > wrote:
> > >>
> > >> > So what about my comments regarding the consumer rebalance listener
> > >> > interfac

Re: Kafka Streams

[David Buschman]

@Jay, I currently use reactive-kaka for my Kafka sources and sinks in my stream 
processing apps. I was interested to see if this new stream API would make that 
setup easier/simpler/better in the future when it becomes available.

How does the Streams API handle the commit offsets? Since you are processing 
"1-at-a-time”, is it auto magic on commit handling at the beginning/end of the 
processing or can we specify where in the processing an offset commit happens? 

Thanks,
DaVe.

David Buschman
d...@timeli.io



> On Mar 11, 2016, at 7:21 AM, Dick Davies  wrote:
> 
> Nice - I've read topics on the idea of a database as the 'now' view of a 
> stream
> of updates, it's a very powerful concept.
> 
> Reminds me of Rich Hickeys talk on DAtomic, if anyone's seen that.
> 
> 
> 
> On 10 March 2016 at 21:26, Jay Kreps  wrote:
>> Hey all,
>> 
>> Lot's of people have probably seen the ongoing work on Kafka Streams
>> happening. There is no real way to design a system like this in a vacuum,
>> so we put up a blog, some snapshot docs, and something you can download and
>> use easily to get feedback:
>> 
>> http://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple
>> 
>> We'd love comments or thoughts from anyone...
>> 
>> -Jay

Re: Kafka Streams

[Jay Kreps]

Hey David,

The commit always happens at a "safe point", when the local portion of the
processing topology has fully processed a set of inputs. The frequency is
controlled by the property commit.interval.ms.

-Jay

On Fri, Mar 11, 2016 at 9:28 AM, David Buschman 
wrote:

> @Jay, I currently use reactive-kaka for my Kafka sources and sinks in my
> stream processing apps. I was interested to see if this new stream API
> would make that setup easier/simpler/better in the future when it becomes
> available.
>
> How does the Streams API handle the commit offsets? Since you are
> processing "1-at-a-time”, is it auto magic on commit handling at the
> beginning/end of the processing or can we specify where in the processing
> an offset commit happens?
>
> Thanks,
> DaVe.
>
> David Buschman
> d...@timeli.io
>
>
>
> > On Mar 11, 2016, at 7:21 AM, Dick Davies  wrote:
> >
> > Nice - I've read topics on the idea of a database as the 'now' view of a
> stream
> > of updates, it's a very powerful concept.
> >
> > Reminds me of Rich Hickeys talk on DAtomic, if anyone's seen that.
> >
> >
> >
> > On 10 March 2016 at 21:26, Jay Kreps  wrote:
> >> Hey all,
> >>
> >> Lot's of people have probably seen the ongoing work on Kafka Streams
> >> happening. There is no real way to design a system like this in a
> vacuum,
> >> so we put up a blog, some snapshot docs, and something you can download
> and
> >> use easily to get feedback:
> >>
> >>
> http://www.confluent.io/blog/introducing-kafka-streams-stream-processing-made-simple
> >>
> >> We'd love comments or thoughts from anyone...
> >>
> >> -Jay
>
>

Re: seekToBeginning doesn't work without auto.offset.reset

[Cody Koeninger]

Is there a KIP or Jira related to " working on improving these cases
with improved APIs " ?

I saw that there was some discussion of it in KIP-41, but that seemed
to have been resolved in favor of keeping everything inside of poll()

On Fri, Mar 11, 2016 at 11:17 AM, Guozhang Wang  wrote:
> Cody, Mansi:
>
> All good points! Let me try to answer them one-by-one.
>
> About this specific issue, as I suggested in the JIRA we can separate the
> case about resetting offset upon initializing a partition to fetch, from
> the case that fetching offset out-of-range in the auto.offset.reset config.
> These two scenarios are indeed quite different and it's reasonable treating
> them differently.
>
> About passing a consumer context to the rebalance callback's constructor,
> we left it for user's flexibility: if you want to use Kafka to commit
> offsets, for example, then you pass the consumer reference to the callback;
> if you use an external service to store offsets, you can pass a JDBC
> connector, for example, to the callback; for some data mirroring you can
> even pass in another producer client into it. Always enforcing the consumer
> context could be convenient (i.e. you do not need to pass in the argument
> to the constructor yourself) for some use cases, but not necessarily all.
>
> About wrapping coordination protocols (partition assignment, heartbeat)
> inside "poll()" behind the scene, we implemented the APIs in this way in
> order to abstract the underlying details from the users, and also to
> provide a simple "single-thread-poll-loop" design pattern in the new
> Consumer. We realized that it does actually make some of the use cases more
> awkward, and are working on improving these cases with improved APIs as
> well. Let us know if you have any suggestions about this.
>
> Guozhang
>
>
>
>
>
>
> On Thu, Mar 10, 2016 at 7:53 AM, Mansi Shah  wrote:
>
>> I second the need for having a consumer context passed to rebalance
>> callback. I have ran into issues several times because of that.
>>
>> About - subscribe vs assign - I have not read through your spark code yet
>> (will do by eod), so I am not sure what you mean (other than I do agree
>> that new partitions should be consumed automatically). I guess we can
>> continue this discussion on the spark list then :-)
>>
>> Thanks
>> Mansi.
>>
>> On Thu, Mar 10, 2016 at 7:43 AM, Cody Koeninger 
>> wrote:
>>
>> > Mansi, I'd agree that the fact that everything is tied up in poll
>> > seems like the source of the awkward behavior.
>> >
>> > Regarding assign vs subscribe, most people using the spark integration
>> > are just going to want to provide a topic name, not go figure out a
>> > bunch of partitions.  They're also going to be surprised if things
>> > suddenly blow up once a partition is added, or that partition doesn't
>> > start being consumed (we already have that second issue today).
>> >
>> > Thats why separating the behavior of auto offset reset seems like the
>> > best idea I've heard so far.
>> >
>> > Consumer rebalance listeners are still probably going to be necessary
>> > for people who are storing offsets externally.
>> >
>> > On Thu, Mar 10, 2016 at 9:27 AM, Mansi Shah 
>> > wrote:
>> > > Guozhang
>> > >
>> > > Sorry for joining the party a little late. I have been thinking about
>> > this
>> > > whole awkward behavior of having to call poll(0) to actually make the
>> > > underlying subscriptions take effect. Is the core reason for this
>> design
>> > > the fact that poll is also the actual heartbeat and you want to make
>> the
>> > > listener group assignments through poll - so that timeouts and
>> > > reassignments can all go through poll? So I think clubbing liveness
>> with
>> > > poll (which in effect clubs consumer group assignments and hence
>> metadata
>> > > fetch with poll) is the real cause of this design. Were there issues
>> > where
>> > > you were seeing active consumers not calling poll that led to this
>> design
>> > > choice? I tried to look for a relevant JIRA but could not find one -
>> can
>> > > you please point me to something if you have it handy?
>> > >
>> > > Btw this would also means that your proposal to do the actual
>> assignments
>> > > through seek might not be ideal since there can still be indefinite
>> time
>> > > between seek and poll (just like between subscribe and poll) and the
>> > > consumer could timeout even before the first poll is called?
>> > >
>> > >
>> > > @Cody in your case if you really have only one consumer and it is going
>> > to
>> > > get all the partitions of the topic anyway - then you might as well
>> > > subscribe using "assign" call instead of "subscribe" call. That will
>> make
>> > > at least your code cleaner and I do not think you are gaining anything
>> > with
>> > > the listener group functionality anyway?
>> > >
>> > > - Mansi.
>> > >
>> > >
>> > >
>> > > On Wed, Mar 9, 2016 at 8:35 PM, Guozhang Wang 
>> > wrote:
>> > >
>> > >> In order to do anything meaningful with the consumer 

Producer connection leakage situation in 0.8.1.1

[Jagbir Hooda]

System configuration:

OS: Ubuntu 14.04LTS
java version "1.7.0_80", Java(TM) SE Runtime Environment (build
1.7.0_80-b15), Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11,
mixed mode)
kafka version: kafka_2.10-0.8.1.1
No. of brokers: 4

All,

We're experiencing a weird tcp connection leakage situation in which
if rough kafka clients do not properly close their producers after
producing messages the brokers leak connections. On broker side, we
see these connections continuously grow in numbers in ESTABLISHED
state, e.g.,

tcp6   0  0  :9092   :46864
ESTABLISHED 14060/java

Even if we shutdown the clients completely the connections remain in
ESTABLISHED state and would not go away. We tried forced full garbage
collection on the brokers, but still the connections won't go away.
This is quite weird and I'll appreciate if someone faced similar
issues and figured out a way to cleanup the dead producer connections
without restarting the brokers.

Thanks and I'll really appreciate if you can provide some help.

jhooda

Re: New to Kafka

[prabhu v]

Hi Christian/Gaurav,

I am looking for the user group meetings which is listed in the page
https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
.

User group meetings:

   - 1st Kafka user group meeting at LinkedIn, Jun. 14, 2012. video (part 1)
   , video (part 2)
   
   - 2nd Kafka user group meeting at LinkedIn, Jun 27 2013. video
   
   - 3rd Kafka user group meeting at LinkedIn, June 3, 2014, video
   

.

I am able to access only the 2nd Kafka user group meeting..

1st & 3rd user group meetings are not available in the mentioned link...

[image: Inline image 1]

Are there any central repository/youtube channel where they keep all the
presentations ??

Thanks,

On Fri, Mar 11, 2016 at 10:43 PM, Christian Posta  wrote:

> What exactly is outdated? Are you not able to grok Kafka with the current
> presentations?
>
> On Fri, Mar 11, 2016 at 1:01 AM, prabhu v  wrote:
>
> > Hi,
> >
> > Can anyone please help me with the video presentations from Kafka
> experts?
> >
> > Seems the link provided in Kafka home page
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+papers+and+presentations
> > is
> > outdated..
> >
> > Thanks in advance..
> >
>
>
>
> --
> *Christian Posta*
> twitter: @christianposta
> http://www.christianposta.com/blog
> http://fabric8.io
>