2013年weblogic server勉強会の総まとめ

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. 1

2013年WebLogic Server勉強会総まとめ

2014年1月22日日本オラクル株式会社


以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。


WebLogic Server基本編


WebLogic Server基本編

開催日セッション資料

1月24日「起動・停止スクリプトを極める」 http://www.slideshare.net/OracleMiddleJP/ss-16168237

5月23日「WebLogic Server の開発モードと本番モード」 http://www.slideshare.net/OracleMiddleJP/weblogic-server-

22423176

6月20日「WebLogic Server デプロイメントエッセンシャルズ」

http://www.slideshare.net/OracleMiddleJP/20130620-

wlstudy-deployhandsout

8月21日「Java EE アプリケーションをWebLogic Serverで動かしてみよう」


wlstudy-jeeapphandsout

http://www.slideshare.net/OracleMiddleJP/ss-16168237




http://www.slideshare.net/OracleMiddleJP/weblogic-server-22423176






http://www.slideshare.net/OracleMiddleJP/20130620-wlstudy-deployhandsout






http://www.slideshare.net/OracleMiddleJP/20130821-wlstudy-jeeapphandsout







目標：WebLogic Serverを使って見る。

テーマチャレンジ項目

インストールインストーラが12.1.2でOUIに変更。ドメインとは、管理サーバ、管理対象サーバ

開発モードと本番モード開発モードと本番モードの違い、開発モードでのみ使用できる機能、開発モードと本番モードの切り替え

管理サーバと管理対象サーバの起動と終了起動/停止スクリプトの構造、利用する可能性が高い環境変数

アプリケーションのデプロイデプロイメントとは、2段階（インストール、アクティベーション）、コンソールデプロイメント、コマンドラインデプロイメント、自動デプロイメント、ステージングモード、デプロイメントプラン、プロダクション再デプロイメント、FastSwap


WebLogic Server のインストール WLS12.1.2からインストーラがOUIに

TIPS: インストーラの起動

$ java –d64 –jar wls_121200.jar

TIPS: インベントリ・ディレクトリが存在しない場合はインベントリ・ディレクトリを指定


ドメインディレクトリ構成

ディレクトリ説明

1 domain ドメインディレクトリ (ディレクトリ名=ドメイン名)

0 autodeploy 自動デプロイメントディレクトリ(開発モード用)

0 bin 起動・停止スクリプト etc

管理サーバ: startWebLogic.sh / stopWebLogic.sh

管理対象サーバ: startManagedWebLogic.sh / stopManagedWebLogic.sh

0 config コンフィグレーションディレクトリ

config.xmlが配置される

0 init-info ドメインの初期化情報

0 nodemanager ノードマネージャ・ホームディレクトリ (WLS12.1.2 ～)

0 pending ペンディングコンフィグレーションストア

(編集中のコンフィグレーションの保存先)

0 security セキュリティファイル (ldift, SerializedSystemIni.dat)

1 servers サーバローカルディレクトリ

servers配下にサーバごとにディレクトリが作成される 0 server_name


起動スクリプトと停止スクリプト 1月24日「起動・停止スクリプトを極める」資料引用


カスタマイズ対象の環境変数 1月24日「起動・停止スクリプトを極める」資料引用


管理対象サーバーのマシン管理サーバーのマシン

ステージングとは？デプロイ対象のサーバーにアプリケーションを配布すること

webApp.war

<source_dir>

webApp.war

<server_dir>

stage

upload

webApp.war

servers

<domain>

<server_dir>

stage

<app-name>

webApp.war

servers

<server_root>

管理対象サーバー

webApp.war

アップロードステージング

ロード

アクティブ化

アプリケーション・ファイルは管理サーバの任意のディレクトリに配置可能。

ファイルは必要に応じてアップロード可能。(コンソール/

コマンドライン)

管理サーバからステージされるファイルは各サーバーのステージングディレクトリに配置される


コマンドラインデプロイメント

準備完了

アクティブ

①

② ③

④

⑥ ⑤

WLST weblogic.Deployer

① distributeApplication() -distribute

② startApplication() -start

③ stopApplication() -stop

④ undeploy() -undeploy

⑤ deploy() -deploy

⑥ undeploy() -undeploy

⑦ redeploy() -redeploy

⑦

コマンドラインデプロイメントはWLST、またはweblogic.Deployerで実行可能 * コマンドは管理サーバに対して実行デプロイなし

管理モード起動時は管理ポートを有効化する必要がある

(主にプロダクション再デプロイメント用)

管理

③ ②

② ③


プロダクション再デプロイメント

WebLogic Serverではアプリケーションをバージョニング可能

– 保持できるバージョンは2つまで

プロダクション再デプロイメントでは新しいバージョンと古いバージョンを並行してデプロイする

– 既存のクライアント・リクエストは古いバージョンへ

– 新しいクライアント・リクエストは新しいバージョンへ

バージョニングによる再デプロイメント

プロダクション再デプロイメントを使用するとサービスを中断しないアプリケーション更新をサーバ単体で実現可能


プロダクション再デプロイメント

WebLogic Server

古い

アプリケーション

WebApp (v1)

新しい


WebApp (v2)

既存の

ユーザ・リクエスト

新しい

ユーザ・リクエスト

新バージョンデプロイ後は

リタイア中に

デプロイ後は新バージョンが

アクティブに

アクセスするバージョンはWebLgoic Serverが管理

NOTE: すべてのセッションがタイムアウト or 指定したタイムアウト時間経過でアプリケーションはリタイアする


WebLogic Server データベース接続


WebLogic Serverデータベース接続


2月20日「WebLogic Serverとデータベース接続の基礎から応用」

http://www.slideshare.net/OracleMiddleJP/weblogic-server-

16684776

4月25日「Active GridLink for RAC 入門」 http://www.slideshare.net/OracleMiddleJP/20130425-

wlstudy-agl4rachandsout







http://www.slideshare.net/OracleMiddleJP/20130425-wlstudy-agl4rachandsout







目標：データソース設定を適切に


データソース設定パラメータそれぞれの意味を理解し環境に合わせた設定ができること。

障害時対応障害時のリカバリを学ぶ。動作内容、振る舞いを理解する。

GridLinkデータソース特長と動作内容を理解する。


データソースを使ったデータベースアクセスアプリケーションは接続情報を意識しない

WebLogic Server

データソース

接続プール

JNDI デプロイ時にバインド

RDBMS

デプロイ時に

初期容量まで接続

JNDIルックアップ

(論理名で検索)

@Resource(name = "jdbc/test") DataSource ds; try (Connection conn = ds.getConnection(); PreparedStatement pstmt = conn.prepareStatement(QUERY)) { pstmt.setString(1, "xxx"); ResultSet rs = pstmt.executeQuery(); while(rs.next()) { // .... } } catch (SQLException e) { // 例外処理

}

開発者運用担当者

接続オブジェクト取得


データベースとの接続が失われた場合

データベースとの接続が失われると接続オブジェクトは無効になる

– WebLogic Serverデータソースでは接続テストによって無効な接続をリフレッシュ可能

接続テストを行わないと無効な接続を保持し続ける

接続プール

RDBMS

@Resource(name = "jdbc/test") DataSource ds; try (Connection conn = ds.getConnection(); PreparedStatement pstmt = conn.prepareStatement(QUERY)) { pstmt.setString(1, "xxx"); ResultSet rs = pstmt.executeQuery(); while(rs.next()) { // .... } } catch (SQLException e) { // 例外処理

}

1. ds.getConnection()

2. SELECT 1 FROM dual

3. Connectionを返却

無効な接続を破棄して再作成


接続テストの振る舞い

データベース接続が失われた場合

– テストなし … 無効な接続が維持される

– テストあり … テストに2回失敗すると全接続を閉じる

全接続が閉じられたデータソースは無効化される(PoolDisabledSQLException)

– リフレッシュ・プロセスとして定期的なヘルス・チェックを実行(5秒間隔)

– データベースが回復すると接続を作成し、データソースを有効化する

テスト設定の有無でデータソース無効化のタイミングが異なる

DB接続の失敗を許容しない場合:

アイドル・プール接続を信頼する秒数=0, 予約時に接続をテスト=有効化

DB接続の失敗を許容できる場合:

アイドル・プール接続を信頼する秒数…大きく,テスト頻度>0 or 予約時に接続をテスト=有効化


GridLinkデータソースと汎用データソース

汎用データソース

– 接続先のRACインスタンスを意識していない

– 実行時ロードバランスはなく、RAC側の都合は意識できない。実行先RACインスタンスに偏りが出る可能性がある。

– RACサービス（インスタンス）の動的な停止、起動に対する物理接続の作成、終了タイミングが制御できない

GridLinkデータソース

– 接続先のインスタンスを意識できる(アプリケーションからは透過)

– FANイベントによりRAC側のステータスを把握でき、適切な実行時ロードバランスが可能

– RACサービス（インスタンス）の停止では迅速にそのインスタンスだけの接続を終了させ、起動時は自動的にそこへの物理作成を作成

RAC接続時の振る舞いの違い

RAC データソース

Connection

Connection

Connection

Connection

RAC

GridLink DS

Connection

Connection

Connection

Connection

RAC1

RAC1

RAC2

RAC2

FAN

RACステータスなし

RAC ステータス

通常のデータソース



ONS (Oracle Notification Service)

– RAC側の情報をFANイベントとして送信する仕組み

FAN (Fast Application Notification )

– RAC側の死活情報、負荷情報などを含んだ情報

UCP ( Universal Connection Pool)

– GridLinkデータソースがFANイベント情報を扱うために内部で利用

ロード・バランシング・アドバイザ

– RACのサービスレベルでの負荷状況をFANを通じてアプリケーションに提供

UCP-RAC モジュール

ONS Daemon

Web

Lo

gic

Serv

er

RA

C

死活・負荷状況通知

インスタンス1 GridLinkデータソース

（サービスA用）

インスタンス2

ON

S

clien

t

サービス

A ロード・バラ

ンシング・アドバイザ

ONS Daemon

FAN

GridLinkデータソースの仕組み WebLogic ServerデータソースにUCPの機能を統合


高速接続フェールオーバー (FCF)

UCPがサブスクライブしているRAC FANイベントをWebLogic Server の接続プールに通知

– RACノードの計画/計画外停止(DOWNイベント)

– RACノードの新規追加や復旧(UPイベント)

通知されたイベントをもとにWebLogic Server側で接続プールを制御

– 無効な接続を検知し即座に削除 … 障害インスタンスの接続だけ削除し、正常なインスタンスへの接続は維持

– ノードの追加や削除を検知し、アクティブなRACインスタンスに分配

障害時の早期エラー検出機能

GridLink DataSource

Instance2

RAC Database

Instance1

Instance3

Start ONS Subscribe

Handle Event ONS Publish X

X X

X

Universal Connection Pool (UCP)

FAN

WebLogic Server


実行時接続ロードバランシング (RCLB)

Oracle RACのロード・バランシング・アドバイザ

– RACインスタンスが自身のSQL実行統計を観測し、最適なリクエスト配分を算出

サービスタイムまたはスループットのどちらかを優先した方法でリクエスト配分を算出

リクエスト配分をFANイベントとして、ONS経由でGridLink内のUCPモジュールに送信


– 各インスタンスのリクエスト配分率にしたがってプールからどのインスタンスへの接続を取得するかを選択

クラスタの設定変更、アプリケーションのワークロード、過負荷/ハング状態のノードにも対応

負荷状況に応じた最適なリクエスト配分


Application

RAC Database

Instance1

Instance2

Instance3

ロード・バランシング・アドバイザ

リクエスト配分比率

inst1: 30%

inst2: 10%

inst3: 60%

リクエスト配分

比率情報

SQL実行統計

SQL実行統計

SQL実行統計

比率に応じた

コネクション

FAN

30%

10%

60%

WebLogic Server


最初のリクエストはRCLBによってインスタンスを選択

コンテキスト内に選択されたインスタンス情報が保存され同じHttpセッション内で有効

– セッション外のリクエストはXAアフィニティで処理

– アフィニティのON/OFFをRAC側が自動的に制御。アフィニティヒントとしてFANで通知

前回と同じインスタンス用のコネクション

Webセッション・アフィニティセッション処理を同じRACインスタンスで処理


Application

RAC Database

Instance1

Instance2

Instance3

ロード・バランシング・アドバイザアフィニティヒント

inst1: true

inst2: true

inst3: true

アフィニティ

有効フラグ

待機イベント統計



HTTPセッション

アフィニティ・コンテキスト

sessionXX : inst1

FAN

WebLogic Server


XAトランザクション・アフィニティ

最初のリクエストはRCLBによってインスタンスを選択

コンテキスト内にインスタンス情報が保存され同じXAトランザクション内で有効になる

– WebLogicのコンテキスト伝搬機能により他のサーバーでもコンテキスト情報が共有され同じRACインスタンスを選択

– アフィニティのON/OFFをRAC側が自動的に制御。アフィニティヒントとしてFANで通知。

XA処理を同じRACインスタンスで処理

GridLInkデータソース

TXClient 1

RAC Database

Instance1

Instance2

Instance3

XAトランザクション

コンテキスト伝搬

TXClient 2 前回と同じインスタンス用のコネクション

Txコンテキスト

XID xxx : inst1

WebLogic Server


WebLogic Scripting Tool (WLST)


WebLogic Scripting Tool


7月23日「使ってみよう WLST」 http://www.slideshare.net/OracleMiddleJP/20130723-

wlstudy-wlstpublish

7月23日「一歩先に進むためのWLST活用技法」 http://www.slideshare.net/OracleMiddleJP/wlstudy-

201307wlst

http://www.slideshare.net/OracleMiddleJP/20130723-wlstudy-wlstpublish






http://www.slideshare.net/OracleMiddleJP/wlstudy-201307wlst





目標：WLSTを使って見る。


WLST活用 WLSTサンプルの内容を理解し、カスタマイズして動作を確認する。

MBean MBeanを使ったWLSTを作成し理解を深める。


WLSTの機能

複数のツールで実行していたWebLogic Serverの管理作業をWLSTひとつに集約できる

ドメイン構成ウィザード

weblogic.Deployer

Administration Console

WLST


WLST操作の基本的な流れ

管理サーバ

Runtime Configuration Edit

cd

ls

get

startEdit cd set save activate

cd ls get

WLST edit edit

server Runtime

server Config

serverConfig serverRuntime

connect

① サーバに接続

② 操作目的に応じてツリー(MBeanサーバ)を移動

③ 目的のコマンドを実行


WLST操作

① サーバに接続

② 操作目的に応じてツリー(MBeanサーバ)を移動

③ 目的のコマンドを実行

a. ロックして編集

b. 管理対象サーバー作成

c. 保存

d. アクティブ化


WebLogic Server クラスタリング


WebLogic Serverクラスタリング


9月26日「Oracle WebLogic Serverクラスタリングの勘所」 http://www.slideshare.net/OracleMiddleJP/20130926-

wlstudy-clusterhandsout

http://www.slideshare.net/OracleMiddleJP/20130926-wlstudy-clusterhandsout







目標：クラスタの役割と機能を学ぶ。


クラスタ概要クラスタの役割と機能を理解し環境に合わせた設定ができること。

フェイルオーバ障害時の動作内容、振る舞いを理解。フェイルオーバの流れを理解する。

クラスタ環境設定クラスタグループなどの効率的な設定方法を学ぶ。


WebLogic Server クラスタ

複数の『サーバー』の論理的なグループ

– 各サーバー上にデプロイされたアプリケーション・サービスに対して拡張性・高可用性を提供する

– クライアントからは単一のサーバにアクセスしているように見えるように複数のサーバーが協調動作する

クラスタ

サーバーサーバー

サーバーサーバークライアント

クライアントはアクセスするサーバーを意識しない


サービス


設定箇所の確認

クラスタの設定: WebLogicドメインで設定

プロキシの設定: プロキシ側で設定

mydomain

cluster1

Server1

Web コンテナ

EJB コンテナ

Server2

Web コンテナ

EJB コンテナ

RDBMS プロキシ

データソース

データソース

AdminServer ドメイン設定

設定ファイル

HTTPサーバーやロードバランサの設定

WLSドメインの設定


Webアプリケーションのクラスタ化

クラスタにデプロイされたWebアプリケーションへの負荷分散・フェイルオーバーはプロキシプラグインによって行われる

– WebLogic Server Plugin (HTTP サーバー)

– ロードバランサ

Webアプリケーションのフェイルオーバーにはユーザの対話状態(HttpSession)

を永続化する必要がある

– インメモリレプリケーション

– Cookie

– File

– JDBC

通常はインメモリレプリケーションを第一候補に検討 HttpSessionの消失が許容できない場合はJDBCを検討信

頼性

高

低

速度

高

低


HttpSession永続化設定

HttpSessionの永続化設定は、Webアプリケーションのデプロイメント記述子(weblogic.xml)で指定

– IMRはreplicated | replicated_if_clustered (デフォルトは memory )

Webアプリケーションの設定

TIPS: 永続化方式にreplicated_if_clusteredを指定すると、クラスタ、非クラスタにデプロイ可能

weblogic.xml


インメモリレプリケーション

HttpSession をクラスタ内の2つのサーバーで保持する

– セッション毎にプライマリ・セカンダリサーバーが決定される

– サーバーにはプライマリ・セカンダリセッションが混在する

セカンダリ分だけヒープ消費量は増大

cluster1

プロキシ

Server1 Server2 Server3

セカンダリ

1

クライアント

プライマリ

1

2 2

3

3


インメモリレプリケーションの動作

プライマリサーバーは負荷分散によって初回リクエスト時に決定

– セカンダリサーバーはレプリケーション・グループとマシン設定からHttpSession生成時に決定

– セカンダリサーバーへの同期はHttpSession#setAttribute()がトリガ

– プライマリ・セカンダリサーバー情報

はCookieに埋め込まれる

正常時

cluster1

プロキシ


セカンダリ

setAttribute()

クライアント

プライマリ

プライマリ = Server3

セカンダリ = Server2



プライマリサーバーに障害が発生するとセカンダリが昇格

– 別のサーバでセカンダリが再生成される

プロキシプラグインによってセカンダリサーバーにリクエストの振り替えられる

– 振り替えはクライアントからの次の

リクエスト時

– プロキシプラグインはCookieの

サーバーリストをもとにセカンダリ

サーバーに接続

フェイルオーバー

cluster1

プロキシ

クライアント


プライマリプライマリセカンダリ





プライマリに昇格したサーバーはCookieを更新

– プライマリとセカンダリ情報が更新されたCookieがクライアントに戻される

フェイルオーバー

cluster1

Server1 Server3

セカンダリ

Server2

プライマリ

クライアント

setAttribute()



TIPS: セッションIDのフォーマット

[SessionID]![JVMID1]![JVMID2]![CreationTime]

プロキシ


cluster1

MachineX MachineY

インメモリレプリケーションとマシン

セカンダリセッションの作成先は別マシン上のサーバーが優先される

– 1つのH/W上に複数のサーバーが存在する場合はマシンを定義しないと同一

H/W上にセカンダリセッションが

作成される可能性がある

プロキシ


セカンダリ

1

クライアント

プライマリ

1

2 2 2


インメモリレプリケーションの考慮事項

リクエストのフェイルオーバーはプラグインによって行われる

– クライアントからのリクエスト到達までにプライマリ/セカンダリサーバーが共にダウンするとセッションは継続できない

– セッションの消失が許容できない場合はインメモリレプリケーションは選択不可

– IMRを使用する場合は3つ以上のサーバーでクラスタを構成することを推奨

HttpSessionに格納するデータサイズが大きすぎるとレプリケーションでオーバーヘッドが発生する

– HttpSessionに格納するデータは可能な限りコンパクトに

java.io.Serializableの実装も忘れずに

– 同期のトリガはHttpSession#setAttribute()


Java EE


Java EE


3月21日「Java Persistence API入門」 http://www.slideshare.net/OracleMiddleJP/java-persistence-

api-17707340

3月21日「WebLogic ServerでJAX-RS」 http://www.slideshare.net/OracleMiddleJP/weblogic-

serverjaxrs

6月20日「Context and Dependency Injection(CDI)

入門」 http://www.slideshare.net/OracleMiddleJP/20130620-

wlstudy-cdiv01

http://www.slideshare.net/OracleMiddleJP/java-persistence-api-17707340








http://www.slideshare.net/OracleMiddleJP/weblogic-serverjaxrs




http://www.slideshare.net/OracleMiddleJP/20130620-wlstudy-cdiv01







目標：JPA, JAX-RS, CDIの概要を学ぶ。


JPA 目的、メリット、機能を理解し実際に使用する。

JAX-RS 目的、メリット、機能を理解し実際に使用する。

CDI 目的、メリット、機能を理解し実際に使用する。


JPA概要 Java Persistence APIの略

Java EE環境に限らず、Java SEでも利用可能

O/Rマッピングの仕様

– データベースのテーブルのレコードをJavaのオブジェクトに相互変換

– Javaのオブジェクトにアクセスし、データベース操作可能

「JSR-000317 JavaTM Persistence 2.0 (Final Release)」（2009年12月10日）

「JSR-000338 JavaTM Persistence 2.1 (Final Release)」（2013年5月22日）

データベース

Java

Object

マッピング（自動で相互変換）

App

参照挿入更新削除


JPAプログラミング

public static void main(String[] args) { Connection con = null; PreparedStatement stm = null; try { Class.forName(“oracle.jdbc.OracleDriver”); con = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:xe", "HR", "hr"); stm = con.prepareStatement("SELECT * FROM Employees e WHERE e.EMPLOYEE_ID = ?"); stm.setInt(1, 100); ResultSet rSet = stm.executeQuery(); if (rSet.next()) { Employee emp = new Employee(); emp.setEmployeeId(rSet.getLong("EMPLOYEE_ID")); emp.setLastName(rSet.getString("LAST_NAME")); emp.setFirstName(rSet.getString("FIRST_NAME")); emp.setEmail(rSet.getString("EMAIL")); emp.setPhoneNumber(rSet.getString("PHONE_NUMBER")); emp.setHireDate(rSet.getDate("HIRE_DATE")); emp.setJobId(rSet.getString("JOB_ID")); emp.setSalary(BigDecimal.valueOf(rSet.getLong("SALARY"))); emp.setCommissionPct(BigDecimal.valueOf(rSet.getLong("COMMISSION_PCT"))); emp.setDepartmentId(BigDecimal.valueOf(rSet.getLong("DEPARTMENT_ID"))); System.out.println(emp); } } catch (ClassNotFoundException e) { e.printStackTrace(); } catch (SQLException e) { e.printStackTrace(); } finally { try { if (stm != null) stm.close(); if (con != null) con.close(); } catch (SQLException e) { e.printStackTrace(); } }

public static void main(String[] args) { EntityManager em = Persistence.createEntityManagerFactory("db").createEntityManager(); Employee emp = em.find(Employee.class, 100L); System.out.println(emp); em.close(); }

コード量大幅削減


JPAの構成要素

Persistence Context

EntityManager

Persistent Unit

（persistence.xml）

EntityManagerFactory

Entity

Entity

Entity

Entity

Entity

データベース

決定生成

Persistence Unitの設定に基づき、Entity Managerのインスタンスを生成

データ操作及び管理の為のAPIを提供する


Entityとは

テーブルに対応したマッピング対象のクラス（＝Entity）

– ただのPOJO（Plain Old Java Object）で作成

– @Entityアノテーション ⇒ Entityクラスであることを示す

– @Idアノテーション ⇒ 主キーを示す

@Entity public class Customer { @Id private Long id; private String address1; private long age; private String name; private String telephone; //セッタ・ゲッタ }

ID ADDRESS1 AGE NAME TELEPHONE

Entity Customerクラス

データベース

CUSTOMER表


Entityのライフサイクル


Entityのライフサイクル（コード例）

ライフサイクルのコード例

– Entityのインスタンスを生成（new）しただけではデータベースには何も反映されない

EntityManagerFactory emf = Persistence.createEntityManagerFactory(”DB"); EntityManager em = emf.createEntityManager(); EntityTransaction tx = em.getTransaction(); Customer customer = new Customer(); //Entityの生成 tx.begin(); em.persist(customer); //管理状態のEntity tx.commit(); //デタッチ状態になるEntity //JavaのHeapにはcustomerは存在するが、JPAの管理状態から外れデタッチ状態 //この状態でcustomerに対する操作を行った場合は、merge()で同期 em.close(); emf.close();


2種類のEntityManager コンテナ管理のEntityManager（Java EE環境）

– アノテーション、DIによりEntityManagerインスタンスを注入

– コンテナがトランザクションを管理する

アプリケーション管理のEntityManager（Java SE/EE環境）

– Factoryメソッドを使用して、EntityManagerを取得

– アプリケーション側でトランザクションを管理のためのコーディング必要

@PersistenceContext(unitname = “DB”) private EntityManager entityManager;

EntityManagerFactory emf = Persistence.createEntityManagerFactory(“DB"); EntityManager em = emf.createEntityManager(); EntityTransaction tx = em.getTransaction(); tx.begin(); em.persist(customer); tx.commit(); em.close(); emf.close();


JAX-RS概要

The Java™ API for RESTful Web Servicesの略

JAX-RSはHTTPを使用したシンプルなWebサービスの仕様

ステートレスであり、セッション情報などの状態を保持しない。

「JSR-000311 JAX-RS 1.1: The JavaTM API for RESTful Web Services」（2009年9月17日）

「JSR-000338 JAX-RS 2.0: The JavaTM API for RESTful Web Services」（2013年5月24日）


JAX-RSとは 3月21日「WebLogic ServerでJAX-RS」資料引用


Context and Dependency Injection(CDI)概要

JSR 299: Contexts and Dependency Injection for the JavaTM EE platform

（2009年12月10日）

Contexts：サーバ上の状態を表現するもの

Dependency Injection：依存性の注入

コンポネント間を疎結合にできるコードがよりシンプルになる

インスタンスのライフサイクル管理や

インスタンス(の依存関係)の注入をコンテナが引き受ける

（＝プログラマが、クラスをnewしたり、setメソッドを呼び出す必要が減少）


CDIができること

DI(依存性注入) インターセプト

インスタンスのライフサイクル管理 EL式からのアクセス

Bean

Bean HTTPリクエスト


Java EE 5のDI

DIの機能はJava EE 5 でも使用可能だが…

@ManagedBean public class SampleMg { @EJB private Logic lg; }

JSF EJB JPA 依存関係

@Stateful public class Logic { @PersistenceContext(unitName=“JPA”) private EntityManager em; }

<?xml version="1.0" encoding="UTF-8" ?> <persistence xxx> <persistence-unit name=“JPA"> …略

プレゼンテーション層ビジネスロジック層データアクセス層

依存関係

注入する種別によってアノテーションが異なる注入先も限定的


Java EE 6のCDI

CDIを使用したコーディング

@Named @RequestScoped public class SampleMg { @Inject private Logic lg; }

JSF EJB JPA 依存関係

@Stateful public class Logic { @Inject private EntityManager em; }

<?xml version="1.0" encoding="UTF-8" ?> <persistence xxx> <persistence-unit name=“JPA"> …略

プレゼンテーション層ビジネスロジック層データアクセス層

依存関係

注入する種別が異なっても@Injectで注入可能注入先も自由


Java EE 6のCDI：何を注入するか

注入先の型がインターフェースの場合

実装クラスのインスタンスを生成して注入

実装クラスが複数ある場合はエラー

public class xxBean{ @Inject private BizLogic logic; }

public class BizLogicImpl implement BizLogic { }

public class xxBean{ @Inject private BizLogic logic; }

public class BizLogicImplJAPAN implement BizLogic { }

public class BizLogicImplUS implement BizLogic { }

Error

Qualifierの機能を使用して適切に注入できるようになる

public class xxBean{ @JPN @Inject private BizLogic logic; }

@JPN public class BizLogicImplJAPAN implement BizLogic { }

注入

注入

解決方法例


WebLogic Serverチューニング


WebLogic Serverチューニング


11月27日「Oracle WebLogic Serverチューニングのポイント」


wlstudy-tuninghandsout

http://www.slideshare.net/OracleMiddleJP/20131127-wlstudy-tuninghandsout







目標：チューニング要素をマスター


WebLogic Serverアーキテクチャリクエスト処理の流れを理解する。

ワークマネージャ機能、振る舞いを理解する。

リソース全体最適のためにリソースを効率良く使うためのTipsをマスターする。


WebLogic Server EAR

WebLogic Serverのリクエスト処理リクエスト処理でポイントになる箇所

データベース

クライアントクライアントクライアントクライアントクライアント

SocketMuxer

WorkManager

Webコンテナ EJBコンテナ

(フリープール) データ

ソース

7001

データベースへの接続要求が最大容量を超えると待ちが発生する

SLSBのフリープールサイズが小さいとEJB呼び出しで待ちが発生する

スレッドプールのスレッドがワークマネージャによって使用される

スレッド数は負荷に応じて自動チューニングされる

原則としてMuxerはNativeI/Oを使用

ワークマネージャに最大容量が設定されているとスレッド割り当て待ちが発生する

最大容量を設定しないとスレッド数が増えすぎて適性な性能を得られない場合がある

カスタムワークマネージャを使用する場合はアプリケーション側で指定


WebLogic Server EAR

WebLogic Serverのリクエスト処理クライアントからのリクエストはスレッドで処理される

データベース

SocketMuxer

WorkManager

Webコンテナ EJBコンテナ

(フリープール) データ

ソース

7001

単一のスレッドプールの実行スレッドでリクエストを処理

SocketMuxerによって実行スレッドに引き渡される

Muxerキュー

Muxerスレッド

スレッドプール

ワークマネージャ

バックログ

リクエスト受信リクエスト処理

リクエストはMuxer

キューへ(リスンスレッド)


ワークマネージャの構成要素

ワークマネージャ

– 要求クラス … フェアシェア、応答時間、コンテキストのうち1つを指定

– 制約 … 最大スレッド数、最小スレッド数、容量を任意で指定

要求クラスと制約

ワークマネージャ要求クラス

制約 1

制約 2


要求クラスリクエストの重みを決定する

要求クラス説明

フェアシェア要求クラスリクエスト割り当ての重みを指定フェアシェアは1～1000の任意の数値を指定。

2つのワークマネージャにそれぞれフェアシェア10, 20を設定した場合は1:2の割合でスレッドが割り当てられる

応答時間要求クラス応答目標時間を指定 2つのワークマネージャにそれぞれ2000ms, 1000msと応答時間を設定した場合は1:2の割合でスレッドが割り当てられる

コンテキスト要求クラスユーザ/グループ毎に要求クラスを指定ユーザAにフェアシェア50、ユーザBにフェアシェア100の要求クラスを設定した場合はユーザBのリクエストに多くスレッドが割り当てられる


制約スレッド生成やリクエスト数を制限する

最大スレッド数制約最大同時実行数複数ワークマネージャで共有可能

最小スレッド数制約最小同時実行数主にデッドロック防止のために使用

容量制約実行中+キューに滞留するリクエストの最大数容量制約に達するとリクエストは拒否される


過負荷保護機能

サーバの処理能力を超えるリクエストを受入れ続けると過負荷状態に陥る

– システムを過負荷状態から保護・検出するための設定

スレッドプール内の要求数の制限 (共有容量)

HTTPセッション数の制限

メモリ不足例外発生時の終了・低メモリ状態の検出

スタックスレッドの処理

– 過負荷状態のサーバは強制停止・再起動するように設定可能

要設定。デフォルトでは何もしない


データソース

アプリケーションで接続待ちが発生しないことが理想的

– 接続待ちが発生しないように最大容量を設定する

実行スレッド数を目安に設定を開始、負荷状況によって最大容量を決定する

– 原則は初期容量=最大容量

初期容量と最大容量に差があると容量増加時に待ちが発生する可能性あり

容量の管理がキーポイント


Tips: 最大容量と最大スレッド数制約

ワークマネージャの最大スレッド数制約ではデータソースの最大容量を指定することができる

データソースの最大容量を超える実行スレッドの生成を抑制するには?

データソース名を指定

データソースの最大容量が容量制約数になる

解消できる問題点: 自動チューニングスレッドプールで負荷に応じてスレッド数が増えてもデータソースの最大容量を超えてしまうと接続待ちによる処理の遅延が発生する


参考: モニタするMBean属性

MBean 属性

JDBCDataSourceRuntime CurrCapacity

ActiveConnectionsCurrentCount

WaitingForConnectionCurrentCount

ThreadPoolRuntime ExecuteThreadTotalCount

ExecuteThreadIdleCount

StandbyThreadCount

PendingUserRequestCounts WorkManager単位でのPending数を取得する場合はRequestClassRuntime

必要に応じてHighCountも取得

ActiveConnectionsHighCount

WaitingForConnectionHighCount

アクティブなスレッド数は以下で算出 = ExcecuteTreadTotalCount – ExecuteThreadIdleCount

– StandbyThreadCount


参考: モニタするMBean属性

MBean 属性

ServerRuntime OpenSocketsCurrentCount

WebAppComponentRuntime OpenSessionsCurrentCount

StatelessEJBRuntime PooledBeansCurrentCount

BeansInUseCurrentCount

WaiterCurrentCount

JVMRuntime HeapFreeCurrent

HeapSizeCurrent


WebLogic Server トラブルシューティング


WebLogic Serverトラブルシューティング


1月24日「スローダウン、ハングを一発解決！スレッドダンプはトラブルシューティングの味方」

http://www.slideshare.net/yusukey/wlstudy

5月23日「今日から始めるトラブルシューティング - Flight

Recorder入門」 http://www.slideshare.net/OracleMiddleJP/flight-recorder-

22422966

11月27日「高負荷試験で得た体験談」 http://www.slideshare.net/OracleMiddleJP/ss-29344482

12月19日「Oracle WebLogic Serverトラブルシューティングのポイント」


wlstudy-troubleshootinghandsout

12月19日「Flight Recorder活用の実践」 http://www.slideshare.net/OracleMiddleJP/jfr-fordevelopers



http://www.slideshare.net/OracleMiddleJP/flight-recorder-22422966










http://www.slideshare.net/OracleMiddleJP/20131219-wlstudy-troubleshootinghandsout






http://www.slideshare.net/OracleMiddleJP/jfr-fordevelopers





目標：トラブルシューティング総合力向上

テーマFlight Recorder チャレンジ項目

トラブルシューティング準備万一に備えて必要な情報収集や設定を行うためのノウハウを養う。

障害時対応障害時に適切な情報やツールを活用して原因究明を行う。

Flight Recorder Mission Controlを使用してFlight Recorderイメージファイルから障害時に遡って状況分析を行う。


トラブルシューティング手法

利点考慮事項

ログサーバーで発生するイベントを時系列で取得可能。トラブル発生時の初期情報の収集に最適。

サーバログ … サーバのアクティビティ

GCログ … GCの発生頻度

HTTPログ … ユーザリクエスト

情報が各ログファイルに分散しているため一元的に情報を把握しにくい

・Enterprise Managerを使用すると横串検索可能

Javaスレッドダンプ JVMで行われているスレッド処理のスナップショットを取得。低負荷のため本番環境でも取得可能。

スレッドダンプはテキスト情報のため必要に応じてデータ加工の必要あり

・侍, ThreadLogicなど各種ツールを活用

WLDFイメージキャプチャサーバーの設定、モニタ情報、ログ、スレッドダンプをまとめて取得可能。WLDFモジュールを設定すればルールに基づいて自動的にイメージキャプチャを取得可能。

イメージキャプチャ取得のオーバーヘッドとディスクサイズを考慮する必要アリ

自動キャプチャにはWLDFモジュールを構成する必要がある

Flight Recorder JVM+WebLogic Serverで発生するイベント詳細レベルで取得。Mission Controlを使用してGUIベースで解析可能。

常時Flight 記録を取得する場合はディスクサイズを考慮する必要アリ

情報収集ツールの比較


トラブル発生時に集めるべき情報は？

WebLogic Serverのログファイル

– サーバーログ … <DOMAIN>/servers/<server_name>/logs/<server_name>.log

WebLogic Serverのアクティビティが記録されるログファイル。

– ドメインログ … <DOMAIN>/servers/<admin_server>/logs/<domain_name>.log

サーバーログを集約したもの。障害調査ではあまり使わない。

– HTTPログ … <DOMAIN>/servers/<server_name>/logs/access.log

クライアントからのアクセスを記録。拡張フォーマットを使うとリクエスト処理時間も取得可能

ログ情報 TIPS: 拡張フォーマットの設定方法 ( [サーバー]-[ロギング]-[HTTP] ▼詳細 )

1. フォーマットを拡張に変更

2. 拡張ロギング・フォーマットのフィールドを指定

date time c-ip s-ip cs-method cs-uri cs-uri-query sc-status bytes time-taken


Tips: サーバーの標準出力のリダイレクト

サーバーの標準出力のリダイレクトは環境変数 WLS_REDIRECT_LOG

を指定する

startWebLogic.sh(cmd)を編集

WLS_REDIRECT_LOGの設定を追記


サーバーログの重大度

Severity 説明ドメインログ

TRACE 診断フレームワークからのメッセージ

DEBUG デバッグメッセージ(Debug=ONの場合)

INFO 通常の処理を通知するために使用する低レベルの情報メッセージ

NOTICE 重要度の高いINFOメッセージ ○

WARNING 問題のあるオペレーションまたはコンフィグレーションがあったが、通常のオペレーションに支障は生じない

○

ERROR ユーザエラーが発生したことを示す。システムまたはアプリケーションでは、割り込みやサービスの限定的な低下を起こすことなくエラーに対処できる

○

CRITICAL システムエラーまたはサービスエラーが発生したことを示す。システムを回復できるが、サービスの一時的な損失や永久的な低下が発生する場合がある

○

ALERT システムの特定のサービスだけが使用不能の状態にある。自動回復を実行できない。この問題を解決するには管理者がすぐに措置を講じる必要がある

○

EMARGENCY サーバが使用不能な状態にある。この重大度は、重大なシステム障害または問題があることを示す

○

NOTICE以上のメッセージはデフォルトでドメインログに転送される

低

高


Tips: デバッグ情報サーバー単位で設定可能

デバッグ出力例: DebugJDBCSQL(コンソール:weblogic→jdbc→sql→DebugJDBCSQL/WLST ServerDebugMBean) ####<2013/12/15 15時43分43秒 JST> <Debug> <JDBCSQL> <DAOKADA-JP> <ManagedServer1> <[ACTIVE]

ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-00036DDE372208547105> <1b7e5955c26b51de:29038235:142f4fe00cd:-8000-000000000000003e> <1387089823815> <BEA-000000> <[[weblogic.jdbc.wrapper.JTAConnection_weblogic_jdbc_wrapper_XAConnection_oracle_jdbc_driver_LogicalConnection-hrDataSource-4, oracle.jdbc.driver.LogicalConnection@2460cd3]] prepareStatement(SELECT EMPLOYEE_ID, COMMISSION_PCT, DEPARTMENT_ID, EMAIL, FIRST_NAME, HIRE_DATE, JOB_ID, LAST_NAME, MANAGER_ID, PHONE_NUMBER, SALARY FROM EMPLOYEES WHERE (FIRST_NAME LIKE ? OR LAST_NAME LIKE ?))>

デバッグ属性を選択して

有効化 or 無効化


Tips: GCログオプション

説明 HotSpot JRockit

GCログ -verbose:gc -verbose:gc

GCログ(詳細) -XX:+PrintGCDetails -Xverbose:gcreport

-Xverbose:gcpause

GCのタイムスタンプ出力 -XX:+PrintGCTimeStamps (サーバー起動からの経過時間)

-Xverbosetimestamp

GCログをファイル出力 -Xloggc:<file_name> -Xverboselog:<file_name>

[gcpause][Tue May 21 10:42:45 2013][04868] [YC#25] [---] 26.105 ms (1236.973000-1236.999000) YC [gcpause][Tue May 21 10:42:45 2013][04868] [YC#25] [con] 0.002 ms (1236.973000-1236.973000) YC:PreGC [gcpause][Tue May 21 10:42:45 2013][04868] [YC#25] [pau] 26.062 ms (1236.973000-1236.999000) YC:Main [gcpause][Tue May 21 10:42:45 2013][04868] [YC#25] [con] 0.008 ms (1236.999000-1236.999000) YC:PostGC

[gcpause][Tue May 21 10:42:45 2013][04868] [OC#1] [---] 45.613 ms (1236.999000-1237.045000) OC [gcpause][Tue May 21 10:42:45 2013][04868] [OC#1] [con] 0.004 ms (1236.999000-1236.999000) OC:PreGC [gcpause][Tue May 21 10:42:45 2013][04868] [OC#1] [pau] 44.730 ms (1236.999000-1237.044000) OC:Main [gcpause][Tue May 21 10:42:45 2013][04868] [OC#1] [con] 0.810 ms (1237.044000-1237.045000) OC:PostGC


トラブル発生時に集めるべき情報は？

スレッドダンプとは

– JVMで実行中のスレッドのスナップショット

スレッドがどんな処理を実行しているのか？

– JVMの標準機能

WebLogic Serverの障害解析以外でも活用可能

標準出力(/標準エラー出力)に出力される

Javaスレッドダンプ

スレッドダンプはシステムに負荷をかけずに情報収集できる最良のツール

スレッドダンプ取得時は

一定間隔で複数回取得


スレッドダンプの取得方法

OS

– CTRL + BREAK / wlsvc -dump -svcname:service-name (Windows)

– kill -3 <pid> (Linux/UNIX)

WLST

– ThreadDump()

JVM

– jstack <pid> (HotSpot)

– jrcmd <pid> print_threads (JRockit)

Tips: Javaプロセスのpidは jps コマンドで確認 (HotSpot/Jrockitどちらでも使用可能)


Tips: WebLogic Server診断フレームワーク WebLogic Server全体を監視、診断するための機能

監視データを生成する仕組み

構成情報や解析に必要な情報を統合的に取得する仕組み

監視対象の設定と通知の仕組み

監視データを取得する仕組み

監視データを

画面表示する

仕組みインスツルメンテーション

データパブリッシャ

データプロバイダ

(MBean)

イメージキャプチャ

データをファイルとして出力する仕組み

アーカイバ

ロガー

ハーベスタ

監視と通知

アクセサ


障害時に集めるべき情報は？

スレッドダンプやGCログはトラブル解決に有益だが…

– トラブルが発生した瞬間に取得できるわけではない

– 必要な情報が得られない場合もある

Java Flight Recorder

– トラブル解決に必要な情報を常時記録可能 (=本番環境でも低負荷)

– JVMからアプリケーション(+WLS)まで幅広い情報を記録

必要なときに情報が得られるか？

トラブルの確実な原因を「遡って」追跡可能に

トラブルの発生から改善までのサイクルと手間を大きく短縮に


Java Flight Recorder 全ては記録される

WebLogic Server

Mission Control

WLDF イベントイベント

Disk File

古いデータ

WLST

Applicatio

n Application WebLogic

JVM

Runtime

jrcmd/jcmd

ダンプ解析

ダンプ依頼

ダンプ依頼

ダンプ

ルールに基づくダンプトリガー

ダンプ依頼

イベント

診断イメージ

キャプチャダンプ依頼

Thread Buffer

Global Buffer

新しいデータあふれたら移動

あふれたら移動

Rotating Buffer

Flight Recorder Runtime

FlightRecorder.jfr


WebLogic ServerとFlight Recorderの連携

WebLogic ServerはFlight Recorderと連携可能

– サーバーで発生したイベントをFlight Recorderに送信

– WLDF診断イメージキャプチャにFlight Recorder記録を含める

WLDF Flight

Recorder

イベント

イメージキャプチャ


Flight Recorder記録 Mission Controlの表示


JRockit Mission Control MemoryLeak Detector

2013年weblogic server勉強会の総まとめ

Technology