|
||||||||||
| 前のクラス 次のクラス | フレームあり フレームなし | |||||||||
| 概要: 内部クラス | フィールド | コンストラクタ | メソッド | 詳細: フィールド | コンストラクタ | メソッド | |||||||||
java.lang.Object | +--org.apache.log4j.NDC
The NDC class implements nested diagnostic contexts as defined by Neil Harrison in the article "Patterns for Logging Diagnostic Messages" part of the book "Pattern Languages of Program Design 3" edited by Martin et al.
NDCクラスは、Martin et alにより編集された書籍、"Pattern Language of Program Design 3"の"Pattern for Logging Diagnostic Message"部の 記事内の Neil Harrison が定義した ネスト化診断コンテキストを 実装しています。
A Nested Diagnostic Context, or NDC in short, is an instrument to distinguish interleaved log output from different sources. Log output is typically interleaved when a server handles multiple clients near-simultaneously.
ネスと化診断コンテキストまたは、略してNDC は、インターリーブログ出力と異なるソースを区別するための仕組みです。 サーバがマルチクライアントをほぼ同時に処理する時、ログの出力は、典型的にインターリーブされます。
Interleaved log output can still be meaningful if each log entry from different contexts had a distinctive stamp. This is where NDCs come into play.
異なるコンテキストからの各ログのエントリがことなる目印を持った場合、インターリーブされたログの出力は、いまだ有意義であるはずです。
Note that NDCs are managed on a per thread
basis. NDC operations such as push, pop(), clear(), getDepth() and setMaxDepth(int)
affect the NDC of the current thread only. NDCs of other
threads remain unaffected.
NDCはスレッド毎で維持されます。
pushやpop()、clear()、getDepth()、
setMaxDepth(int)は、現在のスレッドだけをもつNDCに影響を及ぼします。
他のスレッドをもつNDCには影響はありません。
For example, a servlet can build a per client request NDC
consisting the clients host name and other information contained in
the the request. Cookies are another source of distinctive
information. To build an NDC one uses the push
operation. Simply put,
例えば、サーブレットは、要求に含まれるクライアントのホスト名や他の情報を
もとにクライアントの要求 NDC 毎に構築されます。
Cookies は、明確な情報をもつ別の情報源です。
NDCを組み立てるには、一つには、pushオペレーションを使います。
簡単に置き換えると、
コンテキストは、ネスト化されているはずです。
NDC.push. As a
side effect, if there is no nested diagnostic context for the
current thread, this method will create it.
コンテキストを入力したとき、NDC.pushが呼び出されます。
一つの影響として、現在のスレッドに関するネスト化診断コンテキストがない場合、
このメソッドは、それを作成します。
NDC.pop.
コンテキストを出す時、NDC.popが呼び出されます。
NDC.remove().
スレッドを抜ける時、NDC.remove()が呼び出されるのを確かめてください。
There is no penalty for forgetting to match each
push operation with a corresponding pop,
except the obvious mismatch between the real application context
and the context set in the NDC.
実際のアプリケーションのコンテキストとNDC内に設定されているコンテキスト間に明らかなミスマッチがあった場合を除き、対になっているpopを使った各pushオペレーションにマッチし忘れた場合でもペナルティは課せられません。
If configured to do so, PatternLayout and TTCCLayout instances automatically retrieve the nested diagnostic
context for the current thread without any user intervention.
Hence, even if a servlet is serving multiple clients
simultaneously, the logs emanating from the same code (belonging to
the same category) can still be distinguished because each client
request will have a different NDC tag.
もし、そうするように設定した場合、PatternLayoutとTTCCLayout
のインスタンスはユーザの介入なしに自動的にネスト化診断コンテキストを取り出します。
その上で、たとえ、サーブレットが、マルチクライアントを同時に処理したとしても、
各クライアントの要求が、異なる NDC のタグを持っているという理由で、同じコード(同じカテゴリに属している)から発生するログは区別されます。
Heavy duty systems should call the remove() method when
leaving the run method of a thread. This ensures that the memory
used by the thread can be freed by the Java garbage
collector. There is a mechanism to lazily remove references to dead
threads. In practice, this means that you can be a little sloppy
and sometimes forget to call remove() before exiting a
thread.
大量の処理をもつシステムでは、スレッドのrunメソッドを抜け出た時 remove()
を呼び出したほうがいいでしょう。
これにより、スレッドで使われるメモリがJavaのガベージコレクタにより開放されると
いうのを保証されます。
死んでしまったスレッドへの参照を怠けて削除するというメカニズムです。
実際には、このことは、あなたが、ちょっといいかげんで時々スレッドを抜ける前に
remove()を呼び出すのを忘れる可能性があるということを意味しています。
A thread may inherit the nested diagnostic context of another
(possibly parent) thread using the inherit
method. A thread may obtain a copy of its NDC with the cloneStack method and pass the reference to any other
thread, in particular to a child.
スレッドは、inheritメソッドを使って、他の(多分親の)
スレッドのネスト化診断コンテキストを継承するかもしれません。
スレッドは、cloneStackメソッドを使ってNDCのコピーを
取得し、他のスレッド、特に子への参照を渡すかもしれません。
| メソッドの概要 | |
static void |
clear()
Clear any nested diagnostic information if any. |
static Stack |
cloneStack()
Clone the diagnostic context for the current thread. |
static String |
get()
Used when printing the diagnostic context. |
static int |
getDepth()
Get the current nesting depth of this diagnostic context. |
static void |
inherit(Stack stack)
Inherit the diagnostic context of another thread. |
static String |
peek()
Looks at the last diagnostic context at the top of this NDC without removing it. |
static String |
pop()
Clients should call this method before leaving a diagnostic context. |
static void |
push(String message)
Push new diagnostic context information for the current thread. |
static void |
remove()
Remove the diagnostic context for this thread. |
static void |
setMaxDepth(int maxDepth)
Set maximum depth of this diagnostic context. |
| クラス java.lang.Object から継承したメソッド |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| メソッドの詳細 |
public static void clear()
もし存在する場合は、ネスト化診断コンテキストをクリアします。 このメソッドは、同じスレッドが異なる関連性のないコンテキスト内で 潜在的に延々と使われるような場合に役立ちます。
This method is equivalent to calling the setMaxDepth(int)
method with a zero maxDepth argument.
このメソッドは、0 maxDepth引数を使う setMaxDepth(int)を
呼び出すのと同じです。
public static Stack cloneStack()
現在スレッドに対する診断コンテキストのクローンを生成します。
Internally a diagnostic context is represented as a stack. A given thread can supply the stack (i.e. diagnostic context) to a child thread so that the child can inherit the parent thread's diagnostic context.
内部的には、診断コンテキストは、スタックとして表します。 渡されるスレッドは、子が親スレッドの診断コンテキストを継承するために 子スレッドに対しスタック(例えば、診断コンテキスト)を提供します。
The child thread uses the inherit method to
inherit the parent's diagnostic context.
子スレッドは親の診断コンテキストを継承するために、inheritを
使用します。
Stack 現在のスレッドの診断コンテキストのクローン
public static void inherit(Stack stack)
他のスレッドの診断コンテキストを継承します。
The parent thread can obtain a reference to its diagnostic
context using the cloneStack() method. It should
communicate this information to its child so that it may inherit
the parent's diagnostic context.
親のスレッドは、cloneStack()メソッドを使って診断コンテキストの
参照を取得します。
親の診断コンテキストを継承するために子へ情報を伝達する必要があります。
The parent's diagnostic context is cloned before being inherited. In other words, once inherited, the two diagnostic contexts can be managed independently.
親の診断コンテキストは、継承される前にクローン化されます。 言い換えると、いったん継承されると、2つの診断コンテキストが、 独立して管理されるということです。
In java, a child thread cannot obtain a reference to its parent, unless it is directly handed the reference. Consequently, there is no client-transparent way of inheriting diagnostic contexts. Do you know any solution to this problem?
Javaでは、子のスレッドが参照を直接処理しない限り、親への参照を取得できません。 そういうわけで、継承する診断コンテキストの client-transparent の方法はありません。 あなたは、この問題への解決方法を知ってますか?
stack - The diagnostic context of the parent thread.
stack 親スレッドの診断コンテキスト
public static String get()
診断コンテキストを出力する時に使用されます。
public static int getDepth()
診断コンテキストの現在のネストの深度を取得します。
setMaxDepth(int)public static String pop()
クライアントは、診断コンテキストを除去する前にこのメソッドを呼び出す必要があります。
The returned value is the value that was pushed last. If no context is available, then the empty string "" is returned.
戻り値は、最後にプッシュされた値です。 もし、利用できるコンテキストがない場合は、空の文字列 "" が返されます。
String 最も奥にある診断コンテキスト
public static String peek()
診断コンテキストを削除せず、NDCの上位で最後の診断コンテキストを見ます。
The returned value is the value that was pushed last. If no context is available, then the empty string "" is returned.
戻り値は、最後にプッシュされた値です。 もし、利用できるコンテキストがない場合は、空の文字列 "" が返されます。
String 最も奥にある診断コンテキスト
public static void push(String message)
現在のスレッドに対し新しい診断コンテキスト情報をプッシュします。
The contents of the message parameter is
determined solely by the client.
messageパラメタの内容は、クライアントによって一意に決められます。
message - The new diagnostic context information.
message 新規の診断コンテキスト情報
public static void remove()
このスレッドに対する診断コンテキストを削除します。
Each thread that created a diagnostic context by calling
push(java.lang.String) should call this method before exiting. Otherwise,
the memory used by the thread cannot be reclaimed by the
VM.
push(java.lang.String)を呼び出すことで診断コンテキストを作成したスレッドは、
終了する前にこのメソッドを呼び出します。
そうでない場合は、スレッドで使われたメモリは、VMにより要求される
ことはありません。
As this is such an important problem in heavy duty systems and
because it is difficult to always guarantee that the remove
method is called before exiting a thread, this method has been
augmented to lazily remove references to dead threads. In
practice, this means that you can be a little sloppy and
occasionally forget to call remove() before exiting a
thread. However, you must call remove sometime. If
you never call it, then your application is sure to run out of
memory.
大量の処理をもつシステムでは、重要な問題です。
削除メソッドが、スレッドを終了する前に必ず呼び出されるというのを保証するのは難しいので、
このメソッドは、死んだスレッドへの参照を怠けて削除しようとします。
実際、これは、あなたが、ちょっといいかげんで、スレッドを終了する前に、
remove()を呼び出すのを時々忘れる可能性があることを意味しています。
しかし、あなたは、ときどきは、removeを呼び出す必要があります。
もし、呼び出さなかった場合、あなたのアプリケーションは
確実にメモリ不足となります。
public static void setMaxDepth(int maxDepth)
maxDepth, then no
action is taken.
この診断コンテキストの最大深度を設定します。
もし、現状の深度が、maxDepthより小さいか、等しい場合は、
アクションは、起きません。
This method is a convenient alternative to multiple pop() calls. Moreover, it is often the case that at the end of
complex call sequences, the depth of the NDC is
unpredictable. The setMaxDepth method circumvents
this problem.
このメソッドは、複数の pop()呼び出しにとって都合のいい選択肢です。
その上、複雑な呼び出しシーケンスの最後でNDCの深度は、予測できません。
setMaxDepthメソッドは、この問題を防ぎます。
For example, the combination
例えば、組み合わせとして以下のようになります。
void foo() {
int depth = NDC.getDepth();
... complex sequence of calls
NDC.setMaxDepth(depth);
}
ensures that between the entry and exit of foo the depth of the
diagnostic stack is conserved.
エントリとfooを抜ける間で診断スタックの深度が保持されていることを確かめてください。
getDepth()
|
||||||||||
| 前のクラス 次のクラス | フレームあり フレームなし | |||||||||
| 概要: 内部クラス | フィールド | コンストラクタ | メソッド | 詳細: フィールド | コンストラクタ | メソッド | |||||||||