[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic
Java EE 7をサポートしているため、WebLogic Server 12.2.1はJava EE Concurrency Utilities (JSR236)仕様をサポートしています。
この仕様は、（ServletやEJBといった）Java EEアプリケーションコンポーネントから並列性を利用するため、シンプルかつ標準化されたAPI（4種類の管理対象オブジェクト）を提供します。
この4種類の並列性管理対象オブジェクトは、パッケージjavax.enterprise.concurrent packageのインターフェースManagedExecutorService、ManagedScheduledExecutorService、ManagedThreadFactory、ContextServiceを実装します。
依然としてServletやEJB内で直接java.lang.Threadやjava.util.Timerといった共通のJava SE concurrency APIを使っている場合、Java EE Concurrency Utilityを使うことを強く推奨します。Java SE concurrency APIを使って作成されたスレッドはWebLogic Serverで管理されないので、通常これらの管理対象外のスレッドからは、WebLogic Serverが管理するサービスやリソースを利用できません。Java EE Concurrency Utilitiesを使うことで、非同期タスクはWebLogic Serverで管理されたスレッドで動作します
Since WebLogic Serverにはこれらのスレッドや非同期タスクに関する知識があるので、以下の操作をすることでWebLogic Serverはスレッドや非同期タスクを管理します。
  • 適切な実行コンテキストを提供する。これにはJNDI、クラスローダ、セキュリティ、作業領域を含む。
  • サーバ全体の自己チューニングするシングルスレッドプールに短時間実行するタスクを発行し、定義されたルールやランタイムメトリックを基にしてタスクに優先度を付ける
  • 長時間実行するタスク用のスレッド数を制限し、サーバのパフォーマンスや安定性に影響を与えないようにする
  • アプリケーションがシャットダウンした場合には、スレッドの割り込みやタスクのキャンセルによって非同期タスクのライフサイクルを管理する
コンテキストを意識識したワークマネージャやタイマーを提供する）CommonJ APIはWebLogic Server固有であり、Java EE Concurrency Utilitiesの前身です。CommonJ APIに比較して、Java EE Concurrency Utilitiesは一層標準化されていて使いやすく、カスタムスケジューリング、ContextService、ManagedThreadFactoryといった多くの機能を提供しています。詳細は以下の記事をご覧ください。
詳細は、製品ドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1, Part One: ManagedExecutorService

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic1

Overview

ManagedExecutorService（管理対象エグゼキュータ・サービス）はWebLogic Serverが提供するスレッドで非同期でタスクを実行するためにあります。このサービスはjava.util.concurrent.ExecutorServiceの拡張ですが、新しいメソッドを持ちません。そのため、ExecutorSrevice由来のメソッド（execute、submit、invokeAll、invokeAny）を提供しますが、ライフサイクルのメソッド（awaitTermination、isTerminated、isShutdown、shutdown、shutdownNow）は無効にされており、使うとIllegalStateExceptionが発生します。
Weblogic Serverは事前構成済みのデフォルトの管理対象エグゼキュータ・サービスを各アプリケーションのために提供しており、アプリケーションは何も設定せずに簡単にこのサービスをWebコンポーネントやEJBコンポーネントで利用できます。デフォルトの管理対象エグゼキュータ・サービスをServletで使うという簡単な例からはじめてみましょう。

Example-1: Use Default ManagedExecutorService to Submit an Asynchronous Task in a Servlet

Step1）
非同期タスクを作成します。非同期タスクはjava.util.concurrent.Callableもしくは java.lang.Runnableのいずれかを実装する必要があります。タスクはjavax.enterprise.concurrent.ManagedTaskを実装して、識別情報やManagedTaskListener、もしくはタスクの追加実行プロパティを提供することができます。
JSR 236: Concurrency Utilities for JavaTM EE
https://jcp.org/en/jsr/detail?id=236
public class SomeTask implements Callable<Integer> {
    public Integer call() {
        // Interact with a database, then return answer.
    }
}
Step2）
SomeServlet.java がデフォルトの管理対象エグゼキュータ・サービスを注入し、タスクを管理対象エグゼキュータ・サービスに対し発行します。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource ManagedExecutorService mes;

     protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // Create and submit the task instances
        Future<Integer> result = mes.submit(new SomeTask());

        // do something else

        try {
            // Wait for the result
            Integer value = result.get();

            // Process the result and reply to the user

        } catch (InterruptedException | ExecutionException e) {
            throw new ServletException("failed to get result for SomeTask", e);
        }
    }
}

Runtime Behavior


Application Scoped Instance

上図には2個のアプリケーション（赤はA、緑はB）があります。この2個のアプリケーションがタスクを異なる管理対象エグゼキュータ・サービス・インスタンスに発行していることがわかります。これは管理対象エグゼキュータ・サービスがアプリケーションスコープにあるためです。各アプリケーションにはそれぞれ固有の管理対象エグゼキュータ・サービス・インスタンスがあり、管理対象エグゼキュータ・サービス・インスタンスのライフサイクルはアプリケーションに紐付いています。管理対象エグゼキュータ・サービスに発行された非同期タスクもまたアプリケーションスコープであるため、アプリケーションをシャットダウンすると、関連する非同期タスクやスレッドはキャンセルもしくは中断されます。
各アプリケーションはそれぞれデフォルト管理対象エグゼキュータ・サービス・インスタンスを持ちます。それに加え、アプリケーションやシステムの管理者はカスタマイズされた管理対象エグゼキュータ・サービスを定義することができます。管理今ソースでグローバルに定義された管理対象エグゼキュータ・サービス・テンプレート（後述します）は実行時にはアプリケーションスコープであることにご注意ください。

Context Propagation

上図で、アプリケーションAがタスクを発行すると、そのタスクはアプリケーションAのコンテキストでラップされ、アプリケーションBがタスクを発行すると、そのタスクはアプリケーションBのコンテキストでラップされます。これは管理対象エグゼキュータ・サービスがアプリケーションコンテキストをタスク発行時に捕獲し、その後捕獲したアプリケーションコンテキストをタスク実行前に伝播するため、正しい振る舞いです。そえゆえタスクもアプリケーションコンテキストを伴って実行します。
4種類のアプリケーションコンテキスト、JNDI、クラスローダ、セキュリティ、ワークエリアが伝播されます。伝播されたコンテキストタイプは4種類のコンカレント管理対象オブジェクトと同じものです。

Self Tuning(for short-running tasks)

上図で、管理対象エグゼキュータ・サービスが短時間実行されるタスクをワークマネージャに対して発行すること、長時間実行されるタスク用に新たなスレッドを生成することがわかります。
Workload Management in WebLogic Server 9.0
http://www.oracle.com/technetwork/articles/entarch/workload-management-088692.html
ご存じかもしれませんが、WebLogic Serverは、一定期間（デフォルトでは10分）スレッドが引き続き動作している（アイドル状態ではない）場合、スタックしたと判断します。そのため、通常はタスクはその時間を超えて継続する場合、長時間実行するタスクの可能性があります。ManagedTask.LONGRUNNING_HINTプロパティ（JSR 236の仕様をご覧ください）にtrueを設定し、長時間実行するタスクとして実行させることができます。
JSR 236: Concurrency Utilities for JavaTM EE
https://jcp.org/en/jsr/detail?id=236
各管理対象エグゼキュータ・サービスはアプリケーションスコープのワークマネージャと関連づけられています。デフォルトでは、管理対象エグゼキュータ・サービスはアプリケーションのデフォルトのワークマネージャと関連付けられています。アプリケーションやシステムの管理者はディスパッチ・ポリシーを指定し、管理対象エグゼキュータ・サービスをアプリケーションスコープのワークマネージャと関連付けることができます。後の章でディスパッチ・ポリシーの利用例をご紹介します。
管理対象エグゼキュータ・サービスをワークマネージャと関連付けることで、WebLogic Serverはシングルスレッドプールのスレッドを活用し、非同期タスクをアプリケーションから実行します。非同期タスクはServletやRMIリクエストとともに動的に優先度を付けることもできます。

Limit of Concurrent Long-running Requests

前述の通り、長時間実行するタスクはシングルスレッドプールのスレッドを活用せず、WebLogic Serverが各タスク用に新規のスレッドを作成します。過剰に多くの実行中スレッドが存在するとサーバーのパフォーマンスと安定性に影響を及ぼす可能性があるため、WebLogic Serverは、同時長時間実行リクエストの最大数を管理対象エグゼキュータ・サービス/ManagedScheduledExecutorService（管理対象スケジュール済エグゼキュータ・サービス）インスタンス、サーバのグローバル（ドメインレベル）ランタイム、サーバにて提供します。デフォルト設定は以下のようになっています。
  • 管理対象エグゼキュータ・サービス/ 管理対象スケジュール済エグゼキュータ・サービス・インスタンス：10
  • サーバーのグローバル（ドメインレベル）ランタイム：50
  • サーバ：100
制限のいずれかを超過すると、管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスはRejectedExecutionExceptionをスローすることによって長時間実行タスクの発行を拒否します。
グローバル（ドメインレベル）ランタイムスコープの同時長時間実行リクエストの最大数と、サーバスコープの同時長時間実行リクエストの最大数に違いがあることにご注意ください。WebLogic Server 12.2.1の重要な機能の一つはMultitenancyのサポートで、一つのWebLogic Serverドメインに複数のパーティションを含めることができます。グローバル（ドメインレベル）ランタイムスコープの同時長時間実行リクエストの最大数は、グローバル（ドメインレベル）ランタイム用のサーバ上の管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスの全てが発行した同時長時間実行タスクの最大数であり、これはサーバ上で動作しているパーティションスコープ内で発行された同時長時間実行タスクを除くのに対し、サーバスコープの同時長時間実行リクエストの最大数は、サーバ上の管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスの全てが発行した同時長時間実行タスクの最大数であり、これにはグローバル（ドメインレベル）のランタイム、パーティション内で発行された同時長時間実行タスクを含みます。パーティションスコープの同時長時間実行タスクの最大数については、Part 5 - Multitenancy supportのエントリをご覧下さい。
Concurrency Utilities support in WebLogic Server 12.2.1, Part Five: Multi-tenancy Support
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic5
http://orablogs-jp.blogspot.jp/2015/12/concurrency-utilities-support-in_41.html
管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスは3個の制限のいずれも超えない場合のみ、同時長時間実行タスクの発行を受け付けます。例えば、サーバーのグローバル（ドメインレベル）ランタイムにデプロイされたアプリケーションがあって、長時間実行中のタスクをデフォルトの管理対象エグゼキュータ・サービスに発行したとします。そこで、
  • 管理対象エグゼキュータ・サービスに発行された進行中の長時間実行タスクが10個ある
  • グローバル（ドメインレベル）ランタイムスコープの管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスに発行された進行中の長時間実行タスクが50個ある
  • サーバの管理対象エグゼキュータ・サービス/管理対象スケジュール済エグゼキュータ・サービスに発行された進行中の長時間実行タスクが100個ある
のいずれかの場合に、RejectedExecutionExceptionがスローされます。同時長時間実行タスクの最大数の設定方法は後の章でご紹介します。

Configuration

前述の通り、各アプリケーションは個々の管理対象エグゼキュータ・サービスを持ちます。デフォルトの管理対象エグゼキュータ・サービスはデフォルトのワークマネージャと関連付けられており、次の設定値がデフォルトで設定されています。
  • 同時長時間実行タスクの最大数：10
  • スレッド優先度：Thread.NORM_PRIORITY
また、
  • サーバ全体に対する同時長時間実行タスクの最大数：100
がデフォルトで設定されています。デフォルトの設定が十分ではない場合、設定方法を記載していますので続きを読んでください。例えば、事前定義済みのワークマネージャに対する短時間実行タスクをより高い優先度で関連付ける場合、管理対象エグゼキュータ・サービスを構成する必要がありますし、サーバで同時長時間実行タスクが100を超える場合にはサーバスコープの同時長時間実行タスクの最大数を変更する必要があるでしょう。

Configure ManagedExecutorServices

名前、ディスパッチ・ポリシー、長時間実行リクエストの最大数、長時間実行プライオリティを管理対象エグゼキュータ・サービス内で設定します。
  • 名前：管理対象エグゼキュータ・サービスを識別する文字列
  • ディスパッチ・ポリシー：短時間実行タスクを発行するワークマネージャの名前
  • 最大同時長時間リクエスト：この管理対象エグゼキュータ・サービスに発行された同時長時間実行タスク個数の上限
  • 長時間実行の優先度：長時間実行タスクのために作成されたスレッドの優先度 
アプリケーションはDD（デプロイメント・ディスクリプタ：weblogic-application.xml/weblogic-ejb-jar.xml/weblogic.xml）で管理対象エグゼキュータ・サービスを構成できます。管理対象エグゼキュータ・サービス・インスタンスを@Resource(mappedName=<管理対象エグゼキュータ・サービスの名前>)で取得してから、タスクを発行します。アノテーションの他に、DDで<resource-env-description> と <resource-env-ref> を指定することで、アプリケーションは管理対象エグゼキュータ・サービス・インスタンスをJNDIにバインドすれば、JNDI Naming Contextを使って検索します。詳細は以下の製品ドキュメントをご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
また、WebLogicシステム管理者は事前定義済みの管理対象エグゼキュータ・サービス・テンプレートを構成することができます。アプリケーションをデプロイすると、WebLogic Serverが管理対象エグゼキュータ・サービス・テンプレートの設定に基づいて管理対象エグゼキュータ・サービスを作成します。作成された管理対象エグゼキュータ・サービスは全てこのアプリケーションのスコープに入っています。

Example-2: Configure a ManagedExecutorService in weblogic.xml

Step1）
管理対象エグゼキュータ・サービスを定義します
<!-- weblogic.xml --> 
<work-manager>
   <name>customizedWM</name>
  <max-threads-constraint>
    <name>max</name>
    <count>1</count>
   </max-threads-constraint>
</work-manager>
<managed-executor-service>
  <name>customizedMES</name>
  <dispatch-policy>customizedWM</dispatch-policy>
  <long-running-priority>10</long-running-priority>
  <max-concurrent-long-running-requests>20</max-concurrent-long-running-requests>
</managed-executor-service>
Step2）
管理対象エグゼキュータ・サービス・インスタンスを取得して利用します
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource(mappedName="customizedMES")
     ManagedExecutorService mes;

     protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
         Runnable aTask = new Runnable() {
             ...
         };
         mes.submit(aTask);
         ...
    }
}

Example-3: Configure a ManagedExecutorService template using WebLogic Administration Console

個別アプリケーションではなく複数のアプリケーションに要件がある場合、管理対象エグゼキュータ・サービス・テンプレートをグローバルに作成して全てのアプリケーションで利用可能にすることができます。例えば、すべてのアプリケーションから低優先度の短時間実行タスクを実行する必要がある場合、管理対象エグゼキュータ・サービス・テンプレートを構成する必要があります。管理対象エグゼキュータ・サービス・テンプレートはバッチジョブでも有用です。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Prerequisite Steps Configure the JobRepository Tables, Batch Data Source, and Managed Executor Service
https://docs.oracle.com/middleware/1221/wls/CNFGD/batch-apps.htm#CNFGD374
前述の通り、管理対象エグゼキュータ・サービス・テンプレートがある場合、WebLogic Serverは管理対象エグゼキュータ・サービス・インスタンスをテンプレートの設定に従って各アプリケーション用に作成します。

Step1）
WebLogic Server管理コンソールから、同時管理対象オブジェクト・テンプレートのサマリーのページで、［新規］をクリックすると、管理対象エグゼキュータ・サービス・テンプレートを作成することができます。［管理対象エグゼキュータ・サービス・テンプレートの作成］ページで、管理対象エグゼキュータ・サービス・テンプレートの名前やその他のパラメータを指定することができます。この例では、testMESという管理対象エグゼキュータ・サービス・テンプレートを作成し、testWMという事前定義済みワークマネージャにマッピングしています。

Step2）
管理対象エグゼキュータ・サービス・テンプレートを作成すると、WebLogic Serverの任意のアプリケーションは管理対象エグゼキュータ・サービス・インスタンスを取得して利用することができます。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {

    @Resource(mappedName="testMES")
    ManagedExecutorService mes;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        mes.submit(aTask);
        ...
    }
}

Configure Max Concurrent Long Running Requests Running in global (domain-level) runtime scope or server scope


Example-4: Configure global (domain-level) runtime Scope Max Concurrent Long Running Requests

グローバル（ドメインレベル）ランタイムの最大同時長時間リクエストとは、サーバのグローバル（ドメインレベル）ランタイムの全ての管理対象エグゼキュータ・サービスやManagedScheduledExecutorServiceに対して発行された同時長時間実行タスク個数の上限です。これには当該サーバで動作しているパーティションスコープ内で発行された長時間実行タスクを含まれません。
WebLogic Server管理コンソールの［（ドメイン名）の設定］画面で、グローバル（ドメインレベル）ランタイムの最大同時長時間リクエストを編集できます。この例では、base_domainのグローバル（ドメインレベル）ランタイムの最大同時長時間リクエストを80に設定しています。


Example-5: Configure Server Scope Max Concurrent Long Running Requests

サーバの最大同時長時間リクエストとは、当該サーバの全ての管理対象エグゼキュータ・サービスと管理対象スケジュール済エグゼキュータ・サービスに対して発行された同時長時間実行タスク個数の上限です。
WebLogic Server管理コンソールの［（サーバ名）の設定］画面で、サーバの最大同時長時間リクエストを編集できます。この例では、myserverの最大同時長時間リクエストを200に設定しています。


Related Articles:

詳細は、ドキュメントの以下の項をご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1, Part Two: ManagedScheduledExecutorService

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic2

Overview

ManagedScheduledExecutorService（管理対象スケジュール済エグゼキュータ・サービス）はManagedExecutorService（管理対象エグゼキュータ・サービス）を拡張したもので、管理対象エグゼキュータ・サービス由来の全てのメソッドは管理対象スケジュール済エグゼキュータ・サービスでサポートされています。それゆえ、この記事の前に是非Part 1をお読み下さい。
Concurrency Utilities support in WebLogic Server 12.2.1, Part One: ManagedExecutorService
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic1
http://orablogs-jp.blogspot.jp/2015/12/concurrency-utilities-support-in_66.html
管理対象スケジュール済エグゼキュータ・サービスはjava.util.concurrent.ScheduledExecutorServiceを拡張したものゆえ、特定の遅延後もしくは定期的に実行するタスクのスケジュールのためのScheduledExecutorService由来のメソッド（schedule、scheduleAtFixedRate、scheduleAtFixedDelay）を提供します。それ以外に、管理対象スケジュール済エグゼキュータ・サービスは、トリガーベースのカスタムスケジュールでタスクを動作するための新たなメソッドを提供します。こうした全てのタスクはWebLogic Serverが提供するスレッド上で動作します。
Weblogic Serverはデフォルトの事前構成済み管理対象スケジュール済エグゼキュータ・サービスを各アプリケーションのために提供しているので、これを設定せずにWebコンポーネントやEJBコンポーネントで簡単に利用できます。デフォルトの管理対象スケジュール済エグゼキュータ・サービスをServletContextListenerで使うという簡単な例から始めましょう。

Example-1: Use Default ManagedScheduledExecutorService to Submit a Periodical Task

Step1）
データをログ出力するタスクを作成します。
public class LoggerTask implements Runnable {
    @Override
    public void run() {
        // collect data and write them to database or file system
    }
}
Step2）
SomeListener.javaがデフォルトの管理対象スケジュール済エグゼキュータ・サービスを注入します。このコードはcontextInitializedでタスクを定期的にスケジューリングし、contextDestroyedでタスクをキャンセルします。
@WebListener
public class SomeListener implements ServletContextListener {
    Future loggerHandle = null;
    @Resource ManagedScheduledExecutorService mses;


    public void contextInitialized(ServletContextEvent scEvent) {
        // Creates and executes LoggerTask every 5 seconds, beginning at 1 second later 
        loggerHandle = mses.scheduleAtFixedRate(new LoggerTask(), 1, 5, TimeUnit.SECONDS);
    }

    public void contextDestroyed(ServletContextEvent scEvent) {
        // Cancel and interrupt our logger task
        if (loggerHandle != null) {
            loggerHandle.cancel(true);
        }
    }
}

Runtime Behavior

管理対象スケジュール済エグゼキュータ・サービスはPart 1のRuntime Behaviorで説明したすべての機能を提供します。
Concurrency Utilities support in WebLogic Server 12.2.1, Part One: ManagedExecutorService
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic1
http://orablogs-jp.blogspot.jp/2015/12/concurrency-utilities-support-in_66.html
前述の通り、管理対象スケジュール済エグゼキュータ・サービスはタスクを定期的もしくはカスタムスケジュールで実行することができるので、タスクは複数回実行される可能性があります。長時間実行タスクの場合、タスクが1回以上実行されるとしても、WebLogic Serverは最初の実行時にこの長時間実行タスクのために1スレッドのみ作成します。

Configuration


Configure ManagedScheduledExecutorService

管理対象スケジュール済エグゼキュータ・サービスには管理対象エグゼキュータ・サービスと同じ構成（名前、ディスパッチ・ポリシー、最大同時長時間リクエスト、長時間実行の優先度）があります。カスタマイズされた管理対象スケジュール済エグゼキュータ・サービスを取得、利用する方法もまた管理対象エグゼキュータ・サービスに似ています。

Example-2: Configure a ManagedScheduledExecutorService in weblogic.xml

Step1）
管理対象スケジュール済エグゼキュータ・サービスを定義します。
<!-- weblogic.xml -->
<work-manager>
 <name>customizedWM</name>
    <max-threads-constraint>
        <name>max</name>
        <count>1</count>
    </max-threads-constraint>
</work-manager>
<managed-scheduled-executor-service>
    <name>customizedMSES</name>
    <dispatch-policy>customizedWM</dispatch-policy>
    <long-running-priority>10</long-running-priority>
    <max-concurrent-long-running-requests>20</max-concurrent-long-running-requests>
</managed-scheduled-executor-service>
Step2）
管理対象スケジュール済エグゼキュータ・サービス・インスタンスを取得して利用します。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource(mappedName="customizedMSES")
    ManagedScheduledExecutorService mses;


    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        mses.schedule(aTask, 5, TimeUnit.SECONDS);
        ...
    }
}

Example-3: Configure a ManagedScheduledExecutorService template using WebLogic Administration Console

Step1）
WebLogic Server管理コンソールで、［同時管理対象オブジェクト・テンプレートのサマリ］ページで［新規］ボタンをクリックすると、管理対象スケジュール済エグゼキュータ・サービス・テンプレートを作成することができます。［新規管理対象スケジュール済エグゼキュータ・サービス・テンプレートの作成］ページで、新たな管理対象スケジュール済エグゼキュータ・サービス・テンプレートの名前やその他のパラメータを指定することができます。この例では、testMSESという管理対象スケジュール済エグゼキュータ・サービスを作成し、事前定義済みのワークマネージャtestWMにマッピングしています。

Step2）
管理対象スケジュール済エグゼキュータ・サービス・テンプレートを作成したら、WebLogic Serverの任意のアプリケーションが自身の管理対象スケジュール済エグゼキュータ・サービス・インスタンスを取得して利用することができます。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource(mappedName="testMSES")
    ManagedScheduledExecutorService mses;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        mses.schedule(aTask, 5, TimeUnit.SECONDS);
        ...
    }
}

Related Articles:

詳細は、ドキュメントの以下の項をご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1, Part Three: ManagedThreadFactory

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic3

Overview

ManagedThreadFactory（管理対象スレッド・ファクトリ）はWebLogic Serverが管理するスレッドを作成するために存在します。これはjava.util.concurrent.ThreadFactoryを拡張したもので、新規追加されたメソッドはありません。この管理対象スレッド・ファクトリはThreadFactory由来のnewThreadメソッドを提供し、ThreadFactoryを必要とする、例えばjava.util.concurrent.ExecutorsでJava SE concurrency utilities APIとともに利用できます。
Weblogic Serverは各アプリケーションに対しデフォルトの事前構成済み管理対象スレッド・ファクトリを提供しているので、アプリケーションはWebコンポーネントやEJBコンポーネントで設定しなくても簡単に利用できます。Servletでデフォルトの管理対象スレッド・ファクトリを使う簡単な例からはじめてみましょう。

Example-1: Use Default ManagedThreadFactory to Create a Thread in a Servlet

Step1）
スレッドが中断されるまでデータをログ出力するRunnableなメソッドを作成します。
public class LoggerTask implements Runnable {
    @Override
    public void run() {
        while (!Thread.interrupted()) {
            // collect data and write them to database or file system
        }
    }
}
Step2）
SomeServlet.javaがデフォルトの管理対象スレッド・ファクトリを注入し、スレッド作成に利用します。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource ManagedThreadFactory mtf;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Thread t = mtf.newThread(new LoggerTask());
        t.start();
        // Do something else and reply to the user
    }
}

Runtime Behavior

Application Scoped Instance

管理対象スレッド・ファクトリはアプリケーション・スコープです。各アプリケーションは自身で管理対象スレッド・ファクトリ・インスタンスを持っており、管理対象スレッド・ファクトリ・インスタンスのライフサイクルはアプリケーションにバインドされています。管理対象スレッド・ファクトリが作成したスレッドもまたアプリケーション・スコープなので、アプリケーションが停止した場合、関連するスレッドも中断されます。
各アプリケーションは自身でデフォルトの管理対象スレッド・ファクトリ・インスタンスを持っていますが、その他に、アプリケーション管理者やシステム管理者がカスタマイズされた管理対象スレッド・ファクトリを定義することができます。WebLogic Server管理コンソールでグローバルに定義された管理対象スレッド・ファクトリ・テンプレート（後でご紹介します）であってもランタイムではアプリケーション・スコープであることにご注意ください。

Context Propagation

管理対象スレッド・ファクトリは管理対象スレッド・ファクトリ作成時にアプリケーション・コンテキストを取得（newThreadメソッドを呼び出したタイミングではありません）し、取得したアプリケーション・コンテキストをタスク実行前に伝播するので、タスクもまたアプリケーション・コンテキストを持って実行できます。
以下の4種類のアプリケーション・コンテキストが伝播されます。
  • JNDI
  • クラスローダ（ClassLoader）
  • セキュリティ（Security）
  • ワークエリア（WorkArea）
伝播されたコンテキストタイプは4種類の同時管理対象オブジェクトの4種類と同じです。

Limit of Running Threads

newThreadメソッドが呼び出されると、WebLogic Serverは新しいスレッドを作成します。実行中スレッドの個数が過大である場合、サーバパフォーマンスや安定性に悪影響を与えるため、WebLogic Serverは管理対象スレッド・ファクトリの実行中スレッドの個数を制限するための設定（最大同時新規スレッド）をインスタンス、サーバのグローバル（ドメインレベル）ランタイム、サーバで提供しています。デフォルト設定値は以下の通りです。
  • 10：管理対象スレッド・ファクトリ・インスタンス
  • 50：サーバのグローバル（ドメインレベル）ランタイム
  • 100：サーバ
いずれかの制限を超えた場合、管理対象スレッド・ファクトリのnewThread()メソッド呼び出しでnullを返します。
グローバル（ドメインレベル）ランタイムスコープの最大同時新規スレッドと、サーバスコープの最大同時新規スレッドの違いに着目してください。WebLogic Server 12.2.1の重要機能の一つが、単一のWebLogic Serverドメインには複数のパーティションを含めることができるMultitenancyサポートです。グローバル（ドメインレベル）ランタイムの最大同時新規スレッドとは、グローバル（ドメインレベル）ランタイムのために、すべてのサーバの管理対象スレッド・ファクトリが作成したスレッドの最大個数であって、これにはサーバで動作するパーティションスコープ内で作成されたスレッドは含まれません。対して、サーバスコープの最大同時新規スレッドとはサーバのすべての管理対象スレッド・ファクトリが作成したスレッドの最大個数ですが、こちらの場合はパーティションのスコープ内で作成されたスレッドを含みます。パーティションスコープの最大同時新規スレッドについては、Part 5 - Multitenancy supportのエントリをご覧下さい。
Concurrency Utilities support in WebLogic Server 12.2.1, Part Five: Multi-tenancy Support
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic5
http://orablogs-jp.blogspot.jp/2015/12/concurrency-utilities-support-in_41.html
管理対象スレッド・ファクトリは3個の上限値をいずれも超えない場合にのみ新たなスレッドを返します。例えば、サーバのグローバル（ドメインレベル）ランタイムにデプロイされたアプリケーションがあって、ServletやEJBがデフォルトの管理対象スレッド・ファクトリのnewThreadメソッドを呼び出したとしましょう。そこで
  • この管理対象スレッド・ファクトリが作成した10個の実行中スレッドがある
  • サーバのグローバル（ドメインレベル）ランタイムスコープの管理対象スレッド・ファクトリが作成した50個の実行中スレッドがある
  • サーバの管理対象スレッド・ファクトリが作成した100個の実行中スレッドがある
のいずれかの場合にnullを返します。後の章で最大同時新規スレッドの指定方法の例をご紹介します。

Configuration

前述の通り、各アプリケーションは自身でデフォルトの管理対象スレッド・ファクトリを持っており、以下の値がデフォルトで設定されています。
  • 最大同時スレッド数：10
  • デフォルトスレッド優先度：Thread.NORM_PRIORITY
また、
  • サーバ全体に対する最大同時スレッド数：100
がデフォルトで設定されています。デフォルトの設定が十分ではない場合、設定方法を記載していますので続きを読んでください。例えば、より高い優先度を持つスレッドを作成する必要がある場合、管理対象スレッド・ファクトリを構成する必要がありますし、100個を上回る同時実行スレッドがサーバに存在する可能性がある場合、サーバスコープの最大同時新規スレッドを変更する必要があるでしょう。

Configure ManagedThreadFactories

名前、最大同時新規スレッド、優先度を管理対象スレッド・ファクトリ内で構成します。
  • 名前：管理対象スレッド・ファクトリを識別する文字列
  • 最大同時新規スレッド：管理対象スレッド・ファクトリが作成する実行スレッド数の上限
  • 優先度：スレッドの優先度
アプリケーションはDD（デプロイメント・ディスクリプタ：weblogic-application.xml/weblogic-ejb-jar.xml/weblogic.xml）で管理対象スレッド・ファクトリを構成することができます。その管理対象スレッド・ファクトリ・インスタンスを@Resource(mappedName=<管理対象スレッド・ファクトリの名前>)で取得してスレッドを作成します。アノテーションの他に、アプリケーションは管理対象スレッド・ファクトリ・インスタンスを<resource-env-description>や<resource-env-ref>をDDで指定することで、JNDIにバインドすれば、JNDI Naming Contextを使って検索することができます。詳細は以下の製品ドキュメントをご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
また、WebLogicシステム管理者は事前定義済みの管理対象スレッド・ファクトリ・テンプレートを構成することができます。アプリケーションをデプロイすると、WebLogic Serverが管理対象スレッド・ファクトリ・テンプレートの設定に基づいて管理対象スレッド・ファクトリを作成します。作成された管理対象スレッド・ファクトリは全てこのアプリケーションのスコープに入っています。

Example-2: Configure a ManagedThreadFactory in weblogic.xml

Step1）
管理対象スレッド・ファクトリを定義します。
<!-- weblogic.xml -->
<managed-thread-factory>
    <name>customizedMTF</name>
    <priority>3</priority>
    <max-concurrent-new-threads>20</max-concurrent-new-threads>
</managed-thread-factory>
Step2）
管理対象スレッド・ファクトリ・インスタンスを取得して利用します。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {

    @Resource(mappedName="customizedMTF")
    ManagedThreadFactory mtf;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        Thread t = mtf.newThread(aTask);
        t.start();
        ...
    }
}

Example-3: Configure a ManagedThreadFactory template using WebLogic Administration Console

個別アプリケーションではなく複数のアプリケーションに要件がある場合、管理対象スレッド・ファクトリ・テンプレートをグローバルに作成して全てのアプリケーションで利用可能にすることができます。例えば、すべてのアプリケーションから低優先度のスレッドを作成する必要がある場合、管理対象スレッド・ファクトリ・テンプレートを構成する必要があります。前述のように、管理対象スレッド・ファクトリ・テンプレートがあれば、WebLogic Serverはテンプレートの設定に基づいて管理対象スレッド・ファクトリ・インスタンスを各アプリケーションのために作成します。

Step1）
WebLogic Server管理コンソールから、同時管理対象オブジェクト・テンプレートのサマリーのページで、［新規］をクリックすると、管理対象スレッド・ファクトリ・テンプレートを作成することができます。［管理対象スレッド・ファクトリ・テンプレートの作成］ページで、管理対象スレッド・ファクトリ・テンプレートの名前やその他のパラメータを指定することができます。この例では、優先度3を持つtestMTFという管理対象スレッド・ファクトリ・テンプレートを作成しています。



Step2）
管理対象スレッド・ファクトリ・テンプレートを作成すると、WebLogic Serverの任意のアプリケーションが自身の管理対象スレッド・ファクトリ・インスタンスを取得して利用することができます。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {

    @Resource(mappedName="testMTF")
    ManagedThreadFactory mtf;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        Thread t = mtf.newThread(aTask);
        t.start();
        ...
    }
}

Configure Max Concurrent New Threads in global (domain-level) runtime scope or server scope


Example-4: Configure global (domain-level) runtime Scope Max Concurrent New Threads

グローバル（ドメインレベル）ランタイムの最大同時新規スレッドとは、サーバのグローバル（ドメインレベル）ランタイムの管理対象スレッド・ファクトリが作成するスレッド数の上限であり、これには当該サーバで動作するパーティションスコープ内で作成されたスレッドの個数は含まれません。
WebLogic Server管理コンソールの［（ドメイン名）の設定］画面で、グローバル（ドメインレベル）ランタイムの最大同時新規スレッド数を編集できます。この例では、base_domainのグローバル（ドメインレベル）ランタイムの最大同時新規スレッドを100に設定しています。

Example-5: Configure Server Scope Max Concurrent New Threads

サーバの最大同時新規スレッドは当該サーバのすべての管理対象スレッド・ファクトリが作成する実行スレッド数の上限です。
WebLogic Server管理コンソールの［（サーバ名）の設定］画面で、サーバの最大同時新規スレッドを編集できます。この例では、myserverの最大同時新規スレッドを200に設定しています。


Related Articles:

詳細は、ドキュメントの以下の項をご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1, Part Four: ContextService

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic4

Overview

ContextService（コンテキスト・サービス）はコンテキストのプロキシオブジェクトを生成するためにあり、プロキシオブジェクトを作成するためのcreateContextualProxyメソッドを提供しています。このプロキシオブジェクトメソッドは後に取得したコンテキスト内で動作します。
Weblogic Serverではデフォルトの事前構成済みコンテキスト・サービスを提供しているため、アプリケーションは設定せずにWebコンポーネントやEJBコンポーネントで簡単に利用できます。ではデフォルトのコンテキスト・サービスを使う簡単な例から始めましょう。

Example-1: Execute a task with the creator's context using a ExecutorService

Step1）
タスクを作成します。この例ではタスクはRunnableを拡張しています。
public class SomeTask implements Runnable {
    public void run() {
        // do some work
    }
}
Step2）
SomeServlet.javaはデフォルトのコンテキスト・サービスを注入し、そのコンテキスト・サービスを使って新しいコンテキスト・オブジェクト・プロキシをSomeTaskのために作成した上で、コンテキスト・オブジェクト・プロキシをJava SEのExecutorServiceに対して発行します。run()メソッドの各呼び出しはコンテキスト・オブジェクト・プロキシを作成したServletのコンテキストを有しています。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {
    @Resource ContextService cs;

    @Resource ManagedThreadFactory mtf;
    ExecutorService exSvc = Executors.newThreadPool(10, mtf);

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        SomeTask taskInstance = new SomeTask();
        Runnable rProxy = cs.createContextualProxy(taskInstance, Runnable.class);
        Future f =  = exSvc.submit(rProxy);

        // Process the result and reply to the user
    }
}

Runtime Behavior


Application Scoped Instance

コンテキスト・サービスはアプリケーション・スコープで、各アプリケーションには自身でデフォルトのコンテキスト・サービス・インスタンスを持っており、コンテキスト・サービス・インスタンスのライフサイクルはアプリケーションにバインドされています。コンテキスト・サービスが作成するプロキシ・オブジェクトもまたアプリケーション・スコープゆえ、アプリケーションが停止すると、インターフェースへのプロキシメソッドの呼び出しはIllegalStateExceptionをスローして失敗しますし、createContextualProxy()の呼び出しもまたIllegalArgumentExceptionをスローします。
WebLogic Serverはデフォルトのコンテキスト・サービス・インスタンスを各アプリケーションのために提供するだけで、コンテキスト・サービスの設定方法は提供しません。

Context Propagation

コンテキスト・サービスはコンテキスト・プロキシ・オブジェクト作成時にアプリケーション・コンテキストを取得し、コンテキスト・プロキシ・オブジェクトのメソッドを呼び出す前にその取得したアプリケーションコンテキストを伝播します。そのため、プロキシ・オブジェクト・メソッドもまた、アプリケーション・コンテキストを有して実行することができます。
以下の4種類のアプリケーション・コンテキストが伝播されます。

  • JNDI
  • クラスローダ（ClassLoader）
  • セキュリティ（Security）
  • ワークエリア（WorkArea）

伝播されるコンテキストの種類は同時管理対象オブジェクトの4種類と同じです。

Related Articles:

詳細は、ドキュメントの以下の項をご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Concurrency Utilities support in WebLogic Server 12.2.1, Part Five: Multi-tenancy Support

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/concurrency_utilities_support_in_weblogic5

Overview

WebLogic Server 12.2.1の主要機能の一つがMultitenancyのサポートで、これは単一のWebLogic Serverドメインに複数のパーティションを含めることができるというものです。この記事を読む前に、Part 1からPart 4までの記事をご覧ください。パーティションにデプロイされたアプリケーションは、Part 1からPart 4と同様、4種類の同時管理対象オブジェクト（concurrent managed object）を利用することができますし、また、グローバルの事前定義済み同時管理対象オブジェクト・テンプレート（concurrent managed object template）を使うこともできます。このテンプレートはアプリケーションをパーティションにデプロイした場合に、WebLogic Serverがこのアプリケーションのための同時管理対象オブジェクトをグローバル同時管理対象オブジェクト・テンプレートに基づいて作成します。思い出されるかもしれませんが、サーバ・スコープの最大同時長時間リクエスト（Max Concurrent Long Running Requests）と最大同時新規スレッド（Max Concurrent New Threads）があります。これらの設定はサーバ全体の長時間実行リクエスト、実行スレッドを制限するもので、これにはパーティションも含まれることにご注意ください。

Configuration

システム管理者はパーティション・スコープの同時管理対象オブジェクト・テンプレートを定義することができます。
Part 1（管理対象エグゼキュータ・サービス：ManagedExecutorService）やPart 3（管理対象スレッド・ファクトリ：ManagedThreadFactory）で述べたように、WebLogic Serverは同時実行タスクやスレッドの個数を制限する設定（最大同時長時間リクエストと最大同時新規スレッド）を以下のスコープに対して提供しています。
  • 管理対象エグゼキュータ・サービス（ManagedExecutorService）、管理対象スケジュール済エグゼキュータ・サービス（ManagedScheduledExecutorService）、管理対象スレッド・ファクトリ（ManagedThreadFactory）の各インスタンス
  • サーバのグローバル（ドメインレベル）ランタイム
  • サーバ
これらの中で、インスタンス・スコープとサーバ・スコープの制限はパーティションにも適用できます。その他に、システム管理者はパーティション・スコープの最大同時長時間リクエストと最大同時新規スレッドを定義することもできます。デフォルトの設定値は以下の通りです。
  • パーティション・スコープの最大同時長時間リクエスト：50
  • パーティション・スコープの最大同時新規スレッド：50
管理対象エグゼキュータ・サービス、管理対象スケジュール済エグゼキュータ・サービス、管理対象スレッド・ファクトリは、それぞれの3個の制限をいずれも超えない場合に限り、長時間実行タスクの発行、新規スレッドの作成を受け入れます。例えば、サーバのパーティションにデプロイされたアプリケーションがあり、長時間実行タスクがデフォルトの管理対象エグゼキュータ・サービスに対して発行されるとしましょう。以下の条件のいずれかに該当する場合、RejectedExecutionExceptionがスローされます。
  • この管理対象エグゼキュータ・サービスに対して発行されている10個の長時間実行タスクが進行中
  • このパーティション・スコープにある管理対象エグゼキュータ・サービスや管理対象スケジュール済エグゼキュータ・サービスに対して発行されている50個の長時間実行タスクが進行中
  • このサーバの管理対象エグゼキュータ・サービスや管理対象スケジュール済エグゼキュータ・サービスに対して発行されている100個の長時間実行タスクが進行中

Configure Partition Scope Concurrent Managed Object Templates

WebLogic Serverのシステム管理者はパーティションのために事前定義済みの同時管理対象オブジェクト・テンプレートを構成することができます。アプリケーションをパーティションにデプロイすると、WebLogic Serverは同時管理対象オブジェクト・インスタンスをパーティション・スコープの同時管理対象オブジェクト・テンプレートの設定に基づいて作成します。そしてこの作成された同時管理対象オブジェクト・インスタンスはすべてこのアプリケーションのスコープに入ります。

Example-1: Configure a Partition Scope ManagedThreadFactory template using WebLogic Administration Console

Step1）
WebLogic Server管理コンソールで［同時管理対象オブジェクト・テンプレートのサマリ］の［新規］ボタンをクリックすると、パーティション・スコープの管理対象スレッド・ファクトリ・テンプレートを作成することができます。［新規管理対象スレッド・ファクトリ・テンプレートの作成］ページが開くので、新たな管理対象スレッド・ファクトリ・テンプレートの名前やその他のパラメータを指定することができます。スコープをパーティションに選択してください。この例では、testMTFP1という管理対象スレッド・ファクトリ・テンプレートを　partition1パーティションのために作成しています。


Step2）
パーティション・スコープの管理対象スレッド・ファクトリ・テンプレートを作成したら、当該パーティション上の任意のアプリケーションが自身のデフォルト管理対象スレッド・ファクトリ・インスタンスを取得し、利用することができます。
@WebServlet("/SomeServlet")
public class SomeServlet extends HttpServlet {

    @Resource(mappedName="testMTFP1")
    ManagedThreadFactory mtf;

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        Runnable aTask = new Runnable() {
            ...
        };
        Thread t = mtf.newThread(aTask);
        t.start();
        ...
    }
}

Configure Partition Scope Max Concurrent New Threads & Max Concurrent Long Running Requests

パーティションの最大同時新規スレッドは、サーバの当該パーティションにおけるすべての管理対象スレッド・ファクトリが作成するスレッドの制限です。パーティションの最大同時長時間リクエストは、サーバの当該パーティションで管理対象エグゼキュータ・サービスや管理対象スケジュール済エグゼキュータ・サービスに対して発行された同時長時間タスクの制限です。

パーティションの最大同時新規スレッドと最大同時長時間リクエストは、WebLogic Server管理コンソールの［（パーティション名）の設定］ページで編集することができます。この例では、partition1パーティションの最大同時新規スレッド、最大同時長時間リクエストをそれぞれ30と80に設定しています。


Related Articles:

詳細は、ドキュメントの以下の項をご覧下さい。
Oracle® Fusion Middleware Administering Server Environments for Oracle WebLogic Server 12c (12.2.1)
Configuring Concurrent Managed Objects
https://docs.oracle.com/middleware/1221/wls/CNFGD/concurrent-utils.htm#CNFGD359
- 0 件のコメント:
カテゴリ ,

[Java] Latest Java 9 News

原文はこちら。
https://blogs.oracle.com/java/entry/java_9_news
Javaの次期メジャーリリースであるJava 9では、Java SEプラットフォーム、JDKにモジュールシステムが導入されます。Java 9の作業は引き続いており、新たな提案スケジュール、バージョン文字列体系、最新の機能について知ることができますし、早期アクセスビルドにもアクセスすることができます。

(1) マイルストンスケジュールの変更
新しいGA予定日は2017年3月です。以下はJava 9の提案されたマイルストンをまとめたものです。
2016/05/26  Feature Complete
2016/08/11  All Tests Run
2016/09/01  Rampdown Start
2016/10/20  Zero Bug Bounce
2016/12/01  Rampdown Phase 2
2017/01/26  Final Release Candidate
2017/03/23  General Availability
しばらくの間、ダウンロード、テスト用途で早期アクセスビルドが利用いただけます。
JDK 9 Early Access with Project Jigsaw
https://jdk9.java.net/jigsaw/
ダウンロードバイナリがありますので、ソースからビルドする必要はありません。

(2) JDKバージョン文字列体系の変更
Java 9では、JDKのバージョン文字列体系が変わります。
A New JDK 9 Version String Scheme
https://blogs.oracle.com/java-platform-group/entry/a_new_jdk_9_version
http://orablogs-jp.blogspot.jp/2015/12/a-new-jdk-9-version-string-scheme.html
体系は、マイナー、メジャー、およびクリティカル・パッチ・アップデート（CPU）のリリース番号を強調します。この新しい規約に従い、Major.Minor.Securityというバージョン文字列になります。

(3) JEPのステータス変更
議論やレビューを受けて、JEPのオーナーがいくつかのJava Enhancement Proposals (JEP)のステータスを"Proposed to Target"に変更しました。
JEPs proposed to target JDK 9 (2015/12/3)
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003297.html
対象となるJEPは以下の通りです。
271: Unified GC Logging
http://openjdk.java.net/jeps/271
278: Additional Tests for Humongous Objects in G1
http://openjdk.java.net/jeps/278
279: Improve Test-Failure Troubleshooting
http://openjdk.java.net/jeps/279
280: Indify String Concatenation
http://openjdk.java.net/jeps/280
- 0 件のコメント:
カテゴリ

[WLS] Three Easy Steps to a Patched Domain Using ZDT Patching and OPatchAuto

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/three_easy_steps_to_a
管理対象サーバーへ新しいパッチを適用されたOracleHomeを展開することで非常に簡単にWebLogic Server環境のアップデートができることがおわかりいただけたかと思います。それではさらに一歩すすめて、その操作の準備、配布の部分を自動化する方法を見ましょう。

ZDT PatchingはOPatchAutoと呼ばれる12.2.1の新しいすばらしいツールと統合しました。OPatchAutoは単一のインターフェースで、これを使うと、たった3ステップで、OracleHomeにパッチを適用し、パッチが適用されたOracleHomeをアップデートしたいすべてのノードに配布し、OracleHomeのロールアウトを開始することができます。

1. 最初のステップでは、目的のパッチやPatch Set Updateを本番環境のOracleHomeと組み合わせ、パッチを適用するOracleHomeアーカイブ（.jarファイル）を作成します。この操作はOracleHomeのコピーを作成するので、本番環境に影響しません。その後、指定したパッチをOracleHomeのコピーに適用し、そこからアーカイブを作成します。これはロールアウト時に使うアーカイブですが、まずはすべての対象とするノードにコピーする必要があります。

最初の手順では、以下のようなOPatchAutoコマンドを実行します。
${ORACLE_HOME}/OPatch/auto/core/bin/opatchauto.sh apply /pathTo/PatchHome -create-image -image-location /pathTo/image.jar –oop –oh /pathTo/OracleHome
ここで
  • PatchHome：適用するパッチやPatch Set Updateを含むディレクトリもしくはファイル
  • image-location：生成されるイメージファイルの配置場所
です。また、-oopは“out-of-place”を意味し、OpatchAutoにソースとなるOracleHomeをパッチ適用前にコピーするよう指示します。

2.  第2に、1で作成したパッチ適用済みのOracleHomeアーカイブをすべての対象ノードにコピーします。この手順の素敵なところは、OpatchAutoがZDT Patchingと統合されているため、OpatchAutoに対し、ZDT Patchingとともに使うターゲットを指定することができるので、ZDT Patchingが自動的にノードを計算するようOpatchAutoが依頼します。以下がこの手順におけるコマンド例です。
${ORACLE_HOME}/OPatch/auto/core/bin/opatchauto.sh apply -plan wls-push-image -image-location /pathTo/image.jar -wls-admin-host ${ADMINHOSTNAME}:7001 -wls-target Cluster1 -remote-image-location /pathTo/image.jar -wallet ${WALLET_DIR}
ここで
  • image-location：手順1で作成されたJarファイル
  • wls-target：ドメイン名、クラスタ名、もしくはクラスタのリスト
です。リモートホストに対するssh認可のwalletがまだない場合には作成しておく必要があります。

3.  最後の手順では、OPatchAutoを使ってZDT Patching OracleHomeロールアウトを呼び出します。WLSTにこの時点で切り替え、以前のエントリで説明したように開始することができますが、OPatchAutoはロールアウトの進捗を監視し、有用なフィードバックも返してくれます。OpatchAutoを使ってロールアウトを開始するコマンドの例です。
${ORACLE_HOME}/OPatch/auto/core/bin/opatchauto.sh apply -plan wls-zdt-rollout -image-location /pathTo/image.jar -wls-admin-host ${ADMINHOSTNAME}:7001 -wls-target Cluster1 -backup-home /pathTo/home-backup -remote-image-location /pathTo/image.jar -wallet ${WALLET_DIR}
ここで
  • image-location：手順1で作成されたJarファイル
  • backup-home：オリジナルのOracleHomeのバックアップを格納するための、各リモートノードの場所
です。image-location と remote-image-location は両方指定しておくと、ノードがイメージをなくした場合に自動的にコピーできます。これがここで再度walletが指定されている理由でもあります。

プロセス全体の自動化を見た際に考慮すべきもう一つの素晴らしい点は、これらの同じコマンドを使用して、同じパッチ適用済みOracleHomeアーカイブを検証のためにテスト環境に配布、ロールアウトすることが非常に簡単である、というところにあります。検証がすめば、同じ2つのコマンドを少々変更して、本番環境にまったく同じ（検証済みの）OracleHomeアーカイブをプッシュします。

Zero Downtime PatchingとOPatchAutoを使ったOracleHomeのアップデートに関する詳細は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Using OPatchAuto to Initiate, Revert, and Resume Rollouts
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT166
- 0 件のコメント:
カテゴリ

[WLS, Java] Multi-Tenancy EJB

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/multi_tenancy_ejb

Multi-Tenancy EJB

WLS12.2.1のマルチテナントサポートのおかげで、EJBコンテナは多くの拡張機能を手にしました。アプリケーションとリソースの「かけ算」により、パーティションのことを知らないままでも、EJBコンテナがマルチテナントの機能を提供することができます。別のアプリケーションのコピーがあるおかげで、異なるリモートオブジェクト、Beansプール、キャッシュ、モジュールクラスローダーインスタンスなどにも分離をもたらします。以下でEJBアプリケーションで活用できる新機能のいくつかを挙げています。

1. JNDI

  • サーバー命名ノードはパーティションを認識します。
  • パーティションにデプロイされたアプリケーションには、対応するパーティションのJNDI名前空間で公開されるEJBクライアントビューがあります。

2. Security

  • セキュリティ実装は現在、パーティションごとのセキュリティレルムのサポートを含む、複数のアクティブなレルムを認めています。
  • ロールベースアクセス制御やパーティションにデプロイされたレルムアプリケーションのための資格証明マッピングは、パーティションが構成したレルムを使います。

3. Runtime Metrics and Monitoring

  • PartitionName属性を持つ新しいApplicationRuntimeMBeanインスタンスが、パーティションにデプロイされるアプリケーション毎に作成されます。
  • ランタイムMBeanサブツリーを公開するEJBコンテナは、ApplicationRuntimeMBeanインスタンスによって根づかせます。

4. EJB Timer service

  • 永続ローカルタイマーは、ストアコンポーネントに依存しています。パーティションカスタムファイルストアは必要なテナントデータの分離を提供します。
  • また、裏のクラスタ化されたタイマーはジョブスケジューラを使用しており、これも分離を提供しています。

5. JTA configuration at Partition Level

  • JTAタイムアウトは、ドメインレベルとEJBコンポーネントレベルに加えて、パーティション・レベルで設定することができます。
  • EJBコンポーネントレベルのタイムアウト値は、他の2つに優先します。
  • デプロイメントプランを使って動的更新をサポートします。

6. WebLogic Store

  • 永続ローカルタイマーはストアコンポーネントに依存しています。パーティション化されたカスタムファイルストアは必要なテナントデータの分離を提供します。 

7. Throttling Thread Resource usage

  • 制約のあるワークマネージャは、グローバル・ランタイム・レベルで定義することができ、パーティション内のアプリケーション・インスタンスは、特に対話しないバッチ処理、非同期、メッセージドリブンbeanの呼び出しなどのために、これらの共有ワークマネージャを参照し、スレッドの利用をパーティション全体で絞ることができます。

8. Data Sources for Java Persistence API users

  • リソースグループ・テンプレートのシステムリソースとして定義されるデータソースを使う永続性ユニットは、PartitionDataSourceInfoMBeanベースのオーバーライドを利用することができます。
  • 高度なカスタマイズを必要とするユースケースは、システムリソースの再構成のために追加された新たなデプロイメントプランのサポートを利用できます。
  • アプリケーションパッケージ化されたデータソースモジュールを使用する永続性ユニットは、現在のデプロイメントプランのサポートを利用して、異なるパーティションでコピーを持ち、適切なPDBに向けることができます。

A sample EJB application leveraging Multi-Tenancy

これらの機能の使用を説明するために、マルチテナント環境にEJBアプリケーションの簡単なセットアップを行っていきます。

EJBアプリケーションのアーカイブはsampleEJB.jarで、JPA APIでデータベースと対話するstateful session beanが含まれています。このアプリケーションを2個の独立したパーティションにデプロイし、両者がそれぞれ独自のデータベース・インスタンスを指して独立して動作できるようにしたいと考えています。

1.  Create Virtual Targets

まずは、2個のパーティションそれぞれに対し、2個の仮想ターゲットを作成します。仮想パーティションでは下図のように異なるURI接頭辞（/partition1と/partition2）を使います。


2.  Create Resource Group Template

myRGTというリソースグループ・テンプレートを作成しましょう。リソースグループ・テンプレートはWebLogic Server 12.2.1で新たに導入されたコンセプトで、必要なアプリケーションや様々なリソースをデプロイすることができるテンプレートです。アプリケーションのセットアップが複雑な場合、同じことを異なるパーティションで何度も繰り返したくないのでこのリソースグループ・テンプレートは非常に有用です。

3.  Deploy application and data source

下図のようにアプリケーションをデプロイし、データソースを定義できます。アプリケーションとデータソースはすべてmyRGTスコープで定義されていることに注意してください。


4.  Create Partitions

すべての準備が完了したので、パーティションを作成します。以下のイメージでは、先ほど作成したリソースグループ・テンプレートをパーティション作成時に適用することができます。指定することができることを示しています。テンプレートに従って、定義されたすべてのものを自動的にデプロイします。

5.  Access the EJB

パーティションの作成、起動がすんだので、以下のコードでEJBを検索、アクセスすることができます。partition1のURLを使っていますが、もちろんURLを変更して別のパーティションにもアクセスできます。
Hashtable<String, String> props = new Hashtable<String, String>();
  props.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
  props.put(Context.PROVIDER_URL, "t3://server1:7001/partition1");
  props.put(Context.SECURITY_PRINCIPAL, user);
  props.put(Context.SECURITY_CREDENTIALS, pass);
  Context ctx = new InitialContext(props);

  BeanIntf bean = (BeanIntf)ctx.lookup("MyEJB"); 
  boolean result = bean.doSomething();

6.  Override the data source

どこかまずいと感づいたのであれば、それは正しい感覚です。myRGTにデータソースmyDSを定義し、myRGTを両パーティションに適用したので、両パーティションは同じデータソースを共有しています。通常、これが起こることを望んでいません。2つのパーティションが相互に影響を与えることなく独立して動作してほしいのです。ではどうすれば可能でしょうか。
partition2を別のデータソースに切り替えたい場合、partition2の設定ページの［リソースのオーバーライド］タブでそのように設定すればよいのです。データベースのURLを変更して、別のデータベース・インスタンスをpartition2で使用するように変更することができます。

7.  Change the transaction timeout

前述の通り、EJBアプリケーションのために、動的に特定のパーティションのトランザクション・タイムアウト値を変更することがサポートされています。これは、パーティションの設定ページでも変更できます。以下の例では、15秒にタイムアウトを設定しています。これは、再起動せずに即座に有効です。

ワークマネージャを定義したり、特定のパーティションのリソース使用状況を監視したりと、パーティションの設定のページで、できることがその他にもあります。時間をかけると、このあたりで非常に便利なツールが見つかることでしょう。
- 0 件のコメント:
カテゴリ ,

[Java, WLS] Introducing WLS JMS Multi-tenancy

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/introducing_wls_jms_multi_tenancy

Introduction

Multi-tenancy (MT)はWebLogic Server 12.2.1の主要なテーマで、SaaSやPaaS用途のためにOracle Platformがこの機能により機能強化されています。WebLogic Server Multi-Tenancyの主要なメリットは、集積度の向上、テナントの分離、クラウド構成や管理のシンプル化があげられます。

この記事では、WebLogic Serverのメッセージングコンポーネントである、WebLogic JMSのマルチテナントサポートのMulti-tenancyサポートについてご紹介します。

Key MT Concepts

例えばTimの以下のブログなどですでにWebLogic Server Multi Tenancyの主要なコンセプトはご存じかもしれませんが、幅広い皆様にとってのメリットをJMSの内容に入る前にさらっとご紹介します。
Domain Partitions for Multi-tenancy in WebLogic Server 12.2.1
https://blogs.oracle.com/WebLogicServer/entry/domain_partitions_for_multi_tenancy
http://orablogs-jp.blogspot.jp/2015/11/domain-partitions-for-multi-tenancy-in.html
WebLogic Multi-tenancyでは、ドメイン・パーティション（もしくはパーティション）、リソースグループ（RG）、リソースグループ・テンプレート（RGT）というコンセプトが導入されています。
パーティションは、概念としてWebLogic Serverのドメインをスライスしたもので、様々なテナントのリソースやアプリケーションを同一WebLogic Serverや同一クラスタで分離しながら構成、デプロイできます。これにより、全体としての集積度が向上します。パーティションはJNDI、セキュリティ、ランタイムMBean、アプリケーション永続データ、ワークマネージャ、ログの分離境界を定義します。さらに、同一サーバインスタンスで動作するパーティションには各々のライフサイクルがあります。例えば、パーティションを任意のタイミングで停止しても他のパーティションに影響を与えることはありません。
リソースグループは、リソースやアプリケーションに関連するシンプルな機能の集合体です。リソースグループは、同一パーティション内の他のリソース・グループとは独立してターゲットに指定したり、管理したりすることができます。リソースグループをパーティション内部で定義するだけでなく、ドメインレベルでも定義することができます。パーティションと同じように、同一サーバ上で動作する同一パーティションもしくはドメインレベルのリソースグループには、独自のライフサイクルがあります。
リソースグループ・テンプレートは、例えば同じリソースやアプリケーションが複数のパーティションで実行される必要がある、SaaSのような利用形態におけるWebLogic Serverリソースやアプリケーション構成に関わる管理のオーバーヘッドを削減するテンプレートのしくみを提供します。リソースグループ・テンプレートは、configure-once-and-use-everywhere（1回の構成でどこででも利用できる）機能を提供します。構成アーティファクトの共通セットをRGTで指定することができ、異なるパーティションのリソースグループから参照することができます。リソースグループ・テンプレートは、ターゲット指定できません。そして、デプロイ済みのリソースグループが参照しなければリソースグループ・テンプレートのリソースはデプロイされません。
（直接リソースグループ内で、もしくは直接リソースグループ・テンプレートを参照するリソースグループを通じて）パーティション内で構成、デプロイされているリソースやアプリケーションは、当該パーティションに範囲が限定されることにご注意ください。

Understanding JMS Resources in MT

他のWebLogic構成アーティファクトと同様に、JMSサーバ、SAFエージェント、パスサービス、永続ストア、メッセージングブリッジ、JMSシステムモジュール、アプリケーション・デプロイメントJMSモジュール、Java EE 7リソース定義モジュール、およびJMSアプリケーションといったJMSリソースは、直接またはリソースグループ・テンプレートを通じてだけではなく、以前からの方法（常にドメインレベルでは直接設定です）であっても、すべてリソースグループで構成、デプロイできます。パーティション構成と昔ながらの設定を同一ドメインで組み合わせて使うことも可能です。
異なるパーティション内のリソースやアプリケーションは互いに分離されています。例えば、同じクラスタ内で実行されている複数のパーティションに同じJNDI名を持つJMS宛先を設定することができ、これらの宛先を、独立したランタイムMBeanインスタンスを使って管理し、独立したパーティション固有のセキュリティレルムを使って保護することができます。非永続的な状態に加えて、JMS宛先などの永続的なデータ（例えば、永続メッセージと永続サブスクリプション）も互いに分離されています。

Configuring JMS Resources in MT

以下の構成スニペットでは、マルチテナント環境で構成されたJMSリソースと旧来の非マルチテナント環境におけるJMS構成の違いを示しています。

ご覧になるとおわかりになる通り、パーティションスコープのJMSリソースはパーティションのリソースグループに埋め込まれています（代わりにリソースグループ・テンプレートに埋め込むこともできます。その場合、リソースグループがそれを参照します）。
さらに、リソースグループのリソースは決して個別にターゲットとして指定されず、リソースグループ全体を仮想ターゲットを介してターゲットとして指定します。これが通常のターゲット指定の方法です。リソースグループが仮想ターゲットに対して割り付けられると、WebLogic Serverのクラスタにも割り付けられます。リソースグループのすべてのJMSリソースやアプリケーションもクラスタに割り付けられます。

後でご覧に入れますが、仮想ターゲットはだけでなく、リソースグループのターゲット情報を提供するだけではなく、パーティションのアクセス・ポイントをも定義します。リソースグループの割り付けと仮想ターゲットに関する詳細は、以下のJoeのエントリをご覧ください。
Partition Targeting and Virtual Targets in WebLogic Server 12.2.1
https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
http://orablogs-jp.blogspot.jp/2015/11/partition-targeting-and-virtual-targets.html
WebLogicクラスタ内の各サーバに対する個別のJMSリソース設定について説明せず、「移行可能なターゲット」を構成して高可用性を担保することに言及しなかったことに気付いてらっしゃるかもしれませんが、いいお知らせがあります。どちらも必要なく、MTでサポートされていません。これらの機能は、大幅に強化されたWebLogic JMSのクラスタ・ターゲティングおよびHAサポートに置き換えられています。同郷のKathiravanがこの件に関するエントリを出しています。
12.2.1 WebLogic JMS: Dynamic Scalability and High Availability Made Simple
https://blogs.oracle.com/WebLogicServer/entry/12_2_1_weblogic_jms
http://orablogs-jp.blogspot.jp/2015/12/1221-weblogic-jms-dynamic-scalability.html
システムレベルのJMSリソース（JMSサーバ、SAFエージェント、永続ストア、メッセージング・ブリッジ、パス・サービス、JMSモジュール）がマルチテナント構成で様々に範囲付けられていますが、それぞれの属性は旧来の非マルチテナント構成と全く同じやり方で指定します。
様々な検証およびターゲティングルールは、WebLogicマルチテナントのJMS構成が分離されていて自己完結しており、簡単に管理できることを保証するために強制されています。マルチテナント環境でJMSを構成する上でのある基本的かつハイレベルなルールは、JMS構成アーティファクトが同じスコープの他の構成アーティファクトを参照するのみである、というものです。例えば、JMSサーバーに範囲限定されたリソースグループは、同じリソース・グループで定義されている永続ストアを参照することだけができます。これらのルールは、構成の検証チェックによって実施され、エラーや警告は実行時にログに記載されます。

Accessing JMS Resources in MT

マルチテナント用に設計されたJMSアプリケーションは、JNDI名前空間でJMSリソースを検索することにより、旧来のJMSアプリケーションと同じ方法でJMSリソースにアクセスします。違いは、MTの環境では、WebLogic JNDI InitialContextが作成時に特定のスコープ（ドメインまたはパーティション）に関連付けられていることです。
マルチテナントのアプリケーションは、同じWebLogicクラスタを参照しても異なるパーティションにスコープ限定されている、複数のJNDIコンテキストを持つことができます。初期コンテキストは、一度作成されるとクローズするまでそのスコープ範囲に限定されます。これは、パーティションスコープのJNDIコンテキスト・インスタンスを使うすべてのJNDIの操作を、パーティション固有のJNDI空間の領域を使用してを使用して、すべてのJNDI操作は、JNDIスペースのパーティション固有の領域を使用して実行することを意味します。
JNDIコンテキストのスコープは、初期コンテキスト作成時に提供されるプロバイダURLによって決定されます。
アプリケーションがパーティションスコープのJNDI初期コンテキストを確立すると、このコンテキストを使ってJMS接続ファクトリや宛先を非マルチテナント環境と同じやり方で検索することができます。違うのは、アプリケーションがパーティションスコープのJMSリソースにのみアクセスできる、という点です。
では具体的なユースケースを通じて、アプリケーションがどのように特定パーティションへの初期コンテキストを確立できるのかを見ていきましょう。

Use Case 1 - Local Intra-partition Access

Java EEアプリケーションが同一クラスタ（または同じクラスタ構成ではない管理対象サーバ）のローカルパーティションのJMS宛先にアクセスする必要がある場合は、アプリケーションはプロバイダURLを使わずに初期コンテキストを作成すればよいです。
Example 1: Null Provider URL 
  Context ctx = new InitialContext();
  Object cf  = ctx.lookup("jms/mycf1");
  Object dest = ctx.lookup("jms/myqueue1");
この初期コンテキストはアプリケーションがデプロイされたパーティションに範囲が限定されます。

Use Case 2 - Local Inter-partition Access

Java EEアプリケーションが、自分のデプロイされているパーティション以外に存在するJMS宛先やその他のリソースにアクセスする必要があって、パーティションが同じクラスタにある、もしくは同一管理対象サーバにある場合、パーティションスコープのJNDI名もしくは"local:"プロトコルを使うプロバイダURLを使うことができます。

Using Partition Scoped JNDI Names
JNDI名を名前空間の接頭辞で装飾し、スコープを示すことができます。

 Example 2.1: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
Context ctx = new InitialContext();
Object cf  = ctx.lookup("partition:partition1/jms/mycf1");
Object dest = ctx.lookup("partition:partition1/jms/myqueue1");
同様にパーティションのJava EEアプリケーションは、同一クラスタ内のドメインレベルのJNDIリソースに"domain:"という名前空間の接頭辞を付けると、パーティションスコープの初期コンテキストを使ってアクセスすることができます（例： "domain:jms/mycf2"）。

Using a provider URL with the "local:" Protocol
特定パーティションへの初期コンテキスト作成時に"local:"プロバイダURLを指定することもできます。

Example 2.2: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
Hashtable<String, String> env = new Hashtable<>();
env.put(Context.PROVIDER_URL, "local://?partitionName=partition1");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
Context ctx = new InitialContext(env);
Object cf = ctx.lookup("jms/mycf1");
Object dest = ctx.lookup("jms/myqueue1");
初期コンテキストはそのライフタイムが"partition1"と関連付けられています。
同様に、パーティション内のJava EEアプリケーションは、同一クラスタ内のドメインレベルのJNDIリソースに local://?partitionName=DOMAIN をプロバイダURLとして指定するとアクセスできます。

Use Case 3 - General Partition Access

Java EEアプリケーションやクライアントがパーティションのJMS宛先にアクセスする三個目の方法は、パーティションURLを使う、というものです。JMS宛先がリモートクラスタ（もしくは非クラスタ環境のリモートの管理対象サーバ）にある場合に、パーティションURLを使うことを意図しています。通常パーティションURLはt3://hostnake:portもしくはt3://hos:port/{URI接頭辞}です。
パーティションURLは、WebLogic Server 12.2.1以後を使うJava EEアプリケーションやクライアントのみが使うことができます。旧バージョンの場合、下記のように専用パーティションポートを使います。

 Example 3: 上の例で示されたパーティション構成の場合、以下のコードを使ってpartition1にて構成されたJMS宛先にアクセスすることができます。
注意いただきたいのは、以下のプロバイダURLにある"/partition1"はpartition1の仮想ターゲットで設定されたURI接頭辞です。
Hashtable<String, String> env = new Hashtable<>();
env.put(Context.PROVIDER_URL, "t3://abcdef00:7001/partition1");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");
Context ctx = new InitialContext(env);
Object cf = ctx.lookup("jms/mycf1");
Object dest = ctx.lookup("jms/myqueue1");
ベストプラクティスではありませんが、パーティションURLを使って同一JVM/クラスタの別のパーティションにアクセスすることもできます。

Use Case 4 – Dedicated Partition Ports

最後の方法は、専用ポートを各パーティションに設定することです。これらの構成はJoeの以下のエントリに説明があります。
Partition Targeting and Virtual Targets in WebLogic Server 12.2.1
https://blogs.oracle.com/dipol/entry/partition_targeting_and_virtual_targets
http://orablogs-jp.blogspot.jp/2015/11/partition-targeting-and-virtual-targets.html
パーティション専用ポートを構成すると、旧来のURLを使うアプリケーションがパーティションにアクセスすることができます。このポートは、12.2.1以前のWebLogic Serverで動作するクライアントやアプリケーションが12.2.1以後のドメイン内のパーティションにアクセスできるようにすることを主目的としています。
このような古いクライアントやアプリケーションの場合、ホスト名とURI接頭辞を使ってパーティションにアクセスすることはサポートしていませんので、旧来のクライアントからこれらを使おうとする試みは単に失敗するか、無言のうちにドメインレベルのJNDI名前空間にアクセスするかのどちらかでしょう。

What’s next?


この記事がマルチテナントにおけるJMSの基本を理解する上での助けになることを願っています。この新しい面白い機能の探索は始まったばかりです。マルチテナントにおけるメッセージングに関する情報は以下のドキュメントでたくさん見つけることができます。
Oracle® Fusion Middleware Using WebLogic Server Multitenant 12c (12.2.1)
Configuring Messaging
http://docs.oracle.com/middleware/1221/wls/WLSMT/config_jms.htm#WLSMT617
- 0 件のコメント:
カテゴリ ,

[misc] Upper Stackを使う際に役立つかもしれないJDeveloperの設定やTips

この記事は JPOUG Advent Calendar 2015 の22日目のエントリです。昨日はYousuke Yadaさんのエントリでした。
任意の待機イベントを擬似的に発生させる方法
http://blog.livedoor.jp/y_db_y/archives/46343044.html
今回は、備忘録的なものですが、Upper StackであるSOA Suite、BPM Suiteの開発をする上で設定しておいたほうがいいJDeveloperの設定をご紹介します。
その前に、11gまでは、SOA/BPMの開発では素のJDevelooerをインストールし、Upper Stackに必要なExtensionをインポートする構成でしたが、12c以後では、SOA用のJDeveloper、BPM用のJDeveloperがそれぞれQuick Start Installerとして用意されたものを使うように変わっています。
BPMのQuick Start Installerに含まれるJDeveloperを使うと、SOAの開発も可能です。包含関係は以下のような感じです。なお、SOA Quick Startを使うと、OEP、OSBの開発もできます（11gまでは両者の開発はJDeveloperではなくOracle Enterprise Pack Eclipseを使っていましたが、12cからはできなくなっています）。

JDeveloperで利用するヒープサイズを変更する

デフォルトでは最小128MB、最大640MBですが、もっとメモリを割り当てたい、という場合には以下のように設定します。

［場所］
<JDEV_HOME>/jdeveloper/ide/bin/ide.conf
［設定］
AddVMOption -Xms、-Xmx部分を変更。以下は例。
AddVMOption  -Xms128M
AddVMOption  -Xmx2048M

JDeveloperで利用するPermanent領域のサイズを変更する（JDK 7まで）

ADF、JSFでUIを作成しているときに、「メモリが不足しています…」という忌まわしいメッセージが出ることがあります。これはADFやJSFでの開発をする方はご存知かもしれませんが、JDeveloperでページのイメージを生成する際にPermanent領域を使っているからです。Permanent領域を増やすには、以下の設定を施します。BPMのヒューマンタスク用フォームを作成する場合、2GBほどを割り当ててください。

［場所］
<JDEV_HOME>/jdeveloper/jdev/bin/jdev.conf
［設定］
AddVMOptionHotspot部分を変更。以下は例。
AddVMOptionHotspot  -XX:MaxPermSize=2048M

保存時にプロジェクトを生成しないようにする

12cR1以後、「プロジェクトを保存後に作成」という保存アクションがデフォルトで有効になっています。
これは12cR2でも同様ですので、保存後動作が固まる（ようにみえる）のを避けるには、プリファレンス＞コード・エディタ＞保存アクションで、設定を削除する必要があります。

JDeveloperのユーザーディレクトリを変更する

JDeveloperは、デフォルトで
%APPDATA%\JDeveloper (Windows)
$HOME/.jdeveloper (Linux, Mac OS X)
をユーザーディレクトリとして利用しますが、複数のバージョンが混在する場合であれば、ユーザーディレクトリをわける必要があります。
ドキュメントにあるように、環境変数JDEV_USER_DIRを作成し、<JDEV_HOME>/jdeveloper/jdev/bin/jdev.bootに
ide.user.dir.var = JDEV_USER_HOME,JDEV_USER_DIR
と指定します。複数の環境があるならば、この環境変数をShellもしくはcmd/batファイルで定義し、そのファイルからJDeveloperを起動する、ようにしておくと、異なるバージョン、リリースのJDeveloperが相互干渉せずにそれぞれ別のユーザーディレクトリを使うことができます。
例えば、こんな感じです（以下はWindowsの例）
@echo off
set PATH=C:\Oracle\MW\soa1213\soa\plugins\jdeveloper\integration\adapters\lib;%PATH%;
set JDEV_USER_DIR=C:\JDeveloper\soa1213
C:\oracle\MW\soa1213\jdeveloper\jdeveloper.exe

Javaクラスをさくっと発見したい

Upper Stackとはいえ、APIを使ったカスタム開発が必要になることがあります。例えばOSBのJava Calloutで呼び出したいクラスを作成したいんだけど、あのクラスはどのパッケージに存在するんだったかな、という場合です。ほとんどの場合、IDEがよろしくやってくれますが、[ctrl]と[-]を押すと、検索窓が出ます。例えば、以下ではMapMessageと入れてみました。javax.jmsに含まれるクラスだということがわかります。

そして、ここでお目当てのクラスをクリックすると、このクラスが持つメンバを確認することができます。

JDeveloperのロケールを英語に強制する

JDeveloperは、日本語、英語のみ対応していますが、JDeveloperで発生した例外再現手順をサポートチームへ伝える場合、英語版で説明したほうが解決が速い場合があります。英語環境にするには、以下のように設定します。

［場所］
<JDEV_HOME>/jdeveloper/jdev/bin/jdev.conf
［設定］ 
AddVMOption -Duser.language=en
AddVMOption -Duser.country=US
色々JDeveloperには隠れた機能がありますので、ご興味のある方はぜひ探してみてください。明日はTakahiro Kitayamaさんです。よい休日をお過ごしください。

- 0 件のコメント:
カテゴリ

[WLS] ZDT Patching; A Simple Case – Rolling Restart

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/zdt_patching_a_simple_case
ZDT（Zero Down Time）パッチ適用を理解するために、その最も単純な形であるローリング・リスタートを見てみましょう。この単純なユースケースは、Javaのバージョン、Oracleのパッチ、アプリケーションの更新といった類のロールアウトの基礎です。エンドユーザに対するサービスを停止させず、セッションデータを失わない状態を保証しながら、ローリング・リスタートを実行するには、ドメインやクラスタ内のすべての管理対象サーバの協調とコントロールされたシャットダウンが必要です。

管理者はローリング・リスタートを以下のWLSTコマンドを発行して開始することができます。
rollingRestart("Cluster1")
今回の場合、ローリング・リスタートは、「Cluster1」という名前のクラスタ内のすべての管理対象のサーバーに影響します。これはターゲットと呼ばれています。ターゲットは、単一のクラスタ、クラスタのリスト、またはドメイン名を取り得ます。

コマンドを入力すると、WebLogic管理サーバーがターゲットのトポロジーを分析し、動的にワークフローを作成します（ロールアウトとも呼ばれます）。これは、管理対象サーバ上のすべてのセッションが他の管理対象サーバで利用できるようにしながら、正常にシャットダウンし、クラスタ内の各管理対象サーバを再起動するためにとられるべき各ステップからなります。このワークフローは、次のノードに移動する前に、管理対象サーバ上で実行中のすべてのアプリケーションがエンドユーザからのリクエストを受け入れる準備が完全に整ったことも保証します。完全に一度クラスタ内のすべての管理対象サーバが再起動された場合には、ローリング・リスタートが完了しています。

以下は非常にシンプルなトポロジーでのこのプロセスを説明する図ですが、この図を見ると、ノードがオフライン（赤くなっている）になって、そのノードへ届くはずだったエンドユーザのリクエストが別のアクティブなノードへ再ルーティングされていることがわかります。オフラインノードのサーバが再起動され、アプリケーションが再度リクエストを受け入れる準備が整えば、このノードがアクティブなノードのプールに追加され、ローリング・リスタートは別のノードに移ります。
Animated image illustrating a rolling restart
クラスタでのローリング・リスタート
ローリング・リスタートの機能はお客様からのフィードバックをもとに導入されました。管理対象サーバで動作するアプリケーションのメモリ使用量をリフレッシュすることを目的として、先回りして管理対象サーバを再起動する、というポリシーをお持ちのお客様がいらっしゃいます。この機能を使用して、エンドユーザーに影響を与えずに、手間と時間のかかるプロセスを非常に簡素化しています。

Zero Downtime Patchingを使ったローリング・リスタートに関する詳細情報は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Initiating a Rolling Restart of Servers
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT170
- 0 件のコメント:
カテゴリ

[WLS] Local Transaction Leak Profiling for WLS 12.2.1 Datasource

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/local_transaction_leak_profiling_for
これは、WebLogic Server 12.2.1のプロファイリングの機能強化に関する一連のエントリの三個目です。
これは、アプリケーションがローカルトランザクションを開いたままにして接続プールに戻された場合によくあるアプリケーションエラーで、診断が困難なものです。このエラーは、XAException/XAER_PROTO、またはデータベースのアップデートの意図せぬローカルトランザクションのコミットやロールバックとして現れることがあります。接続がリリースされた場合のローカルトランザクションの内部のコミット、ロールバックに対する現在の回避策は、アプリケーションに現れるエラーをマスクするだけでしかなく、まだデータの矛盾の可能性が残っています。
Oracle JDBC thin driverはローカルトランザクションの接続の状態を取得する独自の方法をサポートしていますが、接続プールにリリースされた時に接続でローカルトランザクションを検知した場合にログエントリを追加する、新しいプロファイリングオプションが追加されています。ログレコードにはコールスタックと接続をリリースしたスレッドに関する詳細情報が含まれています。

ローカルトランザクションのリークプロファイリングを有効化するためには、データソース接続プールのProfileType 属性のビットマスクに0x000200 という値を含める必要があります。

以下は値を設定するためのWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileType(0x000200) # turn on  transaction leak profiling
save()
activate()
exit()
プロファイルタイプを設定する場合、複数のプロファイルオプションを一緒に組み合わせることができます。

管理コンソールでは診断タブで、接続ローカル・トランザクション・リークのプロファイル（Profile Connection Local Transaction Leak）のチェックボックスを使って有効化できます。

ローカルトランザクション・リークプロファイルのレコードには2個のスタックトレースが含まれています。一つは予約しているスレッドからのもの、もう一つは接続がクローズされたときのスレッドによるものです。ログレコードの例を以下に示します。
####<mydatasource> <WEBLOGIC.JDBC.CONN.LOCALTX_LEAK> <Thu Apr 09 15:30:11 EDT 2015> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:398)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:365)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:331)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:568)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:498)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:135)
at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiDataSource.java:522)
at weblogic.jdbc.common.internal.RmiDataSource.getConnectionInternal(RmiDataSource.java:615)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:566)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:559)
...
> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionPool.release(ConnectionPool.java:1064)
at weblogic.jdbc.common.internal.ConnectionPoolManager.release(ConnectionPoolManager.java:189)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:249)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:157)
...
> <[partition-id: 0] [partition-name: DOMAIN] >
レコードを見ると、アプリケーションのどこでクローズが実施されたのかを確認できますので、クローズする前に適切にトランザクションを完了させてください。
- 0 件のコメント:
カテゴリ

[WLS] Closed JDBC Object Profiling for WLS 12.2.1 Datasource

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/closed_jdbc_object_profiling_for
クローズ済みのJDBCオブジェクトへのアクセスはよくあるアプリケーションエラーで、デバッグが難しいものです。そのような条件を診断するのに役立つ、新たなプロファイリングオプションがあります。これはclose()メソッドを呼び出してからConnection、Statement、ResultSetなどのJDBCオブジェクトにアクセスした場合に診断ログメッセージを生成します。

クローズ済みJDBCオブジェクトプロファイリングを有効化するには、データソースのProfileType属性のビットマスクは0x000400が設定されている必要があります。

以下は値を設定するためのWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileType(0x000400) # turn on profiling
save()
activate()
exit()
管理コンソールでは、診断タブの［クローズされた使用のプロファイル］のチェックボックスをONにする必要があります。

このクローズされた使用のログレコードには、2個のスタックトレースが含まれています。クローズ済みの利用ログレコードには次の2つのスタックトレースが含まれています。一つは最初にオブジェクトを閉じたスレッドのもの、もう一つは閉じたオブジェクトにアクセスしようとしたスレッドのものです。レコードの例を以下に示します。
####<mydatasource> <WEBLOGIC.JDBC.CLOSED_USAGE> <Thu Apr 09 15:19:04 EDT 2015> <java.lang.Throwable: Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]
at weblogic.jdbc.common.internal.ProfileClosedUsage.saveWhereClosed(ProfileClosedUsage.java:31)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:242)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:157)
...
> <java.lang.Throwable: Thread[[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]
at weblogic.jdbc.common.internal.ProfileClosedUsage.addClosedUsageProfilingRecord(ProfileClosedUsage.java:38)
at weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:83)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:106)
at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:581)
...
> <[partition-id: 0] [partition-name: DOMAIN] >
このプロファイルオプションを有効にすると、オブジェクトがすでにクローズされていることを示す例外に、どこでクローズが発行されたのかを示すネストされたSQLExceptionが含まれています。以下がその例です。
java.sql.SQLException: Connection has already been closed.
at weblogic.jdbc.wrapper.PoolConnection.checkConnection(PoolConnection.java:82)
at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:107)
at weblogic.jdbc.wrapper.Connection.createStatement(Connection.java:582)
at Application.doit(Application.java:156)
...
Caused by: java.sql.SQLException: Where closed: Thread[[ACTIVE] ExecuteThread: ...
at weblogic.jdbc.common.internal.ProfileClosedUsage.saveWhereClosed(ProfileClosedUsage.java:32)
at weblogic.jdbc.wrapper.PoolConnection.doClose(PoolConnection.java:239)
at weblogic.jdbc.wrapper.PoolConnection.close(PoolConnection.java:154)
at Application.doit(Application.java:154)
... 
接続がすでにクローズされたことを示すエラーが出てどこでそれが起こったのかわからないときに、この機能は非常に有用です。スタックトレースを出力するためのオーバーヘッドがあるため、通常は本番環境でこのオプションを有効にしたままにしないでおきましょう（そのためデフォルトで有効にはなっていません）。とはいえ、問題を解決が必要であれば、このオーバーヘッドには価値があります。
- 0 件のコメント:
カテゴリ ,

[WLS] Connection Leak Profiling for WLS 12.2.1 Datasource

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/connection_leak_profiling_for_wls
これはWebLogic Server 12.2.1におけるデータソース・プロファイリングの機能向上に関する3部作の一個目のエントリです。これらの機能向上はお客様ならびにOracle Supportからの要求でした。この機能はアプリケーションで問題を見つけ出す上で非常に役に立つと思います。

12.2.1までの接続リーク診断プロファイリングオプションでは、アイドルの予約済み接続がリークしていると判断するまでの時間として、接続プールの「非アクティブ接続タイムアウト」属性を正数（0では無効になります）に設定する必要があります。リークしていると判断した場合、接続が再利用され、予約スレッドに関する情報を診断ログに書き出します。長時間接続を保持するアプリケーションでは、後検出によりデバッグが複雑なアプリケーションエラーが発生する場合があります。この問題に対処し、使い勝手を向上させるために、接続リークプロファイリングの2つの機能拡張が使えるようになりました。
  1. 接続プールが最大容量に到達し、確保要求がPoolLimitSQLExceptionエラーになった場合に、すべての予約済み接続に対して接続リークプロファイルレコードを作成します。
  2. 接続がいつリークしていると判断するかを決定する際に利用するため、データソースディスクリプタにオプションのConnection Leak Timeout Seconds（接続リークタイムアウト）という属性を追加します。アイドル接続がタイムアウト値を上回った場合、リークプロファイルログメッセージを書き込み、接続をそのままにしておきます。
データソース接続プールのProfileType属性ビットマスクに既存の接続リークプロファイリングの値（0x000004） を設定しなければなりません。潜在的な接続リークを識別するためのInactiveConnectionTimeoutSecondsの代わりに、ProfileConnectionLeakTimeoutSeconds 属性を設定することでも代用できます。
以下は値を設定するWLSTスクリプトの例です。
# java weblogic.WLST prof.py
import sys, socket, os
hostname = socket.gethostname()
datasource='ds'
svr='myserver'
connect("weblogic","welcome1","t3://"+hostname+":7001")
# Edit the configuration to set the leak timeout
edit()
startEdit()
cd('/JDBCSystemResources/' + datasource + '/JDBCResource/' + datasource +
'/JDBCConnectionPoolParams/' + datasource )
cmo.setProfileConnectionLeakTimeoutSeconds(120) # set the connection leak timeout
cmo.setProfileType(0x000004) # turn on profiling
save()
activate()
exit()
これは値設定後のコンソールページの様子です。プロファイルタイプとタイムアウト値がデータソースの診断タブに設定されていることに着目してください。

ProfileConnectionLeakTimeoutSeconds属性もしくはプールの容量を超えた場合のいずれかがトリガーになっているリーク用に、既存のリーク検出診断プロファイリングログレコード形式を使います。いずれの場合も、各予約接続に対して一回だけログレコードを生成します。その後接続をプールに解放し、再度予約して再びリークする場合、新たなレコードが生成されます。リソースリーク診断ログレコードの例を以下に示します。コンソールやデータソースプロファイル出力テキストファイルから出力を確認することができます。
####<mydatasource> <WEBLOGIC.JDBC.CONN.LEAK> <Thu Apr 09 14:00:22 EDT 2015> <java.lang.Exception
at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:398)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:365)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:331)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:568)
at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:498)
at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:135)
at weblogic.jdbc.common.internal.RmiDataSource.getPoolConnection(RmiDataSource.java:522)
at weblogic.jdbc.common.internal.RmiDataSource.getConnectionInternal(RmiDataSource.java:615)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:566)
at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:559)
...
> <autoCommit=true,enabled=true,isXA=false,isJTS=false,vendorID=100,connUsed=false,doInit=false,'null',destroyed=false,poolname=mydatasource,appname=null,moduleName=null,
connectTime=960,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=false,lastSuccessfulConnectionUse=1428602415037,secondsToTrustAnIdlePoolConnection=10,
currentUser=...,currentThread=Thread[[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={},
supportIsValid=true> <[partition-id: 0] [partition-name: DOMAIN] >
接続のリークがあって、しかも有効な長時間実行する操作を有する可能性のあるアプリケーションでは、通常のアプリケーション実行に干渉せず、問題がある可能性のある接続のリストに目を通すことができます。
- 0 件のコメント:
カテゴリ
登録: 投稿 (Atom)