タグ: Jakarta EE

普段の業務ではモノリシックなアプリを扱っているので"分散"という点はあまり気にしていないのですが、やはり1リクエストでどの辺の処理に時間がかかっているのかを知りたい気持ちがあります。Jakarta EEとの統合を考えるとMicroProfile OpenTracingが第一候補になるかと思います。MP OpenTracingは主にJAX-RSとの統合を意識して作られていると思っていますが、Jakarta Server Facesとの統合を考えるといくつか検討すべき事項があります。

• Jakarta Server Facesにおいてリクエストは"ライフサイクル"に従って処理される。ライフサイクル中の各フェーズにおける処理時間を把握できるようにしたい
  • ライフサイクルについてはjsf ライフサイクルで検索してください
  • Render Response Phaseで時間がかかっているのなら(カスタム)コンポーネントの処理を軽量化できないか検討するとか
  • Invoke Application Phaseで時間がかかっているならビジネスロジックの最適化とか
  • etc…
• MP OpenTracingは@Tracedアノテーションを付与したクラス・メソッドの処理時間等を記録する(CDIのInterceptorで実現している)が、@ViewScopedなバッキングビーン(Serializableとする必要がある)で使用すると例外が発生する(メモるの忘れた・・・non-serializableなinterceptorは適用できないとかなんとか)

この2点を解決できれば有用かと思ったので、休暇を利用してさっと作りました。ライセンスはApache License, Version 2.0で、Maven Centralにも公開済みです。

https://github.com/maruTA-bis5/opentracing-faces

使い方はREADMEにも書いてあるとおりですが、基本的にMP OpenTracingと同じように使います。

• Serializableでないバッキングビーンや、それ以外のCDI管理Beanなどについては、MP OpenTracingの@Tracedを使用します。
• @ViewScopedなバッキングビーンに@Tracedを使うと怒られるので、@TracedSerializableを代わりに使用します。
• 各フェーズの時間を記録する場合、TracingPhaseListenerを使用します。

ちなみに動作確認はWildFly 20.0.1.Finalで行いました。他のアプリケーションサーバーでうまく動かなければ教えてもらえると助かります。