インターネットが壊れた

fastly使ってるとこが全滅した感

死んだのはfastlyか.CDNの死亡じゃないか

ほんとだよ,いつまでも仕事なんかしてんじゃないよというgithubからのメッセージ

githubが応答返さない

あーこのfinってLBが送ってくるやつじゃん.つまりLB側のタイムアウトなわけか

timeoutを指定しないと,結局だれかがfinを送るぞ?誰じゃ?これのタイムアウトさえ短くできればいいんだが

client側のtimeoutを指定しない場合どうなるんだろう,という観測

そもそもうちのLBが悪いのはわかったんだけど,それにしてもnet/http側もちょっと中途半端なのではないか……

本気を出せば初回接続時のエラーハンドリングでRequestCanceledを拾ってCloseIdleConnectionsすれば,transportが保持しているidleConnを吹き飛ばしてリトライ可能ではある.けど,ちょっと場当たり的すぎてあんまりやりたくないんだよなぁ.やるのであれば,そもそもclient-goがRESTClient生成するときに,正しくリトライできるclientを生成してほしい

memberが死んだときにresetを送ってくれるLBと送ってくれないLBがある.どういうことだよwww

ずっとupdateしてていつになっても終わらん……

珍しくproposalを書く

あちぃね

わろたwww

はらへ

落としたインスタンスをLBがmemberから外してくれないし,維持したtcp connに対してもackを返し続けているのでkeepaliveし続けてしまう.せめてmemberから外してほしいし,なんならそのタイミングでresetを送ってほしい

idleConnが全然クリアされない.これほぼほぼLBのせいだと思うんだけど,どうしたもんか……