| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノート 12c (12.2.1) E69917-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureリリース・ノート 12c (12.2.1) E69917-02 |
|
前 |
次 |
この章では、Oracle User Messaging Service (UMS)に関連する問題について説明します。
内容は次のとおりです。
Oracle User Messaging Serviceは、リリース12.2.1では非推奨です。
この項では、一般的な問題および回避策について説明します。内容は次のとおりです。
6.2.2項「Oracle User Messaging ServiceとOracle HTTP Serverを構成した後でノード・マネージャが起動しない」
6.2.3項「ユーザー・メッセージング・サーバーの「パフォーマンス」ページでメッセージ・メトリックが「使用不可」とレンダリングされる」
6.2.8「Upgrade AssistantのUser Messaging Serviceスキーマに接続ボタンがない」
Oracle Enterprise Manager Fusion Middleware Control 12cでは、User Messaging Serviceの拡張ドライバが左側のナビゲーション・ペインのApplication Deploymentsフォルダではなく、User Messaging Serviceフォルダに表示されます。また、ドライバのパフォーマンス・データが拡張ドライバ用に利用できます。これは予測されている動作です。
クラスタ環境では、Oracle Real Application Clusters (RAC)のマルチ・データソースが存在するドメインでOracle User Messaging Service (UMS)とOracle HTTP Serverを構成した場合、ノード・マネージャが起動しないことがあります。
回避策
RACが設定されたクラスタ環境では、データベース・サーバーで許可する最大接続数を増やす必要がある場合があります。この値を、各WebLogic Serverのデータソース当たりの最大接続数の合計に設定します。たとえば、Oracle RACが3つのノードとともに使用されている場合(3つのOracle RACデータソースと2つのWebLogic Server)、最大接続数を600に設定します(2 x 3 x 100)。
サーバーの設定後にメッセージの送受信がない場合などのようにメトリック・データがない場合、メトリックの「パフォーマンス」ページに「使用不可」と表示されます。これは、ソフトウェアの問題ではなく、パフォーマンス・レポート機能は適切に動作しています。送信および受信トラフィックが発生すると、即座に結果が「パフォーマンス」ページに正常に表示されます。UMSサーバーのホームページでもメッセージ数(「統計」セクション)に「使用不可」と表示されます。
Oracle Enterprise Manager Fusion Middleware ControlまたはOracle WebLogicコンソールを通じてUser Messaging Serviceサーバー(usermessagingserver)を再起動し、User Messaging Serviceサーバーにより提供されるユーザー・プリファレンスUI(/sdpmessaging/userprefs-ui)や様々なWebサービス・エンドポイントなどのURLにアクセスしようとすると、「エラー503 - サービスが使用できません」というエラーが発生することがあります。このエラーは、Oracle WebLogic Serverの負荷が(SOAインスタンスなどで)高い場合に断続的に発生します。この問題の回避方法:
User Messaging Serviceサーバーを再起動します(2回以上の再起動が必要になる可能性があります)。
User Messaging Serviceサーバーを複数回再起動しても不十分な場合は、Oracle WebLogic Serverインスタンス全体を再起動します。
いくつかのシナリオでは、UMSの11gから12cへのアップグレード時に次のエラーが発生し、アップグレードが失敗する場合があります。
[2014-04-10T20:38:14.915-07:00] [UCSUMS] [ERROR] [] [upgrade.UCSUMS.UCSUMS_CONFIGURATION_PLUGIN] [tid: 70] [ecid:435559f9-7615-48f8-8e80-950a7f10e152-00000001,0] [[com.jcraft.jsch.JSchException: verify: false
com.jcraft.jsch.JSchException: verify: false例外が断続的に発生します。回避策としては、再度アップグレードを試行します。
Twitterドライバは、再起動するたびに構成済のユーザーに対して最新のツイート20件を取得します。これは、アプリケーションが再起動した後の最初の受信の試行によって、以前に見たことがあるいくつかのメッセージが返される場合があることを意味します。回避策として、すべてのツイートを1回のみ処理したい場合は、Twitter IDを含むヘッダーを使用できます。
問題および回避策
アクセス・ポイントは新規トランザクションで登録されます。つまり、クライアント・アプリケーションがロールバックされるトランザクションでアクセス・ポイントを登録した場合、アクセス・ポイントは引き続き格納されています。アクセス・ポイントを削除する必要がある場合、5.1.2 メッセージ・クライアント・アプリケーションの登録解除に関する項(https://docs.oracle.com/middleware/1213/ums/administer/ns_monitor.htm#UMSAG37181)の説明のようにアプリケーションを登録解除します。
Oracle Fusion Middleware Upgrade AssistantによるUMSスキーマのアップグレードを行う際、「個別に選択されたスキーマ」オプションを選択すると、データベースへの接続を取得するために使用する接続ボタンと利用可能なUMSスキーマ名を移入するために使用するドロップダウン・リストがありません。回避策として、手動でスキーマ名の値を入力します。
非クラスタ化管理対象サーバーを含むデプロイメントでの再送信:
UMSが複数の非クラスタ化管理対象サーバーにデプロイされているドメインで、あるUMSサーバーに関するEMの「メッセージ・ステータス」ページに、ドメイン内の別のサーバーを介して送信されたメッセージが表示されます。元々別のサーバーから送信されたメッセージを再送信すると、再送信が失敗します。再送信操作は、元々メッセージの送信に使用されたサーバーと同じサーバーから行う必要があります。別のサーバーを介してメッセージを再送信するには、ドメイン内の正しいUMSサーバー・ターゲットの「メッセージ・ステータス」ページに移動し、再送信します。
たとえば、2つの管理対象サーバー(a_ums_serverおよびb_ums_server)を含むドメインで適切に送信するには、次の手順を実行します。
左側のナビゲーション・ツリーからターゲット「usermessagingserver (a_ums_server)」を選択し、「メッセージ・ステータス」メニュー項目をクリックします。
ページのメッセージ・ステータス表に、デフォルトの検索基準に基づいてすべてのメッセージが表示されます。
表内のメッセージをクリックし、メッセージの「メッセージの詳細」を表示して元々メッセージの送信に使用されたUMSサーバーを確認します。
たとえば、選択したメッセージの「エンジン」パラメータの値が"/unclustered_base_domain/base_domain/b_ums_server/usermessagingserver"の場合、現在のターゲット・サーバー(a_ums_server)は「エンジン」パラメータ内のサーバー(b_ums_server)と一致しません。選択したこのメッセージの「再送信」ボタンをクリックすると、メッセージの再送信操作に無効なサーバーが選択されましたというエラーになります。
このメッセージを再送信するには、左側のナビゲーション・ツリーで「usermessagingserver(b_ums_server)」に移動してメッセージをクリックし、ターゲット名とエンジンの詳細のサーバー名が一致することを確認して「再送信」をクリックします。
複数のクラスタを含むデプロイメントでの再送信:
UMSが複数のクラスタにデプロイされているドメインで、あるUMSサーバー(クラスタに属する)に関するEMの「メッセージ・ステータス」ページに、ドメイン内の別のサーバーを介して送信されたメッセージが表示されます。元々別のサーバー(別のクラスタに属する)から送信されたメッセージを再送信すると、再送信が失敗します。再送信操作は、元々メッセージの送信に使用されたクラスタと同じクラスタから行う必要があります。別のクラスタを介してメッセージを再送信するには、ドメイン内の正しいUMSサーバー・ターゲット(正しいクラスタ内のUMSサーバーの1つ)の「メッセージ・ステータス」ページに移動し、再送信します。
たとえば、2つのクラスタ(a_ums_clusterおよびb_ums_cluster)を含むドメインで各クラスタに2つの管理対象サーバー(a_ums_clusterにa_ums_server1とa_ums_server2、b_ums_clusterにb_ums_server1とb_ums_server2)が含まれる場合、適切に再送信するには次の手順を実行します。
左側のナビゲーション・ツリーからターゲット「usermessagingserver (a_ums_server1)」を選択し、「メッセージ・ステータス」メニュー項目をクリックします。
ページのメッセージ・ステータス表に、デフォルトの検索基準に基づいてすべてのメッセージが表示されます。
表内のメッセージをクリックし、メッセージの「メッセージの詳細」セクションを表示して元々メッセージの送信に使用されたUMSサーバーを確認します。
例に示すように、選択したメッセージの「エンジン」パラメータの値は"/cluster_base_domain/base_domain/b_ums_server1/usermessagingserver"です。
ターゲット・サーバー(a_ums_server1)と「エンジン」パラメータのサーバー(b_ums_server1)は同じクラスタに属していないため、選択したこのメッセージの「再送信」ボタンをクリックすると、メッセージの再送信操作に無効なサーバーが選択されましたというエラーになります。
このメッセージを再送信するには、左側のナビゲーション・ツリーで「usermessagingserver (b_ums_server1)」に移動してメッセージをクリックし、ターゲット名とエンジンの詳細のサーバー名が一致すること(または同じクラスタ内にあること)を確認して「再送信」をクリックします。
この項では、構成に関する問題およびその回避策について説明します。内容は次のとおりです。
SSLを使用してリモート・ゲートウェイに接続するためにUser Messaging Serviceドライバ(電子メール・ドライバなど)を構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関するトピックで説明されているように、SSL信頼ストアが正しく構成されていることを確認してください。
$DOMAIN_HOME/bin/setDomainEnv.sh(またはWindowsの相当するファイル)に設定されている場合、JVMシステム・プロパティ(javax.net.ssl.trustStore)の値が使用する正しい信頼ストアを指していることを確認してください。Java標準信頼ストアは次の場所にあります。
$JAVA_HOME/jre/lib/security/cacertsまたは$BEA_JAVA_HOME/jre/lib/security/cacerts
SSL信頼ストアのデフォルトの即時利用可能な構成(Java標準信頼ストア)では、UMSドライバはSSLを介してOracle Beehive Email Serverに接続できません。一部のインストールでは(SOAをインストールしている場合など)、Java標準信頼ストアはデモ信頼ストアに置き換えられることに注意してください。このような場合、信頼ストアには、Oracle Beehive Email Serverが必要とする有効なルート証明書が含まれていない可能性があります。この問題を解決するには、正しいSSL信頼ストアを使用するための手順を実行します。setDomainEnv.shファイル(またはWindowsの相当するファイル)でDemoTrustキーストアをJava標準SSL信頼ストアで置き換えると、UMS電子メール・ドライバはSSLを介してOracle Beehive Email Serverに正常に接続できるようになります。
