タグ「Payara」が付けられているもの

Payara Quick Start Guide

This article is revised and English transleted of the post 3rd December 2016.

Recently, Payara users are growing near by me. Most of them migrate from GlassFish, but it's certainly that Payara is the first Java EE server for someone. Then I note minimum instruction for using Payara.

0. Requirements

0.1. JDK

Payara is required JDK 7, or JDK 8 Update 20 or later. About JDK's set up is omitted because it's dependent with target OS. But I suggest to use the newest as possible. Remember setting path to JVM (java / java.exe). Attention: Payara ignores JAVA_HOME environment variable.

0.2. Network settings

In case of some OS, almost listen ports are closed in default. If your environment is such a thing, you need to add a settings of listen ports. Payara listens mainly TCP 4848, 8080 and 8181 ports. In addition to enable Hazelcast, you need to open 5900 and later ports (maximum 5999). Note: To use Payara Micro, Hazelcast is enabled in default.

1. Instruction of development environment

1.1. Downloading Payara Server

Download Payara Server from http://www.payara.fish/downloads (If you need Multi-Language edition, Access to http://www.payara.fish/all_downloads). When to download, you don't any registrations. Even if you use Payara Micro as operation, it's easy to develop applications on Payara Server.

In case of Payara 4.1.1.171.1 (latest release at the time), you may select following one;

  • Payara 4.1.1.171.1 (Full) : payara-4.1.1.171.1.zip
  • Payara-Web 4.1.1.171.1 (Web Profile) : payara-web-4.1.1.171.1.zip
  • Payara-ML 4.1.1.171.1 (Multi-Language Full) : payara-ml-4.1.1.171.1.zip
  • Payara-Web-ML 4.1.1.171.1 (Multi-Language Web Profile) : payara-web-ml-4.1.1.171.1.zip

I suggest you may select Full Platform i.e. payara-4.1.1.171.1.zip for development. If you need Web Profile (e.g. planning to use Payara Micro in operation), restricted by Maven dependency (javax:javax-ee-web:7.0).

1.2. Installation of Payara Server

Extract payara-4.1.1.171.1.zip to any directory. But on Windows, avoid to the directory it's named spaces (e.g. C:\Program Files). If you are an administrator of the computer, extract to C:\ (on Windows) or /opt (on Linux/Solaris) for ease. Then Payara Server installed on C:\payara41 (on Windows) or /opt/payara41 (on Linux/Solaris).

If you're not an administrator, it may extract to %USERPROFILE% (C:\Users\username) on Windows or $HOME (/export/home/username or /home/username) on Linux/Solaris.

1.3. IDE Settings for Payara Server

Payara Server is controlled by major IDEs with some settings.

1.3.1. Eclipse

In case of Eclipse , you should GlassFish Tools contained in Oracle Enterprise Pack for Eclipse (OEPE) (It's no problem to contain other plugins of OEPE). Choose GlassFish 4 for server type, and input C:\payara41\glassfish (Windows) or /opt/payara41/glassfish (Linux/Solaris) for installed directory. Pay attention to setting it glassfish directory that is a sub directory of Payara's install directory. (There's Nucleus, the core modules of Payara) Other choices may be still in defaults.

You may also obtain GlassFish Tools from Eclipse Marketplace.

1.3.2. NetBeans

NetBeans can integrate with GlassFish using a built in feature. Add a server instance in Service - Servers. Choose GlassFish Server as server type, and input C:\payara41 (Windows) or /opt/payara41 (Linux/Solaris) as installed directory. Other choices may be still in defaults. Note: NetBeans can download a server instance if not exists. But it never use for Payara because it will download GlassFish.

1.3.3. IntelliJ IDEA

IntelliJ IDEA can integrate with GlassFish using a built in feature. At first, choice Glassfish Server on Default Settings -> Build, Execution, Deployment -> Application Servers. And then required Glassfish Home directory, input C:\payara41 (Windows) or /opt/payara41 (Linux/Solaris). Other choices may be still in defaults.

1.4. Using Payara Server as development environment

Payara Server in development is usually started, stopped and deployed from IDE. Thus you may know following three operations for Payara Server.

  • payara41/bin/asadmin start-domain to start Payar Server
  • payara41/bin/asadmin stop-domain to stop Payara Server
  • Using admin console http://localhost:4848/ to operate Payara Server during Payara Server is running

Payara's admin console is such a Web UI;

payara-admingui-top.png
figure 1 - Payara Server Console (Dev.)

2. Instruction of operating envirionment

2.1. Downloading Payara Server

Download Payara Server from http://www.payara.fish/downloads as same as instruction of developing envirionment.

In case of Payara 4.1.1.171.1 (latest release at the time), you may select following one;

  • Payara 4.1.1.171.1 (Full) : payara-4.1.1.171.1.zip
  • Payara-Web 4.1.1.171.1 (Web Profile) : payara-web-4.1.1.171.1.zip
  • Payara-ML 4.1.1.171.1 (Multi-Language Full) : payara-ml-4.1.1.171.1.zip
  • Payara-Web-ML 4.1.1.171.1 (Multi-Language Web Profile) : payara-web-ml-4.1.1.171.1.zip

In case of operating environment, you should select to install either Full Platform or Web Profile. For many purposes, Web Profile is better. If you want to use APIs without Web Profile, you need to install Full Platform.

See also following slides about Web Profile.

It's easy to operate Payara Server using mainly admin console. You may use localized admin console to convenient. Then you may install Web Profile Multi-language : payara-ml-4.1.1.171.1.zip.

Tips: When you post an issue in trouble, it's precondition to use English UI. Thus I suggest you also prepare English version for reproducing tests.

2.2. Installation of Payara Server

Extract payara-4.1.1.171.1.zip to any directory. But on Windows, avoid to the directory it's named spaces (e.g. C:\Program Files). If you are an administrator of the computer, extract to C:\ (on Windows) or /opt (on Linux/Solaris) for ease. Then Payara Server installed on C:\payara41 (on Windows) or /opt/payara41 (on Linux/Solaris).

2.3. Enable to remote access to Payara Server

2.3.1. Setting the admin password

Payara is not set the admin pasword in default. It's mean that remote access to Payara Server is disabled in default. Then, at first, you should set the admin password. Use asadmin change-admin password command to set the admin password. see follows;

C:\payara41\bin>asadmin change-admin-password
Enter admin user name [default: admin]>
Enter the admin password>
Enter the new admin password>
Enter the new admin password again>
Command change-admin-password executed successfully.

asadmin change-admin-password command works two tasks, (1) set admin user name, (2) set or change admin password. The input is following items;

  1. admin user name: If use 'admin', you may empty this item
  2. the admin password: current password; In default, it must set empty because the default admin password is empty
  3. the new admin password: input the password
  4. the new admin password again: input the password again

Attention: The first item is admin user name (not password), don't miss.

2.3.2. Enable secure administration

Payara rejects remote access via HTTP (plain text), so you should enable secure administration (remote access via HTTPS). To enable or disable secure administration is needed to run Payara Server, you start to use asadmin start-domain command.

Then you enable secure administration using asadmin enable-secure-admin command. the command requires admin user name and password. because you should set the admin password the previous step.

C:\payara41\bin>asadmin enable-secure-admin
Enter admin user name>  admin
Enter admin password for user "admin">
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.

After secure administration is enabled, you have to reboot Payara Server. You may use convenient command, asadmin restart-domain.

To enable and disable secure administration is also supported by admin console. But Web browser maybe disabled on Payara Server's machine. So I suggest to use command line.

2.4. Using Payara Server as operating envirionment

It's easest that (1) Start to asadmin start-domain command, (2) Stop to asadmin stop-domain command, (3) Other operations are on admin console. Admin console URL via remote access is https://<hostname>:4848/ and require 'User Name' (admin user name, 'admin' in default) and 'Password' (the admin password).

payara-admingui-login.png
figure 2 - Payara Server Log-in (Admin Console)

Set enable-secure-admin when to enable remote access. It means that you access to admin console via HTTPS (HTTP over SSL/TLS) instead of HTTP and using encrypted connection. (To access to admin console is restricted via HTTPS since GlassFish 3.1.2?) Web browsers will block to access admin console once because key store of Payara Server is not ready. But even if it's in intranet, you can ignore and force access to admin console.

payara-admingui-top.png
figure 3 - Payara Server Console (Ops.)

3. Starting up Payara Micro

3.1. Downloading Payara Micro

3.1.1. Download from the Web site

Download Payara Micro 171 (payara-micro-4.1.1.171.1.jar) from http://www.payara.fish/downloads (If need, you may change the file name to any).

3.1.2. Maven integration

Add dependencies to pom.xml in a Maven Project as following. Then Payara Micro is downloaded automatically from Maven Central Repository.

<dependencies>
  <groupId>fish.payara.extras</groupId>
  <artifactId>payara-micro</artifactId>
  <version>4.1.1.171.1</version>
</dependencies>

3.2. Using Payara Micro as operating environment

3.2.1. Run Payara Micro

At first, prepare a WAR file of Web application; webapp.war. Basically you develop a Web application using Payara Server even if you run it on Payara Micro.

And then, run Payara Micro on a terminal.

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war

Ctrl + C to exit.

Payara Micro is enabled Hazelcast clustering in default. (Payara Server is disabled in default) Usually it need not change. If you set with --noCluster option to disable Hazelcast clustering and start up first such a little. But --noCluster option stops whole of Hazelcast, it's disabled not only automatic clustering but also JCache.

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war --noCluster

3.2.2. Create Uber Jar and run

You can create Uber Jar (webapp.jar) from Payara Micro and WAR files.

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war --packageUberJar webapp.jar

After create Uber Jar, you run it directly.

java -jar webapp.jar

Uber Jar is Payara Micro includes WAR files. You may use various options of Payara Micro, and Ctrl + C to exit.

4. Conclusion

Payara is growing day by day. Recently it is not only "well-maintained GlassFish" but also fitting for commertial use. Now it's features are so many and powerful, but it's minimal instruction to use is kept simple. I wish Payara is used many people -- from newbies to experts.

Payara クイック・スタート・ガイド

この記事は、2016 年 12 月 3 日の「Payara クイック・スタート・ガイド」の改訂版です。

最近、私の周りで Payara ユーザーが増えてきました。その多くは GlassFish から移行してきた方々ですが、今後 Payara が最初の Java EE サーバーとなる方々も出てくるかと思います。そういった方々に向けて、Payara の実用レベルで最低限のセットアップをまとめておきます。

0. 事前準備

0.1. JDK

Payara を動作させるには JDK 7 または JDK 8 Update 20 以降が必要です。OS によってセットアップ手順が異なるため割愛しますが、できるだけ新しい Update を使用することをおすすめします。なお、JVM (java / java.exe) へのパスはあらかじめ設定しておいてください (注意: Payara は JAVA_HOME 環境変数を参照しません)。

0.2. ネットワーク設定

いくつかの OS では既定でほとんどのポートの受信を拒否するよう設定されています。これらの OS では、Payara で使用する TCP ポートの受信を許可するよう設定変更が必要です。Payara が使用する主なポートは、TCP 4848、8080、8181 です。Hazelcast を有効にする場合 (Payara Micro の場合は必須) はそれに加えて 5900 以降 (最大 5999) を空けておきます。

1. 開発環境向けスタートアップ・ガイド

1.1. Payara Server をダウンロードする

Payara Server をダウンロードします。http://www.payara.fish/downloads (多国語化版が欲しい場合は http://www.payara.fish/all_downloads) から無償で入手できます。ユーザー登録なども必要ありません。運用環境として Payara Micro を使用する場合でも、開発環境での作業は Payara Server で行った方が便利です。

Payara 4.1.1.171.1 (本稿執筆時点の最新版) の場合、基本的には以下のいずれかを選択することになります。

  • Payara 4.1.1.171.1 (Full) : payara-4.1.1.171.1.zip
  • Payara-Web 4.1.1.171.1 (Web Profile) : payara-web-4.1.1.171.1.zip
  • Payara-ML 4.1.1.171.1 (Multi-Language Full) : payara-ml-4.1.1.171.1.zip
  • Payara-Web-ML 4.1.1.171.1 (Multi-Language Web Profile) : payara-web-ml-4.1.1.171.1.zip

開発環境の場合は Full Platform の payara-4.1.1.171.1.zip を選択すると良いでしょう。必要に応じて (例えば、Payara Micro での運用を想定している場合など)、Maven の依存関係で javax:javax-ee-web:7.0 を設定して使用可能な API を Java EE Web Profile に制限する方法を採るのが現実的です。

1.2. Payara Server をインストールする

ダウンロードした payara-4.1.1.171.1.zip を展開します。展開先は自由に選べます (ただし Windows 環境では C:\Program Files などスペース入りのフォルダは避けた方が無難です)。管理者権限がある場合は、Windows では C:\ 以下に、Linux/Solaris では /opt 以下にそれぞれ展開すると分かりやすいです。展開後、Windows では C:\payara41 以下、Linux/Solaris では /opt/payara41 以下に Payara Server が配置されます。この状態でインストールは完了です。

管理者権限を持たない場合は、Windows では %USERPROFILE% (C:\Users\{ユーザー名}) 以下、Linux/Solaris では $HOME (/export/home/{ユーザー名} または /home/{ユーザー名}) 以下にそれぞれ展開すると良いでしょう。

1.3. IDE で Payara Server の設定を行う

Payara Server を IDE で制御できるように設定します。

1.3.1. Eclipse

Eclipse の場合は、Oracle Enterprise Pack for Eclipse (OEPE) に含まれる GlassFish Tools をインストールする必要があります (OEPE の他のプラグインが含まれていても問題ありません)。サーバーの種類として GlassFish 4 を選択し、サーバーのインストール先として C:\payara41\glassfish (Windows) または /opt/payara41/glassfish (Linux/Solaris) を選択します。Payara のインストール・ディレクトリ以下の glassfish サブディレクトリ (この場所が Payara のコアである Nucleus になります) まで指定する必要があることに注意してください。その他の設定項目は、既定値のままで良いでしょう。

なお、GlassFish Tools は Eclipse Marketplace からも入手することができます。

1.3.2. NetBeans

NetBeans には GlassFish との統合機能が含まれているため、これを利用します。サービス - サーバー画面で、サーバー・インスタンスを追加します。サーバーの種類として GlassFish Server を選択し、サーバーのインストール先として C:\payara41 (Windows) または /opt/payara41 (Linux/Solaris) を入力します。その他の設定項目は、既定値のままで良いでしょう。なお、NetBeans にはサーバー・インスタンスがない場合にダウンロードしてインストールする機能も備わっていますが、Payara の場合には使用できません (GlassFish がダウンロードされるため)。

1.3.3. IntelliJ IDEA

IntelliJ IDEA には GlassFish との統合機能が含まれているため、これを利用します。Default Settings -> Build, Execution, Deployment -> Application Servers で Glassfish Server を選択します。Glassfish Home ディレクトリをたずねられますので、C:\payara41 (Windows) または /opt/payara41 (Linux/Solaris) を入力します。その他の設定項目は、既定値のままで良いでしょう。

1.4. Payara Server を開発環境として使用する

開発環境の Payara Server は、通常 IDE から起動、停止およびアプリケーションのデプロイを行います。Payara Server の直接操作については、以下の 3 点を押さえておけば大丈夫でしょう。

  • payara41/bin/asadmin start-domain で Payar Server を起動
  • payara41/bin/asadmin stop-domain で Payara Server を停止
  • Payara Server の起動中は管理コンソール http://localhost:4848/ で大抵の設定操作は可能

Payara の管理コンソールは、以下のような Web UI となっています (英語版 UI)。

payara-admingui-top.png
figure 1 - Payara Server Console (Dev.)

2. 運用環境向けスタートアップ・ガイド

2.1. Payara Server をダウンロードする

Payara Server をダウンロードします。手順は開発環境の場合と同じです。Payara 4.1.1.171.1 の場合、基本的には以下のいずれかを選択することになります。

  • Payara 4.1.1.171.1 (Full) : payara-4.1.1.171.1.zip
  • Payara-Web 4.1.1.171.1 (Web Profile) : payara-web-4.1.1.171.1.zip
  • Payara-ML 4.1.1.171.1 (Multi-Language Full) : payara-ml-4.1.1.171.1.zip
  • Payara-Web-ML 4.1.1.171.1 (Multi-Language Web Profile) : payara-web-ml-4.1.1.171.1.zip

運用環境の場合は、まず Full Platform と Web Profile のどちらをインストールするかの判断が必要です。多くの用途では Web Profile が第一選択肢となるでしょう。Web Profile にない API が必要であれば Full Platform をインストールします。

Web Profile については以下の資料をしてください。

Payara Server の設定操作は管理コンソールを中心に行うのが便利です。その際、日本語化された UI は使い勝手が良いため、多国語版 Web Profile : payara-ml-4.1.1.171.1.zip を選択しても良いでしょう。

ただし、トラブル発生時の Issue は英語版 UI での利用が前提であるため、再現テストのために英語版 Web Profile 環境を別途用意しておくと安心です。

2.2. Payara Server をインストールする

ダウンロードした Payara Server の ZIP アーカイブ (payara-ml-4.1.1.171.1.zip など) を展開します。展開先は自由に選べます (ただし Windows 環境では C:\Program Files などスペース入りのフォルダは避けた方が無難です)。管理者権限がある場合は、Windows では C:\ 以下に、Linux/Solaris では /opt 以下にそれぞれ展開すると分かりやすいです。展開後、Windows では C:\payara41 以下、Linux/Solaris では /opt/payara41 以下に Payara Server が配置されます。この状態でインストールは完了です。

2.3. Payara Server のリモートアクセスを有効にする

2.3.1. 管理パスワードの設定

Payara の既定では、管理パスワードが設定されていません。リモートアクセスを有効にするのに先立って、まず管理パスワードを設定する必要があります。管理パスワードの設定には asadmin change-admin-password コマンドを使用します。

C:\payara41\bin>asadmin change-admin-password
Enter admin user name [default: admin]>
Enter the admin password>
Enter the new admin password>
Enter the new admin password again>
Command change-admin-password executed successfully.

ここでは、管理ユーザー名の決定と、管理パスワードの変更という 2 種類の操作を行います。入力項目は、以下の通りです。

  1. 管理ユーザー名: 既定の admin を使用する場合は空欄とします
  2. 現在の管理パスワード: 既定では管理パスワードは設定されていないため空欄とします
  3. 新しい管理パスワード: 管理パスワードを入力します
  4. 新しい管理パスワード: 入力した管理パスワードと同じものを確認のため入力します

最初に管理ユーザー名の設定があります。ここは見落としがちのため注意してください。

2.3.2. セキュア管理の有効化

リモートアクセスのためにセキュア管理 (HTTPS 通信) を有効化します。セキュア管理の有効化/無効化は Payara Server が起動している必要があるため、まず asadmin start-domain コマンドで Payara Server を起動します。

続いて、asadmin enable-secure-admin コマンドでセキュア管理を有効化します。その際には、先に設定した管理ユーザー名 (admin) と管理パスワードを入力する必要があります。

C:\payara41\bin>asadmin enable-secure-admin
Enter admin user name>  admin
Enter admin password for user "admin">
You must restart all running servers for the change in secure admin to take effect.
Command enable-secure-admin executed successfully.

セキュア管理を有効化した後は、Payara Server を再起動する必要があります。Payara Server の停止と起動を組み合わせても良いのですが、再起動を行う asadmin restart-domain コマンドを使用した方が高速です。

セキュア管理の有効化/無効化は管理コンソールでも操作できますが、Payara Server のインストール先が必ずしも Web ブラウザを備えているとは限らないため、コマンドラインから管理パスワードと同時に設定を行った方が無難です。

2.4. Payara Server を運用環境として使用する

手っ取り早い方法は、起動コマンドの asadmin start-domain と停止コマンドの asadmin stop-domain だけ覚えて、後の操作は管理コンソール上で行うことです。リモートアクセス時の管理コンソールの URL は https://<hostname>:4848/ となり、起動時にユーザー名 & パスワードの認証があります (ユーザー名は既定では admin となります)。

payara-admingui-login.png
figure 2 - Payara Server Log-in (Admin Console)

リモートアクセスを有効にする際に、enable-secure-admin を設定していますが、これにより管理コンソールへのアクセスが HTTP から HTTPS (HTTP over SSL/TLS) に変更され、暗号化通信となります (GlassFish 3.1.2 あたりから管理コンソールへのリモートアクセスは HTTPS に限定されるようになっています)。Payara Server のインストール直後は電子証明書のチェーンが整備されていないため、ブラウザ側で一旦アクセスをブロックされますが、イントラネット上であるため無視してアクセスを強行してください。その後、Payara の管理コンソールにアクセスできるようになります。

payara-admingui-top.png
figure 3 - Payara Server Console (Ops.)

3. Payara Micro スタートアップ・ガイド

3.1. Payara Micro をダウンロードする

3.1.1. Web サイトからのダウンロード

http://www.payara.fish/downloads から Payara Micro 171 (payara-micro-4.1.1.171.1.jar) をダウンロードします。ダウンロード後、ファイル名は必要に応じて変更しても構いません。

3.1.2. Maven 統合

Maven プロジェクトの pom.xml に以下の依存関係記述を追加します。これにより、Maven Central Repository から Payara Micro が自動的にダウンロードされ、プロジェクトに組み込まれます。

<dependencies>
  <groupId>fish.payara.extras</groupId>
  <artifactId>payara-micro</artifactId>
  <version>4.1.1.171.1</version>
</dependencies>

3.2. Payara Micro を運用環境として使用する

3.2.1. Payara Micro を通常実行する

まず、Web アプリケーションの WAR ファイルを用意します。ここでは WAR ファイルを webapp.war と仮定します。Web アプリケーションは基本的に Payara Server を使って開発することになるでしょう。

WAR ファイルが準備できたら、ターミナルから Payara Micro を起動します。

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war

終了する場合は Ctrl + C を使います。

Payara Micro は既定で Hazelcast による自動クラスタリングが有効になっています (Payara Server では無効)。通常はそのままでも問題ありませんが、--noCluster オプションを付けて無効化することで、少しだけ起動を早めることができます。ただし、--noCluster オプションを使用すると、Hazelcast そのものが無効化されるため、自動クラスタリングだけでなく JCache も使えなくなってしまうことに注意してください。

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war --noCluster

3.2.2. Uber Jar を作成して実行する

Payara Micro と WAR ファイルから Uber Jar を作成することもできます。ここでは、出力する Uber Jar の名前を webapp.jar と仮定します。

$ java -jar payara-micro-4.1.1.171.1.jar --deploy webapp.war --packageUberJar webapp.jar

作成後は、直接 Uber Jar を実行することになります。

java -jar webapp.jar

Payara Micro の Uber Jar は、実際には WAR ファイルを内包した Payara Micro です。Payara Micro の起動時オプションが使用できるほか、Ctrl + C で終了できる点も共通しています。

4. まとめ

Payara は日々進化を続けており、当初の「より良い GlassFish」から、本格的な商用 Java EE サーバーとなるべく様々な機能が追加されています。しかし、最小限の設定は決して多くなく、今回ご紹介した内容をもとに簡単な環境構築は可能です。

皆様に嬉しいお知らせがあります。Payara 4.1.1.171 がリリースされました. これは 2017 年最初のリリースであり、以下のトピックを含む多数の機能が盛り込まれています。(リリース作業中にバグが発見され、その対応を実施したため、厳密なバージョン番号は 4.1.1.171.0.1 となっていますのでご注意ください) 詳細については リリースノート または Payara Blog を参照してください。

参考まで、次回リリース (Payara 4.1.1.172) は 2017 年 5 月頃を予定しています。

1. Notification Service の強化

Payara 4.1.1.164 から Notification Service が本実装されています。従前は server log に対してのみ通知を行う仕様でしたが、今回のリリースからは E-mail、JMS、SNMP、XMPP、HipChat、Slack、Payara Micro (CDI Event Bus) などで通知することも可能になりました。最近流行している Slack や HipChat にも対応しているのは珍しい例ではないでしょうか。

2. Payara Public API の整備

これまで Payara 独自の API を使用するには、Maven の依存関係設定で少々手間がかかりました。今回のリリースでは、Payara 独自 API (Payara Public API) の JAR ファイルが Maven Central に登録され、以前よりも設定が簡単になります。

3. Health Check Service の拡張

Health Check Service が管理コンソールと統合しました。また、Health Check エントリに履歴番号が付加されるよう改修もされています。

4. Payara Micro の拡張

Payara Micro はこれまでのリリースから大きく前進しています。コードベースは完全に書き直され、全体構造を把握しやすく、可読性も高まっています。

*Caution* もし Windows をお使いの場合は、プレリリース版の Payara Micro 4.1.1.171 は使わず、必ず正式版である Payara Micro 4.1.1.171.0.1 を使用してください。プリレレース版は少なくとも Windows 10 では動作しません (詳細は Issue#1396 参照のこと)。

5. コンポーネントのアップデート

  • Weld 2.4.1.Final
  • EclipseLink 2.6.4
  • Mojarra 2.2.14
  • Jackson 2.8.5
  • Jettison 1.3.8
  • Hazelcast 3.7.4
  • asm-commons 5.0.3
  • Grizzly 2.3.27 (*Downgraded*)

6. バグ修正

30 件を超えるバグ (GlassFish 由来の 6 件を含む) が修正済です。

7. セキュリティ・フィックス

セキュリティ・フィックスが実施されています。CVE-2013-2035, CVE-2016-0763, CVE-2016-3092, CVE-2016-3427 の各脆弱性に対する対応も行われています。

とりあえず、速報まで。

ぜひ、Payara 171 を使用してみてください!

p.s.

今回のリリースは、"Payara Server Long Term Support" が適用される最初のリリースです。Payara の商用サポートは進歩しています。もし、Payara を商用環境で運用するのであれば、Production Support に目を通すことをお勧めします (私の願いは、Payara のサポートを、日本でも簡単に受けられるような体制を整備することです。もし可能性があるのなら、現職を放棄してでも成し遂げたい目標でもあります)。

Payara 4.1.1.171 is now available

I'm happy to say that Payara 4.1.1.171 is released. This is the first release in 2017 and contains following changes. (The strict version of this release is 4.1.1.171.0.1 because of some bug fixes within a term of pre-release.) See the Release Notes or Payara Blog for detail.

Next release (Payara 4.1.1.172) is planned on May 2017.

1. Add many notifier for Notification Service

Since Payara 4.1.1.164, Notification Service notifies to only server log. Now it uses also E-mail, JMS, SNMP, XMPP, HipChat, Slack and Payara Micro (CDI Event Bus).

2. Payara Public API

We use Payara specific features called Payara Public API easier than previous releases. It seems that Maven dependency setting is simple.

3. Health Check Service enhancements

Add admin console integration for Health Check Service and store a number of historical measurements to Health Check entries.

4. Payara Micro enhancements

Payara Micro has growing up from previous release. The source code was rewritten completely and became more readable.

*Caution* If you use on Windows, never run Payara Micro 4.1.1.171 (pre-released) but Payara Micro 4.1.1.171.0.1 (formally released), see also Issue#1396.

5. Component upgrades

  • Weld 2.4.1.Final
  • EclipseLink 2.6.4
  • Mojarra 2.2.14
  • Jackson 2.8.5
  • Jettison 1.3.8
  • Hazelcast 3.7.4
  • asm-commons 5.0.3
  • Grizzly 2.3.27 (*Downgraded*)

6. Fixes many bugs

Over 30 bugs (includes 6 GlassFish origin bugs) are fixed.

7. Security fixes

Security fixes (includes adaption to CVE-2013-2035, CVE-2016-0763, CVE-2016-3092, CVE-2016-3427).

Enjoy, new Payara!

p.s.

This is the first release based on "Payara Server Long Term Support." Payara's production support become improved. If you use Payara on production systems, see information to Production Support. (I wish to spread Payara Support as an easy way for Japanese.)

Introduction to migrate GlassFish to Payara Server

Payara 4.1.1.171 will be released soon. (I think it's several days after.) All features are fixed and it seems to prepare for release now.

Well, recently some article was posted to Payara Blog. their are continuing series on alternatives for commercial Oracle GlassFish features, in other words, GlassFish 3.x w/commertial support to Payara Server migration.The series is following five articles at this time. See the detail if you're interested in.

  1. GlassFish to Payara Server Migration - Migrating away from the Load Balancer Configurator Plugin
  2. GlassFish to Payara Server Migration - Domain Administration Server Backup & Recovery
  3. GlassFish to Payara Server Migration: Hazelcast as a Coherence ActiveCache Alternative
  4. GlassFish to Payara Server Migration: Replacing the Monitoring Scripting Client
  5. GlassFish to Payara Server Migration - migrating away from the Oracle Access Manager integration

In general, almost commertial features of Oracle GlassFish 3.x can be replaced by Payara Server or tools in Operating Systems (e.g. cron), but some of them is difficult. (e.g. online backup of domain) Payara Team seems to plan to implement alternative features, so the situation may be better than now.

Payara is better and better each releases. At first, let's try to use Payara!

Payara Foundation web site opened

Payara Foundation is established and this web site opened a few days ago. Please visit to http://www.payara.org/ and know more about Payara Server and Payara Micro!

The site is the hub for all persons who are contributors, developers, users, evaluators, bloggers, etc. If you are unfamilier with Payara, I propose to visit Payara Foundation web site at first.

Payara Foundation is relies on Payara Community (http://www.payara.fish/) and development of Payara continues that. Payara Foundation describes to contribute Payara with practical steps, so it's clearly what we can do for Payara.

This year would be the special one for Payara. Payara changes more powerful both the production and the foundation. Let's contribute Payara for it's more progress!


It may unnecessary digression, Headquarter of Payara locations Malvern Hills Science Park, England. There is near by Worcester and very beautiful place around natural park. I wish to work such a work-site someday.

Payara Advent Calendar 2016 を振り返って

この記事は、Payara Advent Calendar 2016 の最終日です。昨日はひらおかゆみ (@yumix_h) の「Admin ConsoleのLog Viewer」です。

私ひとりで勝手に始めた Payara の Advent Calendar ですが、かずひらさん (@kazuhira_r)、うらがみさん (@backpaper0)、Wreulicke さん (@wreulicke)、多田さん (@suke_masa)、上妻さん (@n_agetsu) に助けられ、何とか最終日まで完走することができました。もちろん、無理を承知で助け船を出してくれたひらおかゆみ (@yumix_h) にも感謝しています。

2016 年の Payara も話題が盛りだくさんでした。私の担当分はその多くがマニュアルの内容を実際に試したものになりますが、それでも 3 週間分くらいの記事にはなりました。2 年前の GlassFish Advent Calendar 2014 では、当時既に開発が停滞しきっていた GlassFish をネタに Advent Calendar をやったため、毎回内容を考えるだけで相当苦労しましたが、Payara は現在進行形で成長しているため、GlassFish から引き継いだ機能からつい最近リリースされた新機能まで幅広い内容で記事を書くことができました。

私以外の方々からは以下の内容の記事をいただきました。

いずれも資料的価値の高い記事であるため、きっかけこそ Advent Calendar ですが、多くの方々におすすめしたい記事が揃いました。

Java EE 全体をみると、2016 年は Java EE 8 の開発一時停止、Oracle vs. Java EE Guardians、Java EE 8 のスケジュール & 内容の大幅な見直しと暗い話題が続きました (特に注目の MVC 1.0 があっさり drop したのは残念でした)。一方で、MicroProfile のようなコミュニティによる新しい取り組みもみられ、将来に向けてかすかな光が見え始めた年だと感じています。そうした中で PayaraMicroProfile に参画したのも、個人的には評価に値するものだと思っています。

世の中のサーバーサイド Java はもはや Spring 一色ですが、そうした状況下で Java EE の遺伝子を受け継ぐ Payara が今後より一層発展することを願ってやみません。


p.s. 来年、私の主催はかなわないかもしれませんが、誰かが何らかの形でこの Advent Calendar を引き継いでいただけるのであれば、2016 年の主催者としてこれほど嬉しいことはありません。

Payara Micro の GAV デプロイ

この記事は Payara Advent Calendar 2016 の 20 日目です。昨日は @backpaper0 さんの「PayaraをDockerで動かす」です。昨年の前半に Payara の Mike Croft (@croft) が中心となって進めていたプロジェクトの成果を日本語で確かめるよい機会です。Docker 環境をすぐに使用できる方は是非お試しください。

去る 12 月 3 日に開催された JJUG CCC 2016 Fall にて、「Payara Micro の設計と実装」と題した発表を行いました。その後のフィードバックで、Maven リポジトリ上の WAR ファイルを Payara Micro へ直接デプロイできることに驚かれた方も少なくなかったようなので、今回はごく簡単なサンプルを用いて、Maven リポジトリからのデプロイ (GAV デプロイ) についてお話ししようと思います。初回こそ Maven 環境を整えるという面倒な作業を要しますが、一度環境を整備すればその後は楽に作業を進められます。

1. 事前準備: WAR ファイルの作成とリポジトリへの登録

まずは WAR ファイルをアップロードする Maven リポジトリが必要です。Maven Central が使用できるのであれば、それを使用するのが最も簡単です。Maven Central へのアップロード方法については http://maven.apache.org/guides/mini/guide-central-repository-upload.html を参照してください。Maven Central は使用できないが独自にホスティング環境を持っている場合には、Sonatype Nexus で Maven リポジトリを構築すると良いでしょう。

私は Maven Central へのアップロード経験がなく、かの場所のワークフローも面倒に思えたので、VPS (ConoHa) を借りて Nexus をインストールしました (MSDN の Azure にも Nexus をホスティングしているのですが、通信量の制約が...)。

アップロードする WAR は、Payara Micro で動作するものであれば何でも良いです。GAV デプロイでも必要であれば複数の WAR をデプロイすることができます。ただし、Snapshot バージョンの場合は設定次第で苦戦するかもしれませんので、それを避けたければ Release バージョンをアップロードしましょう。

2. Payara Micro API を用いた GAV デプロイの実際

今回はとりあえず、JAX-RS で "Hello, world" を出力する WAR ファイルを作りました。コードは https://github.com/khasunuma/helloweb/tree/version-1.0 にあります (実際は HTML/XML/JSON の 3 出力形式に対応するとか、余計なことをしています)。この WAR ファイルは私がホスティングしている Nexus にアップロード済みです。

まずはコマンドラインから、以下のように実行してください。

java -jar payara-micro-4.1.1.164.jar --deployFromGAV jp.coppermine.samples:helloweb:1.0.0 --additionalRepository http://repo1.cubiwano.org/repository/maven-public

--deployFromGAV で WAR ファイルの groupId、artifactId および version を指定します。また、Maven Central 以外のリポジトリ (特に in-house リポジトリ) にある場合は、その URL (今回は http://repo1.haswell.jp/repository/maven-public) を指定します。これだけでデプロイはできるはずです。

【注意】 上記の Maven リポジトリ (repo1.cubiwano.org) は HTTP と HTTPS の両方に対応させていますが、GAV デプロイの際は "HTTP" を指定してください。

このサンプルの動作確認は、ブラウザで http://localhost:8080/helloweb/api/hello を開くことでできます。"Hello, world" が出力されていれば OK です。

Payara Micro API を使用する場合は、以下のようにコーディングします (完全なコードは https://github.com/khasunuma/payaramicro-gav にあります)。

package jp.copermine.samples.payaramicro;

import fish.payara.micro.BootstrapException;
import fish.payara.micro.PayaraMicro;

public class GavDeploy {

    public static void main(String[] args) throws BootstrapException {
        // Required if not using Maven central repository 
        final String repositoryUrl = "http://repo1.cubiwano.org/repository/maven-public";
        
        // groupId , artifactId , version
        // if version is SNAPSHOT, it may not run well
        final String gav = "jp.coppermine.samples,helloweb,1.0.0";
        
        PayaraMicro.getInstance().addRepoUrl(repositoryUrl).addDeployFromGAV(gav).setNoCluster(true).bootStrap();
    }

}

明日は @wreulicke さんです。

この記事は、Payara Advent Calendar 2016 の 16 日目です。昨日は「JavaFX から Payara Micro を呼び出す際の注意点」です。

Payara のクラスタリングには、GlassFish から引き継いだ Shoal を利用する方法と、Payara が独自に実装した Hazelcast を利用する方法の 2 種類があります。今回はその概要をご紹介します。

1. Shoal

GlassFish v2 の頃から開発されているクラスタウェアで、永続化ストアを一切使用しない完全なインメモリ・セッション・レプリケーションを実現した、当時としては画期的なものでした。技術的には Sun Java System Web Server 7.0 (後の Oracle iPlanet Web Server 7.0) と共通している部分もあるようです。Shoal の信頼性は非常に高く、故に GlassFish v3 系ではそれまでの HA 構成を廃止して Shoal クラスタに一本化してしまいました。もっとも、GlassFish v3 FCS には間に合わず、実際に搭載されたのは GlassFish 3.1 からとなります。

GlassFish 3.x のクラスタウェアは、Shoal の基本機能に加えて ssh/scp を利用したノードの自動構成をサポートしていました。この機能は、GlassFish の DAS (ドメイン管理サーバー) がリモート接続先のホストに自身のコピーを作成 (scp を使用) し、そこからノードを構成する (ssh を使用) というもので、DAS から自己増殖的にクラスタのノードを追加できる、他のサーバーでは例を見ないユニークな機能でした。この機能の先には、Java EE のマルチテナント機能があったと考えられ、実際に Java EE 7 で導入を試みた (結果として断念した) マルチテナント機能は、Shoal クラスタのこの機能に近いものだったと考えられます。

Shoal ではリモート接続先のホスト上にノードを構成する際、ssh を利用していました。しかし、Windows では ssh を標準搭載しておらず、別途インストールするハードルがあったため、DCOM で ssh/scp と同等の機能を実現しました。GlassFish では ssh/scp で構成されるノードを SSH ノード、DCOM で構成されるノードを DCOM ノードとして区別していました。また、DAS からのリモート接続を使用せず直接ホスト上に構成されたノードを CONFIG ノードと呼んでいました。制約として、同一クラスタ内での SSH ノードと DCOM ノードの共存は動作保証がなされておらず、また SSH ノードであっても OS が異なる (例: Linux と Solaris) と挙動がおかしくなることが多くありました。CONFIG ノードだけで構成すれば異なる OS のノードを混在させることは可能でしたが、それでは Shoal のメリットが半減してしまいます。

GlassFish 4.0 ではマルチテナント機能の搭載を前提としてロードバランサーを内包しましたが、結局マルチテナント機能は搭載されず、Shoal はロードバランサーとともに放置されるに至りました。現在、Shoal は目立ったメンテナンスが行われておらず、それが Payara で Hazelcast を導入した要因のひとつとなっています。Payara Server では GlassFish 4.1.x との互換性のため Shoal は残されていますが、Payara Micro には当初から搭載されていません。

2. Hazelcast

Hazelcast はインメモリ・データグリッドと呼ばれているミドルウェアの一製品です。同種の製品としては CoherenceInfinispanEhcache などが挙げられます。データグリッドとは、複数のマシンに分散している大量のデータを高速にアクセスする仕組みで、インメモリ・データグリッドは KVS (Key Value Store) のようなキャッシュの延長線上にある技術です。用途としてはローカル・キャッシュ、分散キャッシュ、クラスタ (複数ノード間のデータ共有)、データの分散配置および分散処理と多岐に及びます。

キャッシュとしては Coherence のケース・スタディが比較的分かりやすく、WebLogic Server クラスタと Oracle Database クラスタ (RAC) の間に Coherence が入ることで、WebLogic Server クラスタのデータベース・アクセス全体をキャッシュできるようになります (WebLogic Server は単体でも Oracle Database のクラスタと親和性が高くなっています)。

キャッシュとしての Hazelcast は、JCache (JSR 107) をサポートしつつも KVS の枠に囚われない様々なデータ型を分散配置することができます。クラスタとしての Hazelcast は高度なノード管理機能を持ち、スケールアウトが容易になるよう設計されています。様々なハードウェア と OS に対応し、Java 以外の言語 (C++、C#、Python、Node.js など) にも対応しています。

Payara は早い時期から Hazelcast を搭載しており、特に Payara Micro でマイクロサービスを構築する上で欠かせないものとなっています。また、Hazelcast が標準で JCache 実装を持つことから、Payara は Java EE 7 ベースでありながら JCache も使用可能なサーバーとなっています。

Hazelcast はクライアント・サーバー構成と埋め込み構成の双方をサポートしますが、Payara では埋め込み構成の Hazelcast をクラスタウェア (兼 JCache 実装) として使用します。Payara は埋め込み Hazelcast のインスタンスを生成することでクラスタのノードとなり (もしなければ自身が最初のノードとなってクラスタを構成)、インスタンスをシャットダウンすることでクラスタから外れます。実行中のクラスタに関することは基本的に Hazelcast が担当します。

Payara Server では既定で無効となっていますが、管理コンソールのチェックボックス 1 つで有効化できます。一方、Payara Micro では既定で有効となっており、互いに通信可能な Payara Micro のインスタンスが自動的にクラスタを構成するようになっています。同一クラスタ内に Payara Server と Payara Micro を混在させることも可能です。また、Shoal と異なり OS には依存しません。

3. どちらのクラスタリングを採用すべきか?

Payara で新規にクラスタを構築するのであれば、Hazelcast クラスタが第一選択肢となります。Shoal クラスタは GlassFish Server との互換性のために残されているに過ぎず、また Payara Micro ではサポートされていないためです。

Hazelcast クラスタでは、Shoal クラスタの CONFIG ノード相当しかサポートされませんが、実用上は問題ないでしょう。Shoal SSH/DCOM ノードよりも Hazelcast ノードの方が確実に構成できますし、特に Payara Micro の Uber Jar を使用するのであれば ssh/scp を用いたノード構成を比較的容易にスクリプトとして実行できるからです。


明日は「CLOVER を参照せよ」で有名 (?) な、かずひらさん (@kazuhira_r) の出番です。話題も Hazelcast 関連を予定しているとのこと。お楽しみに。

Payara の歩み (2016-12 版)

この記事は Payara Advent Calendar 2016 の 14 日目です。昨日は「Payara の JDBC サポート機能」です。

今回は、Payara の歴史について振り返ってみたいと思います。

Payara 4.1.144 (2014 年 12 月)

Payara Server 最初のリリースです。当時の Payara は GlassFish 4.x の商用サポート・プロジェクトであり、Payara 4.1.144 も GlassFish 4.1 のバグフィックス版という位置づけでした。

Payara 4.1.151 (2015 年 1 月)

Payara の独自色が姿を見せ始めたリリースです。JBatch に大きな機能拡張があり、従来は永続化マネージャーに Java DB (Apache Derby) のみ使用可能であったものが、MySQL、PostgreSQL、Oracle および DB2 にも対応するようになりました。また、現在の Payara に欠かすことのできない Hazelcast が初めて組み込まれたのも、このリリースです。GlassFish 4.1 で切り捨てられた多国語化対応も、このリリースから復活しています。

Payara 4.1.152 (2015 年 5 月)

Payara Micro はこのリリースで初めて登場しました。構成済みドメインとして GlassFish 4.1 互換の domain1 に加え、プロダクション用途に合わせてチューニングを施した payaradomain も同梱されるようになりました。ただし、起動時にドメインを省略できず、domain1 または payaradomain を明示しなければならない制約がありました。JDK 9 上で動作するようになったのもこのリリースからです。

Payara 4.1.152.1 (2015 年 5 月)

Payara 4.1.152 で管理コンソールに致命的なバグが発見されたため、緊急リリースされたものです。Payara で初めてのパッチリリースとなります。

Payara 4.1.153 (2015 年 7 月)

このリリースでは、Payara Micro に大幅な拡張が施され、API が整備されました。PayaraMicroRuntime クラスや HTTP Auto-binding もこの時に導入されています。また、Payara Blue と呼ばれる、IBM AIX 向けの Payara Server と Payara Micro がラインナップに加わりました。payaradomain 導入によってドメインを省略できなくなった問題についても、ドメイン省略時には domain1 が自動的に選択されるように修正されました。私が管理コンソールの Hazelcast 設定画面を日本語化して Contributor となったのがこのリリースです。

Payara 4.1.1.154 (2015 年 11 月)

このリリースからベースラインが GlassFish 4.1.1 となりました。コンポーネントも GlassFish 4.1.1 と同期するように見直されています。このリリースの新機能として、ログのローテーションを Off にする機能が追加されています。

Payara 4.1.1.161 (2016 年 2 月)

このリリースから、管理コンソールの配色が Payara 独自の、紺色をベースとしたものに変わりました。新機能として、CPU や VM などの状態を監視して結果をログに出力する Health Check Service が追加されました。Health Check Service の実装を皮切りに、Payara は商用サーバーにふさわしい本格的な監視機能を整備し始めることになります。

Payara 4.1.1.161.1 (2016 年 2 月)

Payara 4.1.1.161 の Metro 周りのバグを修正した緊急のパッチリリースです。

Payara 4.1.1.162 (2016 年 5 月)

このリリースと時を同じくして、GitBook ベースの新しいドキュメントが公開されました。Payara 全体としては使用状況をレポートする Phone Home が追加されました。また、Payara Micro では Uber Jar や Maven リポジトリからのデプロイ (GAV deploy) が導入され、マイクロサービスのプラットフォームとしての機能を強化しています。

Payara 4.1.1.163 (2016 年 8 月)

このリリースでは、新たに 2 つの監視機能、Notification Service と Request Tracing Service が追加されました。Request Tracing Service はこのリリースではプレビュー版の位置づけでした。

Payara 4.1.1.164 (2016 年 12 月)

このリリースでは管理コンソールの Hazelcast 設定画面が再構成され、新たに Hazelcast クラスタ・メンバーの一覧を表示できるようになりました。また、ログ出力形式として ULF (Sun GlassFish v3)、ODL (Oracle Fusion Middleware/GlassFish 4) に加え JSON を選択できるようになりました。Payara 4.1.1.163 ではプレビュー版の扱いだった Request Tracing Service は正式版となりました。Payara Micro 独自の機能としては、Uber Jar とそうでない場合でコンテキスト・ルートの設定基準に差異があったものが、Uber Jar 側の基準に統一されました。

Payara 4.1.1.171 (2017 年 第一四半期)

Coming soon... 期待しましょう!

Payara のログ・ビューワの制限事項

先日公開した「Payara の JSON Log Formatter」の時点では黙っていましたが、Payara のログ出力形式を JSON にした場合には管理コンソールのログ・ビューワで参照することができません。バグかもしれないが詳細まで調べていないからしばらく黙っていようと思ったら、@yumix_h早速 Issue Tracker で報告したので、こちらでの調査結果を踏まえて報告しておきます。なお、この件は私の調査と Mike Croft (@croft) の判断により、Enhacement として Payara の internal issue になったことを補足しておきます。

この Issue にはタグ "2:WithDev" (Payara 社内持ち帰り)、"c:Enhancement" (機能追加) および "reproducible" (再現可能) が付いています。タグの意味については先日の記事「Payara Issue Tracker のラベル一覧」にまとめていますので参考にしてください。

Payara 本体のロギングには java.util.logging (JUL) を使用しており、ロガーの設定はプロパティ・ファイル logging.properties の内容に記述されています。管理コンソールの「ロガーの設定」画面の操作で変更されるファイルは、domain.xml ではなく logging.properties です。

logging.properties は以下のディレクトリに格納されます:
Payara_installed_directory/glassfish/domains/domain_name/config

管理コンソールの「ロガーの設定」には、「コンソールのロギング・フォーマット」と「ログ・ファイルのロギング・フォーマット」の 2 項目があり、それぞれログ・ハンドラに対応しています。具体的には以下の通りです。

管理コンソールのプルダウン・リストの選択肢である「ULF」、「ODL」および「JSON」は、上記のログ・ハンドラに設定するログ・フォーマッタに対応しています。具体的には以下の通りです。

この他にも、logging.properties を直接操作することにより、任意のログ・フォーマッタを指定することができます。Payara 内部 (具体的には GFFileHandler) では、ULF または ODL ではない形式のログ・フォーマッタを Custom formatter と呼称しています。 Custom formatter にはいくつかの制約があります。

  • 管理コンソールなどでロガーの設定を変更すると GlassFish/Payara の既定値である ULF に再設定される場合がある。
  • 管理コンソールのログ・ビューワでは参照できず、Raw ログ・ビューワを使用する必要がある。これは、ログ・ビューワは標準のログ・フォーマッタのみ対応しているため。

IMPORTANT : Payara 4.1.1.164 では、標準のログ・フォーマッタは UnformLogFormatter および ODLLogFormatter の 2 種類だけです。そのため、JSONLogFormatter は実際には Custom formatter として扱われます。そのため、Custom formatter が出力する JSON 形式のログを管理コンソールのログ・ビューワから参照することはできません (代わりに Raw ログ・ビューワを使用すること)。

ログ・ビューワに対応させるためには、当該ログ出力形式に対応した LogParser の実装や、ログ・ビューワの Backing Bean (※管理コンソールは JavaServer Faces 1.x/2.x で実装されています) の改修などが必要となります。しかし、現在の実装では JSONLogFormatter の追加と、管理コンソールから「JSON」 = JSONLogFormatter を選択可能にする改修を加えただけに過ぎません。

Payara でも管理コンソールのログ・ビューワを JSON 形式のログにも対応させる案について検討に入りましたので、将来のリリースでは管理コンソール上からログ・ビューワを使用して JSON 形式のログを参照できるようになるかもしれません。

Payara の JDBC サポート機能

この記事は Payara Advent Calendar 2016 の 13 日目です。昨日は「Payara の JSON Log Formatter」です。

Payara 4.1.1.161 以降、JDBC 周りの管理・監視機能が強化されました。ベースとなった GlassFish 自身、本格的な実装を備えていましたが、Payara では商用サーバーに必要と考えられる追加機能をさらに実装しています。SQL サポート機能は、管理コンソールから設定を変更することができます。

1. Slow SQL Logging

Slow SQL Logging は、SQL の実行時間がある閾値を超えた場合に、その情報をログに出力するための機能です。データソース定義で Statement Timeout (fish.payara.slow-query-threshold-in-seconds プロパティ) に閾値を設定することで有効になります。既定値は -1 で、この値は Slow SQL Logging を無効化することを意味します。

Slow SQL Logging を有効化した場合、閾値を超えた SQL について、以下のようなログが出力されます。

[#|2016-02-01T22:39:29.289+0000|WARNING|Payara 4.1|javax.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=61;_ThreadName=http-listener-1(2);_TimeMillis=1454366369289;_LevelValue=900;|
  SQL Query Exceeded Threshold Time: 5000(ms): Time Taken: 10000(ms)
Query was SELECT ID, AGE, BIO, BIRTHDATE, BIRTHDAY, DATEFORMAT, DATEOFBIRTH, DATEOFHIRE, EMAIL, HIREDATE, HIREDAY, MEMBERAGE, NAME, TODAYSDATE FROM MEMBERENTITY WHERE (NAME = ?);

java.lang.Exception: Stack Trace shows code path to SQL
    at fish.payara.jdbc.SlowSQLLogger.sqlTrace(SlowSQLLogger.java:123)
    at com.sun.gjc.util.SQLTraceDelegator.sqlTrace(SQLTraceDelegator.java:122)
    at com.sun.gjc.spi.jdbc40.ProfiledConnectionWrapper40$1.invoke(ProfiledConnectionWrapper40.java:448)
    at com.sun.proxy.$Proxy265.executeQuery(Unknown Source)
    at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:1009)
    at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:644)
    at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:560)
    at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:2055)
    at org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:570)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:242)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:228)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:299)
    at org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.selectAllRows(DatasourceCallQueryMechanism.java:694)
    at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRowsFromTable(ExpressionQueryMechanism.java:2740)
    at org.eclipse.persistence.internal.queries.ExpressionQueryMechanism.selectAllRows(ExpressionQueryMechanism.java:2693)
    at org.eclipse.persistence.queries.ReadAllQuery.executeObjectLevelReadQuery(ReadAllQuery.java:559)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeDatabaseQuery(ObjectLevelReadQuery.java:1175)
    at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:904)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:1134)
    at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:460)
    at org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1222)
    at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2896)
    at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1857)
    at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1839)
    at org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1804)
    at org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:258)
    at org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:473)
    at fish.payara.team.info.controllers.MemberSessionBean.getTeamMemberByName(MemberSessionBean.java:35)

(See also) https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/advanced-jdbc/slow-sql-logger.html

2. Full JDBC Tracing (Log JDBC Calling)

Full JDBC Tracing (Log JDBC Calling) は、JDBC (あるいは JPA) がどのようなメソッドを呼び出したのかをログに記録する機能です。内部で何をやっているのか把握しづらい JPA のデバッグなどに有効でしょう。

Full JDBC Tracing は規定では無効です。有効化する場合には、管理コンソールのデータベース設定で Log JDBC Calls に Enabled のチェックを入れる (fish.payara.log-jdbc-calls プロパティを true に設定する) 必要があります。

Full JDBC Tracing が出力するログは以下のようになります。

[#|2016-02-04T18:51:01.467+0000|FINE|Payara 4.1|javax.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=35;_ThreadName=http-listener-1(5);_TimeMillis=1454611861467;_LevelValue=500;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace;|
  PoolName=DerbyPool | ExecutionTime=1ms | ClassName=org.apache.derby.client.net.NetConnection40 | MethodName=prepareStatement | arg[0]=SELECT ID, AGE, BIO, BIRTHDATE, BIRTHDAY, DATEFORMAT, DATEOFBIRTH, DATEOFHIRE, EMAIL, HIREDATE, HIREDAY, MEMBERAGE, NAME, TODAYSDATE FROM MEMBERENTITY WHERE (NAME = ?) | arg[1]=1003 | arg[2]=1007 | |#]

[#|2016-02-04T18:51:01.467+0000|FINE|Payara 4.1|javax.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=35;_ThreadName=http-listener-1(5);_TimeMillis=1454611861467;_LevelValue=500;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace;|
  PoolName=DerbyPool | ExecutionTime=0ms | ClassName=com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40 | MethodName=setString | arg[0]=1 | arg[1]=test | |#]

[#|2016-02-04T18:51:01.468+0000|FINE|Payara 4.1|javax.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=35;_ThreadName=http-listener-1(5);_TimeMillis=1454611861468;_LevelValue=500;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace;|
  PoolName=DerbyPool | ExecutionTime=1ms | ClassName=com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40 | MethodName=executeQuery | |#]

[#|2016-02-04T18:51:01.483+0000|FINE|Payara 4.1|javax.enterprise.resource.sqltrace.com.sun.gjc.util|_ThreadID=35;_ThreadName=http-listener-1(5);_TimeMillis=1454611861483;_LevelValue=500;ClassName=com.sun.gjc.util.SQLTraceLogger;MethodName=sqlTrace;|
  PoolName=DerbyPool | ExecutionTime=0ms | ClassName=com.sun.gjc.spi.jdbc40.PreparedStatementWrapper40 | MethodName=close | |#]

(See also) https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/advanced-jdbc/log-jdbc-calls.html

3. SQL Trace Listener

SQL Trace Listener は、JDBC (SQL) 監視を独自実装したい場合に使用します。詳細はマニュアルを参照してください。

https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/advanced-jdbc/sql-trace-listeners.html

4. Payara Micro でのサポート状況

今回ご紹介した機能は、Payara Server を主眼に置いていますが、Payara Micro でも使用できます。


2016-12-13 補足: See also http://www.coppermine.jp/docs/promised/2016/12/payara-logviewer-restriction.html

Payara の JSON Log Formatter

この記事は Payara Advent Calendar 2016 の 12 日目です。昨日は「Payara Issue Tracker のラベル一覧」です。

Payara 4.1.1.164 から、Payara のログを JSON 形式で出力できるようになりました。Payara には当初から GlassFish から引き継いだ 2 種類のログ出力形式―ULF (Unified Logging Format : Sun のミドルウェアで使用されていた形式) および ODL (Oracle Diagnostic Logging : Oracle Fusion Middleware で採用されている形式)―が備わっていましたが、最新リリースで新たに第 3 の形式である JSON が加わったことになります。

1. JSON Log Formatter を有効にする

ログ形式の変更は管理コンソールを用いるとプルダウンリストだけで操作できます。asadmin でも変更は可能ですが、コマンド記述が少々長くなります。この記事では管理コンソールでのログ形式変更について取り上げます。まずは figure 1 を参照してください。

logger-settings.png
figure 1 - ロガーの設定画面

ロガーの設定で、ログ形式の種類を選択することができます。ログの種類は ULF、ODL、さらに Payara 4.1.1.164 からは JSON の中から選択します。コンソールとログ・ファイルでそれぞれ別の形式を選択することも可能です。実際に Payara の既定値はコンソールが ULF 形式、ログ・ファイルが ODL 形式となっています。この例では、ログ・ファイルのログ形式を ODL から JSON に変更しています。

2. JSON ログ形式

Payara 4.1.1.163 までの既定値である ODL 形式のログ・ファイルは以下のようになります。

[2016-12-01T10:26:42.428+0900] [Payara 4.1] [INFO] [NCLS-LOGGING-00009] [javax.enterprise.logging] [tid: _ThreadID=17 _ThreadName=RunLevelControllerThread-1480555602091] [timeMillis: 1480555602428] [levelValue: 800] [[
  Running Payara Version: Payara Server  4.1.1.164 #badassfish (build 28)]]

コンソール出力の既定値であり、GlassFish v3 の出力形式であった ULF 形式のログファイルは以下のようになります。

[#|2016-12-02T15:37:59.788+0900|INFO|Payara 4.1|javax.enterprise.logging|_ThreadID=17;_ThreadName=RunLevelControllerThread-1480660679551;_TimeMillis=1480660679788;_LevelValue=800;_MessageID=NCLS-LOGGING-00009;|
  Running Payara Version: Payara Server  4.1.1.164 #badassfish (build 28)|#]

Payara 4.1.1.164 で追加された JSON 形式のログ・ファイルは以下のようになります。

{"_Timestamp":"2016-12-02T14:22:40.237+0900","_Level":"INFO","_Version":"Payara 4.1","_LoggerName":"javax.enterprise.logging","_ThreadID":"17","_ThreadName":"RunLevelControllerThread-1480656159958","_TimeMillis":"1480656160237","_LevelValue":"800","_MessageID":"NCLS-LOGGING-00009","_LogMessage":"Running Payara Version: Payara Server  4.1.1.164 #badassfish (build 28)"}

JSON 形式のログは他の形式と比較して煩雑になりますが、JSON パーサーを使用して解析することができるため、ログ・データの再利用を行う上では有利になります。

Payara Issue Tracker のラベル一覧

この記事は、Payara Advent Calendar 2016 の 11 日目です。昨日は「Payara の Phone Home」です。

Payara は GitHub 上で開発されている OSS ですが、TwitterFacebookLinkedIn および YouTube にそれぞれアカウントを持っており、これら SNS も重視しています。とは言うものの、Payara の不具合や改善要望を直接 Payara Team に伝えるには、GitHub の Issue Tracker を使うのが良いでしょう。Payara の Issue Tracker は https://github.com/payara/Payara/issues になります。

今回は、Issue Tracker で使われているラベルとその意味・使われ方について、一覧形式でまとめます。ラベルは Payara Team が付けるものですが、ユーザーからもそれぞれの Issue が現在どのような状態にあるかを知る手がかりになります。

ラベル説明
0:Triaged 分類済み
1:Investigating 調査中
1:Wait 報告者からの応答待ち
2:WithDev Payara 社内持ち帰り
3:DevInProgress 開発中 ※Pull Request に付けられる
Awaiting CLA CLA 待ち ※Pull Request に付けられる
c:ConfirmedBug バグ
c:Enhancement 機能追加など
c:Misconfiguration 設定ミス
c:PossibleBug バグの可能性あり
c:Question 質問
c:Task タスク
cannot reproduce 事象が再現しない
CLA CLA 済み ※Pull Request に付けられる
documentation ドキュメント関連
duplicate 他の Issue と重複
enhancement 機能追加など ※現在は c:Enhancement
help wanted ヘルプが必要
Insufficient Detail 提供された情報だけでは不十分
payara-micro Payara Micro 関連
payara bug Payara 固有のバグ (GlassFish は無関係)
question 質問 ※現在は c:Question
ready 開発完了 ※Pull Request に付けられる
reproducible 事象が再現した
requestor unresponsive (1) 報告者からしばらく応答がない
requestor unresponsive (2) 報告者から長い間応答がない
Test Case Required テストケースを要求する
try to reproduce 事象の再現待ち
upstream bug GlassFish のバグ
wontfix 修正しない

ラベルには単独でも付けられるものと、そうでないものがあります。例えば、"Triaged" は単独で付けられることはなく、必ず分類を表すラベル (主に "c:ConfirmBug"、"c:Enhancement"、"c:Miscnofiguration"、"c:PossibleBug"、"c:Question"、"c:Task") とあわせて使われます。

いくつかのラベルはワークフローとして使われます。以下に例を挙げます。

  • Pull Request → "InDevProgress" → CLA なし → "Awaiting CLA" → CLA 完了 → "CLA" → マージ完了 → "ready"
  • Issue に対して Payara Team が回答 & 応答待ち → "Wait" → しばらく応答なし → "requestor unresponsive (1)" → 長い間応答なし → "requestor unresponsive (2)" → さらに応答なし → Issue 打ち切り&クローズ

なお、クローズ済みの古い Issue には、以上のラベル分類に必ずしも従っていない、あるいはラベルが全く付けられていないものもあります。それらについてはラベルが現在の形に整備される前であったためと割り切ってください。

Payara の Phone Home

この記事は、Payara Advent Calendar 2016 の 10 日目です。昨日は「Payara の Asadmin Recorder を活用する」です。

Payara 4.1.1.162 より、Phone Home という機能が追加されました。これはユーザーの Payara 使用状況を Payara に送信し、今後の計画に役立てることを目的としています。

実際に Phone Home を行っている fish.payara.nucleus.phonehome.PhoneHomeTask クラスを見れば一目瞭然なのですが、送信している項目は、以下の通りです。

Phone Home で送信する項目
keyvalue
ver Payara のバーション
jvm JVM のバージョン
uptime Payara を起動してからの経過時間
nodes ノード数
servers サーバー数

これらの情報を Payara 起動時に取得し、http://www.payara.fish/phonehome へ送信する仕組みとなっています。具体的にどのような値が送信されるかについては、全部ではありませんが取得するサンプルを作成しましたので、よろしければ参考にしてください。

https://github.com/khasunuma/phonehomedata

Phone Home を無効にする方法

Phone Home は初期状態で有効となっています。Phone Home 自体はユーザー個人を特定するような情報を送信しませんが、それでも何かしら情報が送信されるのは嫌だ、という方は、以下のいずれかで Phone Home を停止することができます。

方法 1: Phone Home のモジュール自体を削除する

Payara が停止している状態で、payara41/glassfish/modules/phonehome-bootstrap.jar を削除してください。Payara のモジュラー・システムのロード対象外となり、Phone Home が動作しなくなります。おそらく、これが究極的な対処法になると思われます。

方法 2: asadmin で Phone Home を無効化する

ドメインが起動している状態で、以下のコマンドを実行してください。

asadmin disable-phone-home

これで、次回以降の起動時には Phone Home は働きません。

方法 3: doman.xml で Phone Home を無効化する

domain.xml (既定では payara41/bin/glassfish/domains/domain1/config 以下にある) を直接更新する方法で対処可能です。くれぐれも domain.xml を壊さないよう、注意してください。

まず domain.xml から <config name="server-config"> 要素を探しだし、子要素として <phone-home-runtime-configuration enabled="false"/> を追加します。その後、ドメインを再起動すれば Phone Home は無効化されます。

補足

Phone Home は非常に小さなプログラムです。HTTP 経由で Payara のサーバーに情報を送信するのですが、Proxy に関する考慮などが全くなされていません。そのため、Proxy により外部へのデータ送信が規制されている場合には、Phone Home は動作しません (接続できずタイムアウトになります)。特に Proxy に BASIC 認証を設定している場合 (SIer でよく行われている設定ですが...個人的には無意味だと思うのですよね。元ネタは IPA のセキュリティ関係の資料なのですが、通読した限りでは結構いい加減なことを書いていたので) には絶対に送信できません。

Payara Micro に関する補足

Payara Micro にも Phone Home は実装されています。初期状態で有効となっている点も Payara Server と同じです。ただし設定方法は異なります (例えば、モジュール削除は使えません)。詳細は Payara Micro のマニュアル (コマンドライン・オプション) を参照してください。

Payara の Asadmin Recorder を活用する

この記事は、Payara Advent Calendar 2016 の 9 日目です。昨日は「Payara の Request Tracing Service」です。今回は Asadmin Recorder について、復習も兼ねて取り上げてみたいと思います。

1. Asadmin Recorder とは

Asadmin Recorder は、Payara の管理コンソール上で行った動作を asadmin コマンドで実行可能なスクリプトとして記録する機能です。

Payara 4.1.1.162 以降で管理コンソールを開くと、右上に「Enable Asadmin Recorder」というボタンが追加されていると思います (figure 1)。

enable-asadmin-recorder.png
figure 1 - Enable Asadmin Recorder ボタン

このボタンをクリックすると、それ以降の管理コンソール上の操作がファイル (既定では payara41/glassfish/domains/domain1/asadmin-commands.txt) に記録されてゆきます。再度ボタンをクリックすると記録を停止します。

生成されたスクリプト (ここでは既定の asadmin-commands.txt とします) は標準出力からパイプで asadmin に渡すことでそのままスクリプトとして使用することができます。

(Linux/Unix/Mac) $ cat asadmin-commands.txt | asadmin

(Windows) > type asadmin-commands.txt | asadmin

Asadmin Recorder によって、例えば WebLogic Server が装備している WLST のような使い方が可能になります (スクリプトに制御構文がないため WLST のような柔軟性はありませんが)。

2. asadmin コマンドについて

asadmin は Payara の起動に使用するコマンドです。ただし、他の Java EE サーバー製品が単なる起動スクリプトであるのに対し、asadmin は CLI の管理ユーティリティーである点が異なります。

Payara の管理は、究極的には asadmin と REST backend の 2 通りしか用意されていません。管理コンソールもその実体は REST backend のフロントエンドとして動作する Web アプリケーションです。

asadmin は Payara のすべてを操作することが可能ですが、REST backend ではいくつかの操作が行えません。具体的には、DAS の起動は REST backend では実行できない操作です。

asadmin にはシングルモードとマルチモードという、2 種類の動作モードがあります。

(1) シングルモード

asadmin の基本となるモードです。

# asadmin サブコマンド名 [パラメーター]

パラメーターはサブコマンドによって異なります(サブコマンドによってはパラメーターがない場合もあります)。

(2) マルチモード

複数のサブコマンドを続けて入力することができるモードです。「asadmin」とだけ入力するとマルチモードになります。その後はプロンプト「asadmin>」に続いてサブコマンドを次々と入力してゆきます。すべてが終わったら「exit」コマンドでマルチモードを終了します。

# asadmin
Use "exit" to exit and "help" for online help.
asadmin> サブコマンド名 [パラメーター]
...
asadmin> exit

マルチモードでは、実行したいサブコマンドのリストをファイルとして作成しておくことで、サブコマンドのバッチ実行が可能になります。

# cat サブコマンド一覧ファイル | asadmin

Asadmin Recorder で生成されたスクリプトの実行も、マルチモードを利用します。

3. Asadmin Recorder を使う

それでは、実際に Asadmin Recorder を使用してみます。まずは Asadmin Recorder を有効化 (figure 1) し、操作記録を開始します。

step1-enable-asadmin-recorder.png
figure 1 - Asadmin Recorder の有効化

続いて、サンプル操作として Hazelcast を有効化してみます (figure 2)。

step2-enable-hazelcast.png
figure 2 - Hazelcast の有効化

もう一つのサンプル操作として、ログ出力形式を既定値の ODL から新しく追加された JSON に変更してみましょう (JSON Log Formatter については後日ご紹介します)。

step3-set-logger-to-json.png
figure 3 - ログ出力形式の変更 (ODL から JSON に変更)

最後に Asadmin Recorder を無効化し、ここまでの操作を記録したスクリプトを生成します。

step4-disable-asadmin-recorder.png
figure 4 - Asadmin Recorder の無効化

ここまでの操作を記録した asadmin-commands.txt の内容は以下の通りです。

set-hazelcast-configuration --startPort=5900 --licenseKey= --hazelcastConfigurationFile=hazelcast-config.xml --clusterName=development --clusterPassword=D3v3l0pm3nt --dynamic=true --multicastPort=54327 --enabled=true --multicastGroup=224.2.2.3 --jndiName=payara/Hazelcast --target=server 
set-log-attributes --target=server-config java.util.logging.FileHandler.pattern='%h/java%u.log'
set-log-attributes --target=server-config java.util.logging.FileHandler.count='1'
set-log-attributes --target=server-config java.util.logging.FileHandler.formatter='java.util.logging.XMLFormatter'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.rotationTimelimitInMinutes='0'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.excludeFields=''
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.compressOnRotation='false'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.multiLineMode='true'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.retainErrorsStasticsForHours='0'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.rotationOnDateChange='false'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.formatter='fish.payara.enterprise.server.logging.JSONLogFormatter'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.maxHistoryFiles='0'
set-log-attributes --target=server-config handlerServices='com.sun.enterprise.server.logging.GFFileHandler,com.sun.enterprise.server.logging.SyslogHandler'
set-log-attributes --target=server-config java.util.logging.FileHandler.limit='50000'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.file='${com.sun.aas.instanceRoot}/logs/server.log'
set-log-attributes --target=server-config handlers='java.util.logging.ConsoleHandler'
set-log-attributes --target=server-config java.util.logging.ConsoleHandler.formatter='com.sun.enterprise.server.logging.UniformLogFormatter'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.flushFrequency='1'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.logtoConsole='false'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.SyslogHandler.useSystemLogging='false'
set-log-attributes --target=server-config log4j.logger.org.hibernate.validator.util.Version='warn'
set-log-attributes --target=server-config com.sun.enterprise.server.logging.GFFileHandler.rotationLimitInBytes='2000000'

4. Asadmin Recorder の活用方法

Payara Server の設定の多くは、管理コンソールで行うのが簡単です。しかし、複数の Payara Server で同一の設定をしなければいけない場合 (クラスタ構成を採る場合など)、すべてのノードに対して管理コンソールで設定を行うのは面倒です。そこで、Asadmin Recorder を有効にして基準となるサーバーの設定を管理コンソールで行い、他のサーバーの設定を出力されたスクリプトでバッチ実行すると、設定に関わる時間を大幅に短縮することができます。

あるいは、Payara Server の設定内容を Asadmin Recorder で記録しておき、障害発生時のリストア作業に用いる方法も考えられます。こちらもバッチ処理で設定が行えるため、リストアにかかる時間を短縮することが可能です。

Payara の Request Tracing Service

この記事は、Payara Advent Calendar 2016 の 8 日目です。昨日は「Payara の Notification Service」です。

前々回から Payara が持つ監視機能についてご紹介しており、今回がその最終回となります。Payara には現在、以下の 3 種類の監視機能が備わっています。

  • Health Check Service
  • Nortification Service
  • Request Tracing Service

今回は Request Tracing Service について取り上げます。

1. Request Tracing Service とは

Request Tracing Service は、Payara の HTTP 通信を監視して、一定の閾値を超えているものを server.log へ出力するための機能です。Payara が持つ 3 種類の監視機能では最も新しく、プレビュー版が Payara 4.1.1.163 で導入され、Payara 4.1.1.164 から正式版となりました。

Request Tracing Service の監視対象は HTTP 通信が関わるあらゆるサービスで、具体的には以下のものが該当します。

  • REST (JAX-RS エンドポイント)
  • Servlet (HTTP リクエスト処理)
  • SOAP Web サービス・リクエスト
  • WebSocket
  • EJB タイマーの実行
  • Message-Driven Bean (MDB) が処理するインバウンドの JMS メッセージ
  • JBatch ジョブの作成
  • Managed Executor による新しいタスクの実行

Request Tracing Service は監視範囲が広く大きな効果が得られる一方で、Payara への負荷も高くなります。Health Check Service や Notification Service のように常時有効化することは想定されておらず、トラブルシューティングのための監視機能と割り切って使用した方が良いでしょう。

2. Request Tracing Service の設定

2.1. Request Tracing Service の有効化/無効化

Request Tracing Service は既定で無効となっています。有効化するには管理コンソールまたは asadmin コマンドを使用します。

最も簡単な方法として、管理コンソールの Request Tracing Configuration 画面 (figure 1) から機能を有効化できます。チェックボックス 1 箇所の設定であるため、非常に簡単です。

Request Tracing Configuration.png
figure 1 - Request Tracing Configuration 画面

asadmin コマンドの場合は、requesttracing-configure サブコマンドを使用します。以下に例を示します。

$ asadmin requesttracing-configure --enabled=true --thresholdValue=30 --thresholdUnit="SECONDS" --dynamic=true

--thresholdValue と --thresholdUnit で閾値を指定します。この例では 30 秒を閾値としています。なお、これらの値は requesttracing-configure の既定値です。--dynamic=true は設定の即時反映を行うためのオプションです。

無効化する場合は、管理コンソールでチェックボックスを外すか、以下のコマンドを実行します。

$ asadmin requesttracing-configure --enabled=false --dynamic=true

2. Request Tracing Service の実際

Request Tracing Service は、既に Payara が実装している SQL トレース機能 (Slow SQL Logger) に続くトレース機能です。閾値を超える HTTP 通信が発生すると、その内容を server.log へ出力します。

Request Tracing Service の特徴のひとつとして、ログに出力するトレース情報が JSON 形式となっている点が上げられます。下記に Payara Blog に掲載されているログ出力例を転載します。全体が JSON 形式となっているわけではないため多少の加工は必要ですが、トレース情報を分析する上で有利に働きます。

[2016-09-01T13:02:13.456+0200] [Payara 4.1] [INFO] [] [fish.payara.nucleus.notification.service.LogNotifierService] [tid: _ThreadID=100 _ThreadName=http-thread-pool(5)] [timeMillis: 1472727733456] [levelValue: 800] [[
  Request execution time: 6286(ms) exceeded the acceptable threshold - {"RequestTrace": {"startTime":"1472727727170","elapsedTime":"6286",
"TraceEvent": {"eventType": "TRACE_START","eventName":"StartTrace","id=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727170","Server": "server","Domain": "domain1","traceTime=":"0"},
"TraceEvent": {"eventType": "REQUEST_EVENT","eventName":"RESTWSRequest","id=":"a85caaf3-34eb-4c99-bc8d-3aded9acac4d","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727171","accept-language": "[en-US,en;q=0.5]","cookie": "[__utma=111872281.148356872.1462355409.1471938946.1472580408.6; __utmz=111872281.1462355409.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); JSESSIONID=50143d92a74d317aaeb825691234; treeForm_tree-hi=treeForm:tree:configurations:server-config:notification; __utmc=111872281]","host": "[localhost:8080]","connection": "[keep-alive]","Method": "GET","URL": "http://localhost:8080/SimpleWAR/rest/request","accept-encoding": "[gzip, deflate]","user-agent": "[Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0]","accept": "[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8]","traceTime=":"1"},
"TraceEvent": {"eventType": "REQUEST_EVENT","eventName":"EJBMethod-ENTER","id=":"322fd38a-cf4e-44e6-a361-cea077c24526","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727415","EJBMethod": "execute","ComponentType": "STATELESS_SESSION_BEAN","ApplicationName": "null","ModuleName": "SimpleWAR","ComponentName": "DemoEJB","EJBClass": "demo.requesttracing.DemoEJB","TX-ID": "JavaEETransactionImpl: txId=402 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@7a4d066a]","CallerPrincipal": "ANONYMOUS","traceTime=":"245"},
"TraceEvent": {"eventType": "REQUEST_EVENT","eventName":"EJBMethod-EXIT","id=":"68f391db-493d-4d01-bcd8-20e1797beee3","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727416","EJBMethod": "execute","ComponentType": "STATELESS_SESSION_BEAN","ApplicationName": "null","ModuleName": "SimpleWAR","ComponentName": "DemoEJB","EJBClass": "demo.requesttracing.DemoEJB","TX-ID": "JavaEETransactionImpl: txId=402 nonXAResource=null jtsTx=null localTxStatus=0 syncs=[com.sun.ejb.containers.ContainerSynchronization@7a4d066a]","CallerPrincipal": "ANONYMOUS","traceTime=":"246"},
"TraceEvent": {"eventType": "REQUEST_EVENT","eventName":"InterceptedCdiRequest-ENTER","id=":"c0ab2f7a-ca37-4dfd-82de-27a07117b525","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727452","MethodName": "execute","TargetClass": "demo.requesttracing.DemoTrackedCDI$Proxy$_$$_WeldSubclass","traceTime=":"282"},
"TraceEvent": {"eventType": "REQUEST_EVENT","eventName":"InterceptedCdiRequest-EXIT","id=":"ae52efcd-761a-4d5a-971d-f704169c66a6","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727727453","MethodName": "execute","TargetClass": "demo.requesttracing.DemoTrackedCDI$Proxy$_$$_WeldSubclass","traceTime=":"283"},
"TraceEvent": {"eventType": "TRACE_END","eventName":"TraceEnd","id=":"288a524c-3d4f-492c-beda-c3accf5d502c","conversationId=":"dc0d27e5-d8eb-41cc-9b7f-89a230b0dfa4","timestamp=":"1472727733456","traceTime=":"6286"}}}]]

Payara Blog には Payara 4.1.1.163 のプレビュー版ベースですが Request Tracing Service の詳細が掲載されています。より深く知りたい場合は是非ご覧ください。

Payara の Notification Service

この記事は、Payara Advent Calendar 2016 の 7 日目です。昨日は「Payara の Health Check Service」です。

前回に引き続き Payara が持つ監視機能についてご紹介します。Payara には現在、以下の 3 種類の監視機能が備わっています。

  • Health Check Service
  • Nortification Service
  • Request Tracing Service

今回は Nortification Service について取り上げます。

1. Nortification Service とは

Notification Service は、汎用目的の通知サービスです。Payara 4.1.1.163 から導入されています。何からの通知すべきイベントが発生したときに、その内容を設定した通知先へ送信します。Payara 4.1.1.164 では、通知先は server.log に限定されていますが、将来的にはメール、HipChat、Slack、JMS、SNMP なども通知先として設定できるようになる計画です。

2. Notification Service の有効化/無効化

Notification Service は規定では無効となっています。有効化するには管理コンソールまたは asadmin コマンドを使用します。

管理コンソールによる有効化は Payara のマニュアルを参照してください (スクリーンショットがあります)。もっとも、チェックボックス 1 つだけで操作するため、迷うことは少ないでしょう。

asadmin コマンドでも有効化できます。

$ asadmin notification-configure --enable=true --dynamic=true

3. Notification Service の用途

現時点では、Notification Service を活用するものは Payara 本体には備わっていません(昨日取り上げた Health Check Service とはいくらかの関連はあります)。この機能は将来を見越した汎用的な通知手段であるため、これからの展開に着たいといったところです。

Payara の Health Check Service

この記事は、Payara Advent Calendar 2016 の 6 日目です。昨日は「Payara Server と Payara Micro のクラスタリング」です。

今回から 3 回に渡って、Payara が持つ監視機能についてご紹介します。Payara には現在、以下の 3 種類の監視機能が備わっています。

  • Health Check Service
  • Nortification Service
  • Request Tracing Service

今回は Health Check Service について取り上げます。

1. Health Check Service とは

Health Check Service は、Payara の状態を監視して一定の閾値を超えた場合に、それを server.log へ出力する機能です。Payara が持つ 3 種類の監視機能の中では最も古く、Payara 4.1.1.161 から実装されています。

Health Check Service の監視対象は以下の通りです。

  • ホストの CPU 使用率
  • ホストのメモリ使用量
  • Payara の JVM の GC
  • Payara の JVM のヒープ使用量
  • 個々のスレッドの CPU 使用率
  • 長時間動作していないスレッド

Health Check Service ではログに GOOD、WARNING、CRITICAL といった状態表示がなされるため、Payara の状態をいち早く知る手がかりとなります。

2. Health Check Service を使用する

Health Check Service に関する設定は、基本的に asadmin コマンドで行います。また、コマンド実行時には Payara が動作している必要があります。

2.1. Health Check Service の有効化/無効化

Health Check Service は既定では無効になっています。有効にするには、以下のコマンドを実行します。

$ asadmin healthcheck-configure --enabled=true --dynamic=true

--dynamic=true オプションは Payara の再起動なしで設定を即時反映する場合に指定します。指定しない場合は次回起動時から Health Check Service が有効となります。

Health Check Service を無効にするには、以下のコマンドを実行します。

$ asadmin healthcheck-configure --enabled=false --dynamic=true

2.2. Health Check Service の対象一覧の表示

asadmin healthcheck-list-services コマンドで、監視対象の一覧を表示することができます。実行結果は、例えば以下のようになります。

$ asadmin healthcheck-list-services
Available Health Check Services:
        healthcheck-cpool
        healthcheck-cpu
        healthcheck-gc
        healthcheck-heap
        healthcheck-threads
        healthcheck-machinemem

2.3. Health Check Service の監視対象の設定

Health Check Service は単に有効化しただけでは何も監視しません。どの項目を監視対象にするかを asadmin healthcheck-configure-service コマンドで指定します。具体的には、以下のようなコマンドを実行します。

$ asadmin healthcheck-configure-service --enabled=true --serviceName=監視対象 --name=短縮名 --dynamic=true

監視対象は、asadmin healthcheck-list-services で表示される一覧の中から選択します。短縮名はログ出力時に監視対象を識別するためのラベルで、省略時は各監視対象に用意された既定値 (CONP、CPUC、GBGC、HEAP、HOGT、MEMM) が使用されます。--dynamic=true は設定を即時反映するためのオプションです。

2.4. Health Check Service の閾値の設定

監視の閾値を任意の値に設定するには、asadmin healthcheck-config-threshold コマンドを使用します。例を以下に示します。

$ asadmin healthcheck-configure-service-threshold --serviceName=監視対象 --thresholdCritical=90 --thresholdWarning=50 --thresholdGood=0 --dynamic=true

閾値は監視対象ごとに設定します。--thresholdCritical は CRITICAL 出力、--thresholdWarning は WARNING 出力、--thresholdGood は GOOD 出力の閾値をそれぞれ設定するためのオプションです。既定値はそれぞれ 90 (%)、50 (%)、0 (%) です。上記の例は、既定の閾値と同じ値を設定しています。閾値を特に設定しない場合には、既定値が自動的に適用されます。

なお、healthcheck-configure-service-threshold で閾値を設定できるのは、healthcheck-cpool (JDBC コネクション・プール)、healthcheck-cpu (CPU 使用率)、healthcheck-heap (ヒープ使用量)、healthcheck-machinemem (物理メモリ使用量) の 4 種類です。healthcheck-threads (応答のないスレッドの検出) と healthcheck-gc (GC) に関する設定は別の方法を用います。

2.5. 応答のないスレッドを検出するための設定

応答のないスレッドを検出するためには、asadmin healthcheck-hoggingthreads-configure コマンドを使用します。

2.6. GC を監視するための設定

GC を監視する設定については、実は asadmin では設定できません。一旦 Payara を停止し、domain.xml を直接書き換える必要があります。

3. 実行サンプル

Health Check Service を有効にすると、server.log に以下のようなメッセージが出力されます。

[2016-05-24T03:52:28.690+0000] [Payara 4.1] [INFO] [fish.payara.nucleus.healthcheck.HealthCheckService] [tid: _ThreadID=72 _ThreadName=healthcheck-service-3 [timeMillis: 1464061948690] [levelValue: 800] [[
CPUC:Health Check Result:[[status=WARNING, message='CPU%: 75.6, Time CPU used: 267 milliseconds'']']]]

[2016-05-24T21:11:36.579+0000] [Payara 4.1] [SEVERE] [fish.payara.nucleus.healthcheck.HealthCheckService] [tid: _ThreadID=71 _ThreadName=healthcheck-service-3] [timeMillis: 1464124296579] [levelValue: 1000] [[
HOGT:Health Check Result:[[status=CRITICAL, message='Thread with : 145-testing-thread-1 is a hogging thread for the last 59 seconds 999 milliseconds'']']]]

これは Payara のマニュアルからの抜粋です。私の環境では GOOD しか出力されず、Health Check Service の効果を実感しづらいためです。

4. See also

Payara のマニュアルに Health Check Service に関する説明があります (英語)。

この記事は、Payara Advent Calendar 2016 の 5 日目です。昨日は「Payara Micro の設計と実装」です。

Payara Micro のマニュアルには、Payara Micro は Payara Server とクラスタを組むことができるという記載があります (原文: "Payara Micro can cluster with Payara Server and share web session and JCache data.")。そこで、実際に試してみました。

なお、実施時期の都合により Payara 4.1.1.163 (旧バージョン) での検証となることをはじめにお断りしておきます。

1. 事前準備

Payara Micro は既定で Hazelcast の Auto Clustering が有効になっているため、特別な設定は必要ありません。一方、Payara Server は GlassFish との互換性維持のためか、Hazelcast が既定で無効となっているため、最初に有効化する必要があります。

Payara Server の Hazelcast を有効化するには、大きく管理コンソール (GUI) を使用する方法と、asadmin の起動時オプションで指定する方法の 2 種類があります。

1.1. 管理コンソールから Hazelcast を有効化する

管理コンソールから Hazelcast の設定を変更するには、図1 の Hazelcast 構成画面から操作します。手前味噌ですが、この画面の日本語化を担当したのは私です (Payara 4.1.153 以降)。

Hazelcast Configuration.png
figure 1.1 - Hazelcast 構成画面

スクリーンショットの赤枠で囲った部分、「Hazelcast分散キャッシュ機能を有効にするかどうかを決定します。」のチェックを ON にして、設定を保存してください。再起動は不要です。これだけで Payara Server の Hazelcast は有効になります。

もし、はじめからチェックが ON になっていた場合は、既に Hazelcast が有効になっています。

管理コンソールからだけでは本当に Hazelcast が有効化されたのか確認できないため (メッセージを信じるしかない)、念のため server.log の中身を見てみます。ここではスペースの関係上、Hazelcast に関連する場所だけ抜粋します。

[2016-12-05T23:38:15.075+0900] [Payara 4.1] [INFO] [] [com.hazelcast.instance.DefaultAddressPicker] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095075] [levelValue: 800] [[
  [LOCAL] [development] [3.6.4] Prefer IPv4 stack is true.]]

[2016-12-05T23:38:15.134+0900] [Payara 4.1] [INFO] [] [com.hazelcast.instance.DefaultAddressPicker] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095134] [levelValue: 800] [[
  [LOCAL] [development] [3.6.4] Picked Address[192.168.184.67]:5900, using socket ServerSocket[addr=/0:0:0:0:0:0:0:0,localport=5900], bind any local is true]]

[2016-12-05T23:38:15.147+0900] [Payara 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095147] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Hazelcast 3.6.4 (20160701 - 5b94d9f) starting at Address[192.168.184.67]:5900]]

[2016-12-05T23:38:15.147+0900] [Payara 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095147] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Copyright (c) 2008-2016, Hazelcast, Inc. All Rights Reserved.]]

[2016-12-05T23:38:15.148+0900] [Payara 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095148] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Configured Hazelcast Serialization version : 1]]

[2016-12-05T23:38:15.281+0900] [Payara 4.1] [INFO] [] [com.hazelcast.spi.OperationService] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095281] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Backpressure is disabled]]

[2016-12-05T23:38:15.300+0900] [Payara 4.1] [INFO] [] [com.hazelcast.spi.impl.operationexecutor.classic.ClassicOperationExecutor] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095300] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Starting with 2 generic operation threads and 4 partition operation threads.]]

[2016-12-05T23:38:15.706+0900] [Payara 4.1] [INFO] [] [com.hazelcast.instance.Node] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095706] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Creating MulticastJoiner]]

[2016-12-05T23:38:15.710+0900] [Payara 4.1] [INFO] [] [com.hazelcast.core.LifecycleService] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095710] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Address[192.168.184.67]:5900 is STARTING]]

[2016-12-05T23:38:15.790+0900] [Payara 4.1] [INFO] [] [com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThreadingModel] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443095790] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] TcpIpConnectionManager configured with Non Blocking IO-threading model: 3 input threads and 3 output threads]]

[2016-12-05T23:38:18.600+0900] [Payara 4.1] [INFO] [] [com.hazelcast.cluster.impl.MulticastJoiner] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098600] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] 


Members [1] {
	Member [192.168.184.67]:5900 this
}
]]

[2016-12-05T23:38:18.651+0900] [Payara 4.1] [INFO] [] [com.hazelcast.jmx.ManagementService] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098651] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Hazelcast JMX agent enabled.]]

[2016-12-05T23:38:18.679+0900] [Payara 4.1] [INFO] [] [com.hazelcast.core.LifecycleService] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098679] [levelValue: 800] [[
  [192.168.184.67]:5900 [development] [3.6.4] Address[192.168.184.67]:5900 is STARTED]]

[2016-12-05T23:38:18.691+0900] [Payara 4.1] [INFO] [] [fish.payara.nucleus.hazelcast.HazelcastCore] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098691] [levelValue: 800] [[
  Hazelcast Instance Bound to JNDI at payara/Hazelcast]]

[2016-12-05T23:38:18.692+0900] [Payara 4.1] [INFO] [] [fish.payara.nucleus.hazelcast.HazelcastCore] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098692] [levelValue: 800] [[
  JSR107 Caching Provider Bound to JNDI at payara/CachingProvider]]

[2016-12-05T23:38:18.692+0900] [Payara 4.1] [INFO] [] [fish.payara.nucleus.hazelcast.HazelcastCore] [tid: _ThreadID=136 _ThreadName=admin-thread-pool(6)] [timeMillis: 1478443098692] [levelValue: 800] [[
  JSR107 Default Cache Manager Bound to JNDI at payara/CacheManager]]

Hazelcast クラスタへ参加したことを確定付けているのは、上記ログのうち以下の部分です。Hazelcast でクラスタ・ノードの追加・削除を繰り返しているとその度に現れるメッセージですので、覚えておきましょう。

Members [1] {
	Member [192.168.184.67]:5900 this
}

ちなみに、現時点では 1 つのノードしかクラスタに参加していないため、Member は 1 つしか表示されていません。

1.2. asadmin から Hazelcast を有効化する

管理コンソールが使用できない環境では、asadmin から Hazelcast を有効化します。

asadmin set-hazelcast-configuration --enabled=true [ --dynamic=true ]

asadmin を使用する場合には、サーバーを起動するたびに設定を行う必要があるます。

1.3. domain.xml に設定を記述する

domain を停止した状態で domain.xml に以下の 1 行を追加します。

<hazelcast-runtime-configuration enabled="true"/>

2. Payara Server を起動する

Hazelcast が有効になっている状態で Payara Server を起動します。念のため、1.1. で示したようなログが server.log に出力されていることを確認してください。

3. Payara Micro を起動する

ここまでの手順に引き続き、Payara Micro を起動します。以下に起動時のログを示します。

hasunuma@pasiphae:~$ java -jar greeting\-0.0.1\-SNAPSHOT.jar                    
[2016-12-05T23:40:54.549+0900] [Payara Micro 4.1] [INFO] [NCLS-CORE-00087] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254549] [levelValue: 800] Grizzly Framework 2.3.25 started in: 26ms - bound to [/0.0.0.0:8080]

[2016-12-05T23:40:54.640+0900] [Payara Micro 4.1] [INFO] [NCLS-CORE-00058] [javax.enterprise.system.core] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254640] [levelValue: 800] Network listener https-listener on port 8443 disabled per domain.xml

[2016-12-05T23:40:54.752+0900] [Payara Micro 4.1] [INFO] [SEC-SVCS-00100] [javax.enterprise.security.services] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254752] [levelValue: 800] Authorization Service has successfully initialized.

[2016-12-05T23:40:54.805+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.instance.DefaultAddressPicker] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254805] [levelValue: 800] [LOCAL] [development] [3.6.4] Prefer IPv4 stack is true.

[2016-12-05T23:40:54.809+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.instance.DefaultAddressPicker] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254809] [levelValue: 800] [LOCAL] [development] [3.6.4] Picked Address[192.168.184.89]:5901, using socket ServerSocket[addr=/0.0.0.0,localport=5901], bind any local is true

[2016-12-05T23:40:54.819+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254819] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Hazelcast 3.6.4 (20160701 - 5b94d9f) starting at Address[192.168.184.89]:5901

[2016-12-05T23:40:54.820+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254820] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Copyright (c) 2008-2016, Hazelcast, Inc. All Rights Reserved.

[2016-12-05T23:40:54.820+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.system] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254820] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Configured Hazelcast Serialization version : 1

[2016-12-05T23:40:54.961+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.spi.OperationService] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254961] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Backpressure is disabled

[2016-12-05T23:40:54.978+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.spi.impl.operationexecutor.classic.ClassicOperationExecutor] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443254978] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Starting with 2 generic operation threads and 2 partition operation threads.

[2016-12-05T23:40:55.338+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.instance.Node] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443255338] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Creating MulticastJoiner

[2016-12-05T23:40:55.341+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.core.LifecycleService] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443255341] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Address[192.168.184.89]:5901 is STARTING

[2016-12-05T23:40:55.413+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThreadingModel] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443255413] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] TcpIpConnectionManager configured with Non Blocking IO-threading model: 3 input threads and 3 output threads

[2016-12-05T23:40:55.562+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.cluster.impl.MulticastJoiner] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443255562] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Trying to join to discovered node: Address[192.168.184.67]:5900

[2016-12-05T23:40:55.634+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.nio.tcp.InitConnectionTask] [tid: _ThreadID=58 _ThreadName=cached2] [timeMillis: 1478443255634] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Connecting to /192.168.184.67:5900, timeout: 0, bind-any: true

[2016-12-05T23:40:55.641+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.nio.tcp.TcpIpConnectionManager] [tid: _ThreadID=58 _ThreadName=cached2] [timeMillis: 1478443255641] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Established socket connection between /192.168.184.89:47714 and /192.168.184.67:5900

[2016-12-05T23:41:02.583+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.cluster.ClusterService] [tid: _ThreadID=38 _ThreadName=hz._hzInstance_1_development.generic-operation.thread-0] [timeMillis: 1478443262583] [levelValue: 800] [[
  [192.168.184.89]:5901 [development] [3.6.4] 

Members [2] {
        Member [192.168.184.67]:5900
        Member [192.168.184.89]:5901 this
}
]]

[2016-12-05T23:41:04.602+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.jmx.ManagementService] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264602] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Hazelcast JMX agent enabled.

[2016-12-05T23:41:04.730+0900] [Payara Micro 4.1] [INFO] [] [com.hazelcast.core.LifecycleService] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264730] [levelValue: 800] [192.168.184.89]:5901 [development] [3.6.4] Address[192.168.184.89]:5901 is STARTED

[2016-12-05T23:41:04.735+0900] [Payara Micro 4.1] [INFO] [] [fish.payara.nucleus.eventbus.EventBus] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264735] [levelValue: 800] Payara Clustered Event Bus Enabled

[2016-12-05T23:41:04.736+0900] [Payara Micro 4.1] [INFO] [] [fish.payara.nucleus.store.ClusteredStore] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264736] [levelValue: 800] Payara Clustered Store Service Enabled

[2016-12-05T23:41:04.738+0900] [Payara Micro 4.1] [INFO] [] [fish.payara.nucleus.exec.ClusterExecutionService] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264738] [levelValue: 800] Payara Clustered Exector Service Enabled

[2016-12-05T23:41:04.738+0900] [Payara Micro 4.1] [INFO] [] [fish.payara.nucleus.store.ClusteredStore] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1478443264738] [levelValue: 800] Payara Cluster Service Enabled

Hazelcast クラスタへ参加したことを確定付けているのは、上記ログのうち以下の部分です。

Members [2] {
        Member [192.168.184.67]:5900
        Member [192.168.184.89]:5901 this
}

ちなみに、このでは 2 つ目のノードがクラスタに参加したため、Member には 2 つ表示されています。

4. 説明しなかったこと

さらなるインスタンスの追加や削除については、スペースの都合で割愛しましたが、ノード間のネットワーク接続が正常で、かつ、ここまでの手順に問題が発生していなければ正しく行われるはずです。結果は必ず Hazelcast のログである Members [n] { (ノード一覧) } で簡単に確認できるため、最低限この部分のチェックだけは怠らないようにしてください。

5. Payara 4.1.1.164 追補

Payara 4.1.1.164 では管理コンソールに Hazelcast のクラスタ・メンバを一覧できる画面が追加されました。合わせて、Hazelcast 構成タブの位置も移動になっています。

hazelcast-cluster-members.png
figure 5.1 - Hazelcast クラスタ・メンバ一覧

hazelcast-configuration.png
figure 5.2 - Hazelcast 構成