2. コンテナ制御

コンテナ制御の注意事項と制限事項について説明します。
以下のWebOTX Application Server の 注意制限事項 も合わせてご覧ください。

• WebOTX Application Server 注意制限事項
  • JNDIサービス
  JDBCデータソース
  • Transactionサービス
  • JMX
  • Object Broker Java™/C++
  • 統合運用管理ツール

2.1. 注意事項

1. コンテナプロセス所有者の設定を行う場合、ドメインエージェントは特権ユーザで起動する必要があります。
   
2. 本製品にバンドルしているPAMの認証設定ファイルのサンプルの既定値では、認証エラーが発生する場合があります。
   • ドメインエージェントを特権ユーザで起動していない、かつ、ドメインエージェントを起動したユーザと、ドメインエージェントへの操作要求を行う際に指定したユーザが異なる場合に、認証エラーとなります。
     詳細については、以下を合わせて参照してください。
     • 機能ガイド
       • アクセス制御
         • アカウント認証
           • OSユーザによる認証
   • ドメインエージェントを特権ユーザで起動していない、かつ、ドメインエージェントを起動したユーザに、PAMの認証設定ファイルの読み込み権が無い、または、PAMの認証設定ファイルまでの絶対パス中のディレクトリに実行権が無い場合、認証エラーとなります。
3. PAM のバージョンが、 0.99.6.2-4 より古い場合、かつ、システムで pam_tally.so を利用している場合、 /var/log/faillog のファイルディスクリプタが開放されない問題があります。
   • バグ情報
     • https://bugzilla.redhat.com/show_bug.cgi?id=457024
   本問題により、認証エラーが発生する場合があります。
   PAM のバージョンは、 0.99.6.2-4 以後のものを利用してください。
4. コンテナが複数存在する、または、コンテナプロセス多重度が 1より大きい 環境では、ジョブリポジトリへのアクセス部において、トランザクションの分離レベルに起因する問題が発生する場合があります。
   • データベースがOracleの場合

     トランザクションの分離レベルが ISOLATION_SERIALIZABLE である場合、
       ORA-08177： can't serialize access for this transaction
     が発生する可能性があるため、トランザクションの分離レベルに ISOLATION_READ_COMMITTED を設定することを推奨します。

     運用管理コマンド(defaultのジョブ実行リソースの変更を行う場合)

     otxadmin set <接続オプション> domain.bsssytem.job-execution-resource.execution-context._ANY_.jobRepositoryIsolationLevelForCreate=ISOLATION_READ_COMMITTED
     

     
     
   • データベースがPostgreSQLの場合

     トランザクションの分離レベルによらず、同様の問題は発生しません

   • データベースがDerbyの場合

     トランザクションの分離レベルによらず、ジョブリポジトリのアクセス時にデッドロックが発生し、 ジョブを正常に開始・終了できない可能性があるため、コンテナとコンテナプロセスの数を一つに限定することを推奨します。

5. ジョブリポジトリの変更時や初期化時には、DOMAIN_HOME/logs/batch/<アカウント名>ディレクトリ下のジョブ実行ログファイルを削除、または、退避してください。
   • ジョブ実行ログはジョブリポジトリによって管理するJobInstanceIdを元にファイルパスを決定します。 そのため、下記いずれかのようなジョブリポジトリの変更によってJobInstanceIdが振りなおされると、異なるジョブ実行ログにログが追記されてしまいます。
     • ジョブリポジトリ用のデータベースを変更
     • マップジョブリポジトリを利用
     • repoadminコマンドによってジョブリポジトリを初期化
6. マップジョブリポジトリ は、限られた用途でのみ利用できます。
   • マップジョブリポジトリの利用を有効化すると、各バッチコンテナプロセスのメモリ上にジョブリポジトリを構成します。
     そのため、異なるバッチコンテナプロセスで実行されたジョブの実行状態を共有できません。 また、ジョブリポジトリ内の情報を永続化しないため、バッチコンテナプロセスの再起動によって情報が保持されません。
     以下のような用途での利用を想定しています
     
     • 開発環境におけるジョブの動作確認
   • マップジョブリポジトリを利用する際は、ジョブ実行リソースコンテキストのキャッシュを有効化する必要があります。
7. 以下の設定を反映するにはドメインエージェントを再起動する必要が有ります。

   表示名	CLIName
   プロセス所有者	domain.bssystem.batch-containers.<コンテナ名>.owner

   ドメインエージェントを再起動しないまま、バッチコンテナのみを再起動すると意図しない所有者のコンテナプロセスへジョブ実行リクエストが振分けられる可能性があります。

8. 以下の設定を反映するにはバッチコンテナを再起動する必要が有ります。

   表示名	CLIName
   スレッド名のプレフィックス	domain.bssystem.job-execution-resource.work-manager.<WorkManager名>.threadNamePrefix
   スレッド優先度	domain.bssystem.job-execution-resource.work-manager.<WorkManager名>.priority

9. Linux OSの環境では、Linux kernelおよびJDKの制限により、スレッド優先度 ( domain.bssystem.job-execution-resource.work-manager.<WorkManager名>.priority )の設定値は、OSのスレッド優先度に反映されません。
10. 強制停止モードの場合、コンテナの状態に関わらず停止処理を試みます。
    強制停止失敗時には、コンテナプロセスの有無に関わらず、コンテナプロセスの状態はNOT_RUNNINGに遷移します。強制停止に失敗した場合、コンテナプロセスの有無を確認してください。

    強制停止に失敗したコンテナプロセスが存在している状態で、コンテナの起動させないでください。

2.2. 制限事項

1. コンテナプロセス所有者の設定は、Windows環境では使用できません。
2. ロールの追加・変更・削除は行えません。
3. JMXMPプロトコル用のJMXコネクタを併用する場合、認証済ユーザに全ての運用操作権限が付与する必要があるため、ロールによるアクセス制御が無効化されます。