残りの空を含む GetNextSegment がファジーの原因となる

Optimizely CMS では、部分的なルーターを作成できます。この概念により、URL 内のルーティングされたコンテンツに応じてコンテンツを異なる方法で表示できます。もちろん、より詳細な説明は次の URL で確認できます。 https://docs.developers.optimizely.com/content-management-system/docs/example-of-news-partial-routing全体として、この概念は CMS の以前のバージョンにも存在していましたが、現在のものとは少し異なっていました。

顧客を.NET Frameworkから.NET Core、つまりCMS 11から12に移行したとき、一見すると原因がわからないメモリリークが発生しました。解決策は部分ルーターを多用していました。この問題は開発マシンではなくDXPで頻繁に発生し、さらに奇妙でした。アプリケーションが自動的に ウォームアップ DXP で実行しているとき。これにより、問題の原因である部分的なルーター、より具体的には URL セグメントの次の値を取得する部分を見つけることができました。

で説明したように、 CMS 12 ドキュメント、から使用することができます UrlResolverContext 方法 GetNextSegment その情報を取得するには、 Segment、これには「次」と「残りのパス」が含まれます。私たちのコードは元々 CMS 11 用に開発されたため、当時は古い API であるメソッド「GetNextValue」を使用していました。おそらく、名前は思い出せませんが、類似のサービスからのもので、Optimizely コードが空のセグメントを返すまでループしていました。これですべて理解できましたか? CMS 11 から逆コンパイルされたコードは次のとおりです。

ご覧のとおり、CMS 11は単に空の「次」と「残り」を返していました。 SegmentPair 残りのパスが空の場合、コードはこの情報、つまりセグメントペアの「Remaining」プロパティに依存していました。この時点で、メモリリークが発生していた理由がお分かりいただけると思います。実際、CMS 12では、このコードが変更され、文字列を連結する無限ループが発生しました。 無限の彼方へ!変更自体は非常に不可解で、Optimizely がなぜそのように変更したのか私自身も理解できません。これは、他の何よりも望ましくないエラーのように感じられます。以下は、逆コンパイルされたコードのスナップショットです。これだけですべてがわかります。

それは、うーん、まあ、残りのパスが空の場合は再割り当てしますが、 同じチェックを直後に現時点では決して満たされない条件は、 私たちが期待するもの。

この不具合については Optimizely に報告しましたが、残念ながら修正されませんでした。現在、私たちのコードにはさまざまなチェックと、無限ループを回避するためのフェイルセーフが組み込まれています。この投稿によって、皆さんの側で同様の問題を診断する時間を節約できることを願っています。