Jinli Liang

> > I think this has all of the same issues as using the pod IP (it's just $nodeIP:$nodeport instead of $podip:$listenport). > > It does. But unlike node ports...

> PS: Please keep also in mind that there are reasons why we use pod DNS names over pod IPs => Pod IPs are not stable and that tends to...

I see, thanks for the context especially the IP recycling bit. I think I found the original issue regarding the ip -> dns change (https://github.com/strimzi/strimzi-kafka-operator/issues/50), although there isn't an exact...

got it, thanks! i will try to duct tape https://github.com/strimzi/strimzi-kafka-operator/blob/release-0.26.x/cluster-operator/src/main/java/io/strimzi/operator/cluster/model/KafkaBrokerConfigurationBuilder.java#L196 & https://github.com/strimzi/strimzi-kafka-operator/blob/release-0.26.x/docker-images/kafka/scripts/kafka_config_generator.sh#L44-L45 to exposing vpc internal pod ip & dog food this first to see howo much of a difference...

Could be reproduced with following ``` package main import ( "fmt" "math/rand" "runtime" "strconv" "time" . "github.com/allegro/bigcache/v2" "github.com/pkg/profile" ) const ( entries = 3000 repeats = 1000 ) var val_big...

Have the same issue on production ``` | 2020-08-18 02:32:06.870 | github.com/allegro/bigcache/v2.(*cacheShard).removeOldestEntry(0xc000375680, 0x1, 0x0, 0xa0f04b) | | 2020-08-18 02:32:06.870 | /go/pkg/mod/github.com/allegro/bigcache/[email protected]/shard.go:296 +0x170 | | 2020-08-18 02:32:06.870 | github.com/allegro/bigcache/v2.(*cacheShard).onEvict(0xc000375680, 0xc00001ca20, 0x9,...

also it appears after big cache panics, the cache get method will hang without throwing errors. we observed this after the panic above is thrown and recovered, then subsequent cache...

We need this as well. is there any plan to include this feature?