問題点

AEM サイトでコンテンツをアクティベートすると、その変更はパブリッシュインスタンスに表示されますが、実際の Web サイトでは表示されません。

原因

これが異なるアーキテクチャによって異なるというのは、多くの原因が考えられます。

原因としては次のようなものがあります。

  • CDN を使用している場合
    • TTL 設定が正しくない
    • キャッシュに関連するヘッダー(キャッシュコントロール、Pragma Expires)が誤りまたは欠落している
  • ディスパッチャーまたは Web サーバーが失敗または設定が正しくない

解決策

このような問題をデバッグする最初の手順は、問題を分離することです。AEM のパブリッシュインスタンスがアクティベーションで更新されていることをすでに知っています。したがって、この問題は、CDN や Web サーバー/Dispatcher キャッシュなどのアップストリーム Web スタックに存在する必要があります。

I. コンテンツが期限切れかどうかを見るために Web サーバー/Dispatcher を確認します

 

  1. ディスパッチャー上のコンテンツが古くなっていない場合、この問題は、ディスパッチャーと AEM によって送信されている CDN の TTL 設定またはヘッダーに関連があります。ガイダンスの下の「"II.CDN の問題」に従います。

  2. ディスパッチャーに古いコンテンツがある場合は、これらのディスパッチャーの 1 つで設定が正しくないか正常に機能しないことがあります。ガイダンスの「IV.Dispatcher のキャッシュの問題」に従います。

II.CDN の問題

CDN のコンテンツが古くなっている場合は、次のようにします。

  1. CDN 管理インターフェイスにログインし、TTL 設定を確認します。TTL が CDN 設定で設定されている場合、非常に高く設定されていないことを確認します。

  2. ディスパッチャーを介してコンテンツに直接アクセスして、max-age、Expires、および Pragma といったキャッシュコントロールなどの HTTP ヘッダーの存在を確認します。例:http://dispatcher-host1/content/geometrixx/en.html

  3. http://dispatcher-host1/content/geometrixx/en.html?bypasscache=1 などの URL にクエリ文字列を追加することにより、ディスパッチャーのバイパスをテストします。この応答のキャッシュ関連ヘッダーも確認します。ヘッダーは、キャッシュされた応答から返されたものとの間で異なる場合があります。ディスパッチャーのキャッシュのフラッシュ後に、最初の HTTP 応答がディスパッチャーをバイパスしたときと同じになることに注意してください。これにより、一部の CDN エッジサーバーはバイパスされた応答を受信し、他はディスパッチャーからキャッシュされた応答を取得するようになります。

注意:

キャッシュ関連のヘッダーが HTTP 応答から省略された場合、Amazon Cloudfront などの一部の CDN は応答を無限にキャッシュします(TTL が設定されていないことが前提となっている)。 

III.ブロックまたは設定されていないエージェントのフラッシュ

問題が CDN レベルでないと判断した場合は、次の手順で AEM フラッシュエージェントの設定を確認します。

フラッシュエージェントが設定されていることと、そのエージェントが有効になっていることを確認します。

キャッシュのフラッシュジョブがキューで処理されているかスタックしている場合は、フラッシュエージェントのキューを確認します。

  1. 1. フラッシュエージェントがブロックされた状態になっている
    ディスパッチャーのフラッシュエージェントページがブロックされていることを表示している場合、AEM とディスパッチャーサーバー間でネットワーク接続の問題が発生している可能性があります。フラッシュエージェントが設定されているすべての AEM インスタンスがディスパッチャーサーバーに到達できることを確認します。サーバー間の接続を許可するファイアウォールのルールを必要に応じて変更します。

  2. 2. フラッシュエージェントは、多くのジョブがキューに格納されたアクティブ状態になっている
    エージェントはアクティブ状態を表示しているが多くのジョブがある場合は、次が発生する可能性があります。
    a. フラッシュ中のエラー
    b. Web サーバーが応答をフラッシュするために極端に遅く応答している
    c. または AEM のジョブ処理の問題

  3. 3. フラッシュエージェントが、キューに格納されているジョブなしにアクティブな状態である
    エージェントはアクティブな状態を表示しているが、キューに格納されていないジョブがある場合、Web サーバーはフラッシュリクエストに対して 200 の応答を返しているが、実際にはフラッシュを実行していません。

IV.Dispatcher のキャッシュの問題

  1. cURL を使用して手動ディスパッチャーフラッシュリクエストをテストする

    cURL を使用してディスパッチャーフラッシュリクエストをテストします。リクエスト本文「OK」がある 200 の応答以外を取得する場合、ディスパッチャーフラッシュはディスパッチャーモジュールで処理されていません。以下の手順に従ってデバッグします。 

    curl -v -H "CQ-Action: Activate" \ 
         -H "CQ-Handle: /content/bar" \ 
         -H "Content-Length: 0" \
         -H "Content-Type: application/octet-stream" \ 
         http://dispatcher-server-hostname:port/dispatcher/invalidate.cache
  2. dispatcher.any の設定の確認

    allowedClients の確認

    dispatcher.any 設定で設定されたディスパッチャーファームの /allowedClients 設定を確認します。フラッシュリクエストを発行する予定のすべての AEM インスタンスの IP アドレスが表示されていることを確認します。 

  3. Web サーバー設定の確認

Microsoft IIS:

A. 「リクエストのフィルタリング」の確認

  1. 管理者として RDP で IIS サーバーにログインします

  2. サーバーマネージャー」=>「役割」=>「IIS マネージャー

    を開きます

  3. IIS マネージャーで、AEM Dispatcher が有効なサイトを参照します

  4. リクエストフィルター

    を開きます

  5. フィルター設定が /dispatcher/invalidate.cache への GET および POST リクエストをブロックしていないことを確認します

これらの設定にアクセスして変更する方法について詳しくは、Microsoft ドキュメントを参照してください。

B. IIS 再書き込みルールの確認

  1. 管理者として RDP で IIS サーバーにログインします

  2. サーバーマネージャー」=>「役割」=>「IIS マネージャー

    を開きます

  3. IIS マネージャーで、AEM Dispatcher が有効なサイトを参照します

  4. URL 再書き込み

    を開きます

  5. ルールを確認して、/dispatcher/invalidate.cache への GET または POST リクエストがブロックまたは解除される可能性があるかどうかを判断します。

これらの設定にアクセスして変更する方法について詳しくは、Microsoft ドキュメントを参照してください。

Apache Web サーバー:

A. 「RewriteRule の設定」を確認します

httpd 設定でディレクティブのレビューおよび RewriteRule を実行し、/dispatcher/invalidate.cache への GET または POST リクエストがブロックまたは解除される可能性があるかどうかを検証します。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー