GRPCのリクエスト構造とエラーハンドリング - Qiita
この記事について GRPC は HTTP/2 の上に構築されているため、クライアントからサーバーのサービス呼び出しや、サーバーからクライアントへ戻り値やエラーの送信、といったやり取りは HTTP/2 のリクエストとレスポンスで実装されています(もうちょっと厳密に言うと HTTP/2 フレームを使って実装されている)。 この記事ではGo言語のGRPC実装(grpc-go)を用いて、以下についてまとめてみました。 GRPC が用いる HTTP/2 のリクエスト、レスポンスの流れと構造 その中でエラーがどう伝播されるか GRPC の Unary RPC のエラーハンドリング 扱いにちょっと悩む Streaming RPC のエラーハンドリング 環境等の情報 記事の作成に用いた環境: Go言語 : v1.15.6 grpc-go : v1.34.0 この記事で用いたソースコード grpc-erro
Sidekiq で最大回数リトライ後に失敗した場合出すログに例外のバックトレースを含める - Qiita
この記事では Sidekiq 5 系を対象にしていますが、4 系でも変わらない内容です。 Sidekiq Worker を利用する利点の一つに、 リトライ処理 を Sidekiq に任せられる点があります。 リトライを安全に実行するために、Sidekiq Worker の処理を冪等にしておくことは Sidekiq の Best Practice にも触れられています。以下は引用です。 2. Make your job idempotent and transactional Idempotency means that your job can safely execute multiple times. For instance, with the error retry functionality, your job might be half-processed, throw an
golangにgoto文が存在する理由 - Qiita
goto文といえばどこにでも飛べるという圧倒的自由度を誇る分、 文の流れを追いづらくなるといった可読性の問題等から基本的に使うべきでなく、 使った方が見やすい場合でも代替の方法があるならそちらを使うべきといったイメージがありました。 おそらく大半のプログラマもそんな感じだと思います。 しかしモダンでイケイケなことで定評のあるgolangにおいてもgoto文がサポートされています。 統一しただけとはいえ、while文すら捨てた新進気鋭のgolangが、 30未満という洗練された予約語の中にgoto文を残したわけです。 もちろん言語界隈はgo繋がりというだけで採用されるコネ社会ではありません。 goto文=悪というプロパガンダを刷り込まれた我々雛鳥世代が黙っているはずはありません。 ピーチクパーチク騒ぐに違いないことは歴史が証明しています。 Effective Go的なドキュメントにgoto文
Ruby の HTTP Client「Faraday」を使った場合の例外の扱いとリトライ処理をどうするか考えてみた - Qiita
チームメンバー毎でも書き方が違う時があるので、どういうやり方がありそうで、どういう時にそれを適用したら良さそうかを考えたメモです。 Faraday Ruby 製の HTTP Client です。Ruby Tool Box の HTTP Client カテゴリでは 2 位なので結構使われているライブラリなのではないかと思います。 lostisland/faraday - Github 本家の README を見てもらうと分かる通り、いくつかの adapter を選択できるようになっています。 また faraday_middleware を代表とした middleware といった形で拡張可能なのも特徴の一つのようです。 Qiita 内でもたくさん見つかりますね Qiita を faraday で検索 まずエラーもリトライも考慮しない書き方 response を受け取るまでは faraday
Sidekiqで非業の死を遂げたキューを知る方法 - Qiita
前置き：Rubyのキューイングシステム Rails（Ruby）で非同期にキューイングしてくれるライブラリといえばSidekiqですよねっていうくらいSidekiqが好きなんですが、世の中のシェア的にはResqueなのかな。でも、Sidekiqの方が安定的に動かせているので僕は好きです（delayed_jobは知らない）。 ShoryukenというAWS SQSを使ったキューイングシステムもあり、RedisじゃなくてSQS使いたいっていう場合は、これも良いのかもしれないですね。まぁ、ローカルの場合面倒そうな感じもありますけど。 phstc/shoryuken まぁともかくSidekiqを導入してキューイングするっていうのは、もう超絶簡単にできるわけです。できるんですけど、実際にラフに運用していくと、キューがいつの間にかこけて処理待ちで埋まってたり、レアなケースで例外投げて死んでたりするわけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
