Re: mod_jk logging buffer

2005-08-15 Thread Radek Wierzbicki
Hi,

the problem is not only a delay but also an order of the messages. I
think all messages should be flushed to the file as soon as they come.

When I choosing to log 'info' messages I accept the fact that it will
slow down the processing of requests. That is always a drawback of
logging. The users should be aware of this.

I have never see apache server showing log entries in a wrong order or
delayed? Then why delay it in mod_jk??

By not flushing output immediatelly you are shirnking the functionality
of logging mechanism.

-- Radek


Mladen Turk wrote:
 Jean-frederic Clere wrote:
 
 Radek Wierzbicki wrote:

 Hello,


 better :
 if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG ||
 level==JK_LOG_ERROR)
 No?

 
 Flush should not be executed for INFO level. It slows the things
 down by the factor of 2. I agree for ERROR and EMERG.
 DEBUG and TRACE uses fflush so the order of messages can be traced,
 but that is also dubious because the messages could come from
 different threads, so the best would be to use the fflush only
 with ERROR and EMERGE levels.
 
 Regards,
 Mladen.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk logging buffer

2005-08-14 Thread Jean-frederic Clere

Mladen Turk wrote:


Jean-frederic Clere wrote:


Radek Wierzbicki wrote:


Hello,



better :
if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || 
level==JK_LOG_ERROR)

No?



Flush should not be executed for INFO level. It slows the things
down by the factor of 2. I agree for ERROR and EMERG.
DEBUG and TRACE uses fflush so the order of messages can be traced,
but that is also dubious because the messages could come from
different threads, so the best would be to use the fflush only
with ERROR and EMERGE levels.


So it is OK to commit the following:
++
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
retrieving revision 1.71
diff -u -r1.71 jk_util.c
--- common/jk_util.c1 Jul 2005 15:41:08 -   1.71
+++ common/jk_util.c14 Aug 2005 18:28:29 -
@@ -186,7 +186,7 @@
fwrite(what, 1, sz, p-logfile);
fputc('\n', p-logfile);
/* [V] Flush the dam' thing! */
-if (l-level  JK_LOG_INFO_LEVEL)
+if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || 
level==JK_LOG_ERROR)

fflush(p-logfile);
}

++
isn't it?



Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk logging buffer

2005-08-12 Thread Radek Wierzbicki

Hello,

I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger 
buffers and delays the output of messages with levels below 'info' 
(info, warning, error, emergency, request).


With the new version, setting the log level to 'error' on production 
setups will delay the output of critical error messages. I think that is 
unacceptable.


Wouldn't it make sense to reverse the logic and immediatelly flush the 
log messages with level 'info' and below, and buffer 'debug' and 'trace' 
messages?


Maybe a configuration option for log buffering would make sense?

Patch:

--- jk_util.c.orig  2005-07-01 17:41:08.0 +0200
+++ jk_util.c   2005-08-12 13:44:01.0 +0200
@@ -186,7 +186,7 @@
 fwrite(what, 1, sz, p-logfile);
 fputc('\n', p-logfile);
 /* [V] Flush the dam' thing! */
-if (l-level  JK_LOG_INFO_LEVEL)
+if (l-level  JK_LOG_DEBUG_LEVEL)
 fflush(p-logfile);
 }

... awaiting comments ...

-Radek W.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk logging buffer

2005-08-12 Thread Jean-frederic Clere

Radek Wierzbicki wrote:


Hello,

I see a problem with logging mechanism in mod_jk 1.2.14.1. The logger 
buffers and delays the output of messages with levels below 'info' 
(info, warning, error, emergency, request).


With the new version, setting the log level to 'error' on production 
setups will delay the output of critical error messages. I think that 
is unacceptable.


Wouldn't it make sense to reverse the logic and immediatelly flush the 
log messages with level 'info' and below, and buffer 'debug' and 
'trace' messages?


Maybe a configuration option for log buffering would make sense?

Patch:

--- jk_util.c.orig  2005-07-01 17:41:08.0 +0200
+++ jk_util.c   2005-08-12 13:44:01.0 +0200
@@ -186,7 +186,7 @@
 fwrite(what, 1, sz, p-logfile);
 fputc('\n', p-logfile);
 /* [V] Flush the dam' thing! */
-if (l-level  JK_LOG_INFO_LEVEL)
+if (l-level  JK_LOG_DEBUG_LEVEL)
 fflush(p-logfile);
 }

... awaiting comments ...


better :
if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || 
level==JK_LOG_ERROR)

No?



-Radek W.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk logging buffer

2005-08-12 Thread Mladen Turk

Jean-frederic Clere wrote:

Radek Wierzbicki wrote:


Hello,



better :
if (l-level  JK_LOG_INFO_LEVEL || level==JK_LOG_EMERG || 
level==JK_LOG_ERROR)

No?



Flush should not be executed for INFO level. It slows the things
down by the factor of 2. I agree for ERROR and EMERG.
DEBUG and TRACE uses fflush so the order of messages can be traced,
but that is also dubious because the messages could come from
different threads, so the best would be to use the fflush only
with ERROR and EMERGE levels.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]