This is starting to sound complicated. I'd say go with the getpid(), since it
covers a major case and is pretty portable and simple.
Bill
--- GOMEZ Henri <[EMAIL PROTECTED]> wrote:
> Depend the OS:
>
> AS/400 =>
>
> int GetThreadId()
> {
> pthread_t lSelf = pthread_self()
>We could add the getpid() but what about Apache 2.0
>in MPM mode (threaded) ?
The getpid() isn't going to be very helpful in that case, but at least it
doesn't hurt.
Is there some other notion like a thread id that would be applicable to the
multithreaded Apache case?
Bill
__
Regarding logging the Apache child process id in mod_jk.log:
>Timestamp is already present in CVS.
>Did others modules add the pid ?
I am not sure, but the process id makes debugging a problem with an individual
Apache child much simpler, because it directs you to the events of interest.
Withou
>2) I suggest adding a timestamp to mod_jk-logging in jk_util.c. Logging
>without a timestamp is not very useful. (change 1 line, add 2 lines)
Yes, this is a must-have... the other thing that is really useful is the
Apache child process id. That way if one process gets stuck, you can get the
i
Thanks for your help, Marc.
Would it be possible to log a message to tomcat.log if the thread pool gets
exhausted? I believe the default Apache installation calls for 256 children,
so busy sites are going to run into this. A log message suggesting to
increase max_threads could save a lot of agg
After quite a bit of struggle, I think I found out what is going on. The
problem is that the default configuration of Tomcat does not have enough
threads in its thread pool for the default configuration of Apache. This
issue would only be apparent if many Apache children were in use.
The result
I've been testing Tomcat 3.2.2b3 and Apache 1.3 on Solaris, connected with
mod_jk. Things are generally working, but there is a serious problem that
occurs under load.
The problem is that certain Apache children get stuck talking to Tomcat. The
children are always requesting JSP pages. Using t
