FAQ

PERFORCE

ナレッジベースからの転載記事に関するFAQ

Qジャーナルノート

FAQ ID:KB3193

A

概要

ジャーナルノートは、バージョン2010.2で初めて導入された、純粋なメタデータです。ジャーナルノートは、データベースのテーブル行を記録せずに、イベントに関するメタデータ情報を記録するという点において、@mx@@ex@に類似します。

詳細

ジャーナルやチェックポイントにジャーナルノートが存在することで、ジャーナルやチェックポイントを後ほど使用するユーザは、ノートを検証のうえそこに格納されている情報を使用して、振る舞いを管理することが可能となります。さらに、ジャーナルノートを用いてレプリカサーバの機能を有効化し、レプリカサーバが処理するジャーナルノートに基づき、同サーバの動作を決めることができます。

ジャーナルノートの基本的な構成内容は、以下のとおりです。

@nx@ type date @version@ i1 i2 i3 i4 i5 @s1@ @s2@ @s3@ @s4@ @s5@

ジャーナルノートにはすべて、以下3つの共通フィールドがあります。

@nx@ type date @version@ i1 i2 i3 i4 i5 @s1@ @s2@ @s3@ @s4@ @s5@

type = ジャーナルノートのタイプdate = ノートが生成時刻を示すタイムスタンプversion = ノートを生成したサーバのバージョン

これらに加えて、一連の正数(i1~i5)や文字列(s1~s5)の形式を用いたオプションで、ジャーナルノートのタイプに基づいた補足情報が保持されます。

@nx@ type date @version@ i1 i2 i3 i4 i5 @s1@ @s2@ @s3@ @s4@ @s5@

ジャーナルノートタイプの概要

タイプ 名前 オプション
0 チェックポイントのヘッダ i1 = 大文字小文字の識別
s1 = データベースのルート
s2 = ジャーナルファイル名
1 チェックポイントのトレーラ  
2 ジャーナルのヘッダ i1 = 大文字小文字の識別
i2 = ジャーナルのタイプ
s1 = データベースのルート
s2 = ジャーナルファイル名
s3 = サーバのバージョン

ジャーナルタイプフィールド(i2)は、ジャーナルファイルの生成方法を示します。
0 = 通常のジャーナル
1 = p4d -jd
2 = p4d -jds
3 = p4d -xx (jnl.fix)
4 = journaldbchecksums -u
3 ジャーナルのトレーラ  
4 テーブルの概要 i1 = テーブルのバージョン
i2 = 古いバージョン
i3 = テーブルのチェックサム
i4 = テーブルの不適切なunlock数
s1 = テーブル名
5 サーバのアップグレード i1 = アップグレードカウンタの開始値
i2 = アップグレードカウンタの反映先の値
6 テーブルのアップグレード i1 = 実行されるアップグレード
s1 = 呼び出されるアップグレード関数名
7 サーバの起動 s1 = サーバのポート番号
s2 = サーバのルート
s3 = サーバ名
s4 = サーバID
8 サーバの停止 s1 = サーバのポート番号
9 Unicodeの有効化  
10 パッチ対象のテーブル  
11 リプレイ対象のジャーナル i1 = ジャーナルのリプレイ中に有効なオプション
s1 = リプレイ対象のジャーナル名/チェックポイント名
12 テーブルのチェックサム i1 = テーブルのバージョン
i2 = テーブルのチェックサム
i3 = テーブルの不適切なunlock数
i4 = テーブルの生成
s1 = テーブル名
13 ヘッダのアンロード i1 = ドメインタイプ(クライアント/ラベル/ストリーム)
s1 = ドメイン名
s2 = アンロード対象のファイル名
14 トレーラのアンロード  
15 チェンジリストの変更 i1 = チェンジリスト番号
i2 = チェンジリストのリビジョン番号
i3 = journaldbchecksums (0)またはsubmit (1)で記録されたノート
s1 = チェンジリストのチェックサム
16 テーブルのダンプ i1 = テーブルのバージョン
i2 = テーブルのチェックサム
i3 = レコード数
i4 = isCompressed
s1 = テーブル名
s2 = ダンプファイル名
17 ブロックチェックサム i1 = テーブルのバージョン
i2 = ブロック番号
i3 = ブロックサイズ
i4 = ダウンプバージョン
s1 = テーブル名
s2 = ブロックの最初のキー
s3 = ブロックの最後のキー
s4 = ブロックのチェックサム
18 マスターの有効化 s1 = ポート番号
s2 = 名前(空白の場合有)
s3 = サーバID(空白の場合有)
19 マスターの無効化 s1 = ポート番号
s2 = 名前(空白の場合有)
s3 = サーバID(空白の場合有)
20 マスターの移行 s1 = ポート番号
s2 =名前(空白の場合有)
s3 = サーバID(空白の場合有)
21 スタンバイの有効化 s1 = ポート番号
s2 = 名前(空白の場合有)
s3 = サーバID(空白の場合有)
22 ワークスペースの有効化 s1 = ポート番号
s2 = 名前(空白の場合有)
s3 = サーバID(空白の場合有)
23 レプリカの移行 s1 = このレプリカのサーバID
s2 = このレプリカの現在のステータスファイルがある場所
i1 = ターゲットから最後に参照された@ex@あるいは@mx@レコード内のpid
i2 = ターゲットから最後に参照された@ex@あるいは@mx@レコード内のタイムスタンプ

使用例

ジャーナルノートのタイプは多岐にわたり、それらの情報を、さまざまな目的で使用することが可能です。以下に、チェックポイントに存在するヘッダ/トレーラのノートが、いかに有用であるかを説明します。

チェックポイントごとに、チェックポイントのヘッダノートが存在します。

@nx@ 0 1296517759 @30@ 2 0 0 0 0 @/p4root@ @journal@ @@ @@ @@

以下は、チェックポイントのトレーラノートです。

@nx@ 1 1296517767 @30@ 0 0 0 0 0 @@ @@ @@ @@ @@

チェックポイントのヘッダノートは、その補足情報の中に、チェックポイントが取得された際に有効な大文字小文字の識別方法とUnicodeオプションが保持されています。これによってPerforceサーバは、必ず同じオプションを有効のうえ、チェックポイントをリストアします。

$ p4d -r /p4root -jr checkpoint.9Perforce db files in '.' will be created if missing...Recovering from checkpoint.9...Perforce server error:Journal file 'checkpoint.9' replay failed at line 1!Bad transaction marker!Case-handling mismatch:server uses Windows-style (-C1) but journal flags are Unix-style (-C0)!

チェックポイントのヘッダノートでサーバのバージョンが指定されている状態で、それより新しいサーバのバージョンで生成されたチェックポイントをリストアすると、警告メッセージが出力されます。

$ p4d -r /p4root -jr checkpoint.9Recovering from checkpoint.9...Perforce server info:Server version 30 is replaying a version 31 journal.

ジャーナルノートは、チェックポイントやジャーナルの他のコンテンツからは独立しているため、障害が発生した場合には、簡単にこれらのノートを削除することが可能です。

例:

grep -v '^@nx@' checkpoint.N > checkpoint.N.new

チェックポイントのトレーラノートは、存在するだけで、チェックポイントが正常に完了したことを確認するために使用することが可能です。

チェックポイントのヘッダ/トレーラに記録されているタイムスタンプの差分から、チェックポイントの作成に費やされた時間を算出できます。

回答を閉じる

Qジャーナルファイルとチェックポイントファイルの読み方

FAQ ID:KB2426

A

概要

通常の環境下において、Perforce管理者がチェックポイントファイルおよびジャーナルファイルの閲覧や編集操作を余儀なくされることはありません。ただし、チェックポイントやジャーナルからの復旧に関わる問題を、トラブルシューティングする必要に迫られる場合があります。この記事には、ジャーナルファイルおよびチェックポイントファイルの構成における、難しい側面の理解を深めるために役立つ情報を記載します。

警告: 適切な指示を受けることなく、チェックポイントやジャーナルを編集すると、サーバのパフォーマンスに大きな影響を与えたり、データが破損したりすることがあります。Perforceデータベースのリストアに支援が必要な場合や、現在のチェックポイントやジャーナルファイルに問題が生じた際には、弊社テクニカルサポートまでご連絡ください。

詳細

チェックポイントおよびジャーナルファイルはテキスト形式です。これらのファイルは、大半のテキストエディタやテキストツール(grepsplitなど)を使用して、内容を確認することができます。これらのファイル内のデータは、次の書式で保存されています。

  • 各レコードの改行コードはNewLine("\n")
  • 各フィールドはスペース(" ")で区切られる
  • 文字列はアットマーク("@")を使用して「囲まれる」
  • 文字列にアットマークが含まれる場合、アットマークを2重に記述("@@")

: アットマークで囲われた文字列には、改行コードNewLineが含まれます(例: チェンジリストのコメントなど)。このため、改行コードNewLineに基づいて1行を読み込むテキスト指向のツール(grepsplitなど)を使用する場合は、十二分に注意してください。

フィールドの説明

フィールド 1

1つめのフィールドでは、そのフィールドに対するデータベース操作を説明します。このフィールドは、使用されるPerforceのバージョンによって異なります。

バージョン97.3以前

@put@ - レコードをデータベースに書き込む(入力)@del@ - レコードをデータベースから削除

バージョン98.1以降

@pv@ - 以前のデータベースバージョンの"@put@"を置き換え@dv@ - 以前のデータベースバージョンの"@del@"を置き換え

: チェックポイントでは、いずれかの形式が使用されますが、特にユーザが最初にチェックポイントを作成してからジャーナルをトランケートせずに、98.1より前のバージョンからアップグレードした場合、ジャーナルファイルには、"@put@"/"@del@"および"@pv@"/@dv@レコードが混在する可能性があります。

@rv@ - レコードを置き換え

これは、サーバに関連する限り、"@pv@"と機能的に同一です。一番の目的は、チェックポイントおよびジャーナルの可読性の向上にあります。

バージョン99.2以降

@vv@ - ジャーナルのみ - ジャーナルのプレイバックシーケンスにおける整合性チェック

(通常はバックアプしたジャーナルファイルの冒頭に存在する)このレコードの値は、「ジャーナル」カウンタの値に一致し、誤った順序でのジャーナルファイルの再リプレイを回避します。ジャーナルファイルのリストア時に、この値が一致しないと、「Journal out of sequence」エラーが出力されます。このエラーメッセージとともに、つぎの文も表示されます。

"Perforce server error:1 out of sequence journals were not replayed"

バージョン2006.2以降

@ex@および @mx@ - トランザクションマーカ

これらの行には、ジャーナルファイルに記録されるトランザクションのプロセスID(PID)および、タイムスタンプが記述されています。これらのマーカは、ジャーナルの複製(レプリケーション)ツール向けに用意されているので、データベースのレコードには対応していません。このため、これらの行がリストアされてもデータベースには何も記録されません。

バージョン2010.1以降

@nx@ - ジャーナルノート

データベースにテーブル行を記録せずに、発生したイベントに関するメタデータ情報を記録するという点において、@mx@や@ex@に類似します。ジャーナルノートを用いることで、ジャーナルやチェックポイントを後ほど使用するユーザは、ノートを確認のうえ、その情報を使用してそれらの振る舞いを管理することが可能となります。

バージョン2011.1以降

@dl@ - コンテンツ情報の削除

これらのレコードには、「p4 obliterate」、「p4 archive」、「p4 shelve -d」等のコマンドの実行によって、サーバのリポジトリから削除されたファイルコンテンツに関する情報が保持されます。これらは、ライブラリアンのファイル名/バージョン、削除されたアーカイブコンテンツのライブラリアンのタイプから構成されます。さらに、同レコードには削除に使用されたコマンドや、そのコマンドに渡されたファイル仕様についての情報も記録されます。

フィールド 2

このフィールドには、レコード形式のリビジョン番号が格納されます。

フィールド 3

3つめのフィールドには、データベースのテーブル名が保持されます。同じ名前のファイルが、Perforceサーバのルートディレクトリに作成されます。

その他のフィールド

特定のレコードにおけるその他のフィールドは、データベースのバージョンによって異なるため、使用しているPerforceの特定のバージョン向けのデータベーススキーマドキュメントを参照してください。最新リリースのデータベーススキーマドキュメントは、以下の場所に公開されています。

http://www.perforce.com/perforce/doc.current/schema/index.html

古いスキーマバージョンのドキュメントについては、弊社テクニカルサポートにお問い合せください。

回答を閉じる

QParallel Syncとそのメリット(Parallel Sync and its benefits)

FAQ ID:KB9064

Q
原文: http://answers.perforce.com/articles/KB/9064 Version:Perforce Helix 2014以降
A

問題

「p4 sync」の処理をスピードアップする方法はありますか?

解決策

リリース2014.1でPerforceは、「Parallel Sync」機能を導入しました。この機能によって、Perforceクライアントは、Perforceサーバからパラレルのスレッド形態でファイルを転送することが可能となりました。シリアル(現在のデフォルト)とは、対照的な手法となります。

Parallel Syncのメリットを本当に実感するには、なるべく小さなサイズのファイルを数多く用意して、それをサーバから取得する必要があります。Parallel Syncのメリットは、次の条件が満たされる際に、最も明確に認識することができます。

  • 長距離の遅延ネットワークや、他のネットワーク構成(ネットワークバッファリング、パケットロス、不適切なTCPトラフィックの輻輳制御の振る舞いなどを制限する設定の組み合わせによって、単一のTCPフローにおける利用可能な帯域幅を制限するような構成)による制限がある環境
  • クライアントがファイルを解凍するために相当な量の処理が必要となる、圧縮された大規模なバイナリファイル。進行中のファイル取得フローを複数持つことは、ネットワークの入出力がファイルの解凍処理で重複することにくわえ、その(マルチコアのクライアントマシン上の)複数のファイルが同時に解凍されていることを意味する。

パラレルでp4 syncコマンドを実行するには、「--parallel」オプションを記述し、その直後に任意のスレッド数を指定します。さらに、コンマで区切って引数を追加し、最小スレッド数(引数:min)や、最小ファイルサイズ(引数:minisize)をキロバイト単位で指定することが可能です。以下にコマンドの記述例を示します。

p4 sync --parallel "threads=4,min=1,minsize=1" [filespec] ...

: Parallel Syncオプションを有効にするためには、Perforceサーバ上でnet.parallel.max変数の値を1以上に設定しなければなりません。「p4 help configurables」を実行すると、次のような出力を確認できます。

net.parallel.max 0 Highest allowed degree of sync parallelism

構文やオプションに関する詳細は、「p4 help sync」または、コマンドリファレンスに記載のp4 syncのページを参照ください。

PerforceユーザにParallel Syncの使用を奨励する前に、各自の環境に同機能が適合するかどうかを確認するための評価テストを実施することを推奨します。

回答を閉じる

Q構造化サーバログ(Structured Server Logs)

FAQ ID:KB3088

Q
原文: http://answers.perforce.com/articles/KB/3088 Version:Perforce Helix 2012.1以降
A

問題

Helixサーバはバージョン2012.1以降、新しいロギング機能が追加され、サーバやユーザのアクティビティに関する追加情報を記録することが可能となりました。 サーバのトランザクションデータを構造化サーバログに記録することができ(コンマ区切りのCSV形式)、従来のHelixサーバログのフォーマットと比べ、より簡単に構文解析を行うことができます。

: 構造化サーバログは、きわめて情報が詳細なため、みるみるファイルサイズが肥大化します。 ログファイルを定期的にローテートまたは削除するか、serverlog.maxmb構成可能変数(以下で説明)を使用して、ログファイルのサイズを制限する必要があります。

: 構造化サーバログは、まだすべてのエラー条件を取得しないため(2012.1時点)、標準のHelixサーバログの代替にはなりません。

解決策

構造化サーバロギングを有効にするには、次の情報を用いてp4 configureコマンドを実行し、サーバに構成可能変数を設定します。

サーバログファイル名の指定(serverlog.file.N)

エラーイベントの追跡情報を出力するログの設定方法を、以下に例示します。

p4 configure set servername#serverlog.file.1=errors.csv

指定のファイルサイズに達した場合に、自動的にログファイルをローテートする回数の指定

ログファイルが100MBになった場合、自動的にそのファイルをローテートするコマンドを以下に例示します。

p4 configure set servername#serverlog.maxmb.1=100

: serverlog.maxmb.Nはオプション設定ですが、構造化サーバログのサイズを制御するためベストプラクティスとして推奨されます。

保持するログファイル数の指定(serverlog.retain.N)

最新のログファイルを10個保持するコマンドを以下に例示します。

p4 configure set servername#serverlog.retain.1=10

: serverlog.retain.Nはオプション設定ですが、ローテートされたログファイルをすべて保持すると、 膨大なディスクの空き少量を消費する可能性があるため、ベストプラクティスとして推奨されます。

p4 configureのログ設定は動的です。サーバはログを生成のうえ、これを使用して次のサーバコマンドの処理を開始します。

: p4 configureコマンドにサーバ名を指定しないと、このサーバ構成可能変数のデータを使用するすべてのサーバ(マスターおよびレプリカサーバ)に、 該当の構成可能変数が設定されます。サーバ構成可能変数を設定する場合は常に、サーバ名を指定することがベストプラクティスです。

サーバログファイル名

ログファイルに出力されるイベントは、使用されるログファイル名で管理されます。

ログファイル名 事前設定済みのイベントall.csv あらゆるイベントcommands.csv コマンドイベント(command-start, command-compute, command-end?)errors.csv エラーイベント(errors-failed, error-fatal)audit.csv 監査イベント(audit, purge)track.csv コマンド追跡イベント(track-usage, track-rpc, track-db)user.csv p4 logappendのユーザイベントevents.csv サーバイベント(startup, shutdown, checkpoint, journal rotation)integrity.csv データベースの整合性イベントauth.csv ログインイベントroute.csv ネットワークのルーティングイベント

2つ以上の構造化サーバログを保持することが可能です。各サーバログをセットアップするp4 configureコマンドを、以下に例示します。

p4 configure set servername#serverlog.file.1=all.csvp4 configure set servername#serverlog.file.2=commands.csvp4 configure set servername#serverlog.file.3=errors.csvp4 configure set servername#serverlog.file.4=events.csv

サーバログイベント

サーバログイベントはすべて、構造化サーバログのエントリの最初のフィールドにイベント番号が記述されます。

イベント名 イベント番号 詳細command-start 0 コマンドの開始command-compute 1 コマンドの取得command-end 2 コマンドの終了errors-all 3 すべてのエラーerrors-failed 4 失敗したエラーerrors-fatal 5 重要なエラーaudit 6 監査イベント(p4 sync/p4 archive)track-usage 7 再使用の追跡track-rpc 8 rpcの追跡track-db 9 データベースの追跡user 10 ユーザイベント(p4 logappend)trigger 11 トリガイベントevent 12 startup, shutdown, restart, jj, jcpurge 13 purge-rev(p4 obliterate)network-estimatesb 14 ネットワーク評価integrity 15 レプリカの整合性検証中に発生するイベント。詳細はp4 help journaldbchecksumsを参照auth 16 p4 loginの実行結果として生じるイベントroute 17 認証済みのクライアント接続における完全なネットワークのルート。net.mimcheck関連のエラーでは、関連するホップ数もログに記録

ログ管理

p4 logrotateコマンドを使用して、構造化サーバログファイルをローテートします。

p4 logrotate # ログファイルをすべてローテートp4 logrotate -l all # 特定のログファイル(all)をローテート

ログのローテートを自動的に行うオプションも用意されています。

p4 configure set servername#serverlog.maxmb.1=100

上記の例では、最初のログファイル(本ドキュメントの例では「all」)が100MBになった場合に、自動的にローテートするようサーバに指示しています。他の番号付きログに対して別の値を設定することも可能です。ログファイルは、チェックポイントやジャーナルローテーション処理時に自動的にローテートされます。このため、serverlog.retain.Nの値を覚えておいてください。

特定の数のログファイルのみを保持したい場合は、その数を指定することが可能です。

p4 configure set servername#serverlog.retain.1=10

新しいログファイルが生成されると、古いものはパージ(削除)されます。

ログファイルの分析

p4 logparseコマンドを用いることで、構造化サーバログファイルの解析を行うことができます。コマンドログから、p4 protectコマンドを実行したユーザを検索する例を、以下に示します。

p4 logparse -F 'f_func = user-protect' -T 'f_user f_host' commands... f_user bruno... f_host unknown... f_user bruno... f_host unknown

「all」ログでp4 verifyコマンドの実行ログを検索するには、次のようにコマンドを実行します。

p4 logparse -F "f_func=user-verify" all.cs... f_eventtype 9... f_timestamp 1329344312... f_timestamp2 372496000... f_date 2012/02/15 14:18:32 372496000... f_pid 73240... f_cmdno 1... f_user bruno... f_client mac-bruno... f_func user-verify... f_host 127.0.0.1... f_prog p4... f_version 2012.1/DARWIN90X86_64/417685... f_args -q://...... f_trackType db... f_dbName db.protect... f_pagesIn 2... f_pagesOut 0... f_pagesCached 1... f_reorderIntl 0... f_reorderLeaf 0... f_readLocks 1... f_writeLocks 0... f_gets 0... f_positions 1... f_scans 4... f_puts 0... f_deletes 0... f_offset 562095

ログファイルのフォーマット

特定のログレコードのフィールドは、イベントのタイプに基づきます。

すべてのログレコードのタイプの詳細を確認するには、p4 logschemaコマンドを使用します。ログに出力されるイベントレコードを、以下に例示します。

12,1329249658,338360000,2012/02/14 12:00:58 338360000,58914,5,restart

上記の場合、イベントタイプは12(1つめのフィールド)です。レコード内の特定のフィールドに関する情報を確かめる際にもp4 logschemaを使用します。

$ p4 logschema 12... f_recordType 12... f_field 0... f_name eventtype... f_recordType 12... f_field 1... f_name timestamp... f_recordType 12... f_field 2... f_name timestamp2... f_recordType 12... f_field 3... f_name date... f_recordType 12... f_field 4... f_name pid... f_recordType 12... f_field 5... f_name eventCode... f_recordType 12... f_field 6... f_name eventInfoフィールド 説明 イベントタイプeventtype イベントタイプ Alltimestamp Unixのタイムスタンプ Alltimestamp2 高精度のタイムスタンプ Alldate 日付 Allpid プロセスID Allcmdno コマンド番号 Alluser ユーザ Allclient クライアント Allfunc 機能(関数?) Allhost ホスト Allprog プログラム Allversion バージョン Allargs コマンド引数 command-start, command-compute, command-endseverity 重要度レベル errors-all, errors-failed, errors-fatalsubsys サブシステム errors-all, errors-failed, errors-fatalsubcode サブシステムコード errors-all, errors-failed, errors-fataltext エラーテキスト errors-all, errors-failed, errors-fatalaction 監査アクション auditfile ファイル auditrev リビジョン audittrackType 追跡タイプ track-usage, track-rpc, track-dbtimer タイマー track-usageutime ユーザ時刻 track-usagestime システム時刻 track-usageio_in I/O読み込み track-usageio_out I/O書き込み track-usagenet_in IPCイン track-usagenet_out IPCアウト track-usagemaxrss 最大物理メモリ track-usagepage_faults ページング失敗 track-usagerecvCount 受信数 track-rpcsendCount 送信数 track-rpcrecvBytes 受信バイト track-rpcsendBytes 送信バイト track-rpcrpc_hi_mark_fwd 最大転送 track-rpcrpc_hi_mark_rev 最大受信 track-rpcrecvTime 受信時刻 track-rpcsendTime 送信時刻 track-rpcdbName データベースのテーブル名 track-dbpagesIn ページイン track-dbpagesOut ページアウト track-dbpagesCached ページのキャッシュ track-dbreorderIntl 内部の再構築 track-dbreorderLeaf リーフノード再構築 track-dbreadLocks 読み取りロック track-dbwriteLocks 書き込みロック track-dbgets 取得 track-dbpositions ポジション track-dbscans スキャン track-dbputs 挿入 track-dbdeletes 削除 track-dbtriggerAction トリガアクション triggertriggerData トリガデータ triggereventCode イベントコード eventeventInfo イベント情報 eventaction アクション purgefile ファイル purgerev リビジョン purgeevent イベント default

カスタムイベントログ(ドキュメント未記載の機能)

構造化ログファイルに出力するイベントを定義するために、構成可能変数「serverlog.events.N」(ドキュメント未記載)にイベントリストをコンマ区切りで指定し、使用することが可能です。以下に例示します。

p4 configure set serverlog.file.8=custom.csvp4 configure set serverlog.events.8="command-start,command-end'

指定可能なイベントリストは次のとおりです。

command-startcommand-endcommand-computeerrors-failederrors-allerrorseventaudittracktriggersuserintegrityauthrouteall

: 上述の『サーバログファイル名』セクションに記載の標準ファイル名の1つを使用して、ファイル名のみを定義すると、サーバは「serverlog.events.N」構成可能変数の設定によって上書き可能なビルトインのデフォルト値を使用して、必要なイベントを処理します。

回答を閉じる