mod_jk logging buffer
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
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]
Tomcat metrics
Howdy, This is just information for the curious or bored ;) I was asked earlier today how many LOC are in Tomcat right now. Since I didn't know off the top of my head, I plopped the source code of 5.5.10 into Eclipse, and using Metrics (http://metrics.sourceforge.net/) calculated it. I had to remove a couple of the Tomcat 3 packages to get things to compile, and of course this doesn't count the .jsp files and other things we might consider source code, so the result is only an approximation: 136K or so ;) For more interesting metrics, you can see the screenshot at http://www.flickr.com/photo_zoom.gne?id=33427988size=o. The metrics thing is a cool little tool. It also exports results in XML, but I didn't feel like sending that XML result file to this list, it's 6.4MB in size ;) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat metrics
Yoav Shapira wrote: Howdy, This is just information for the curious or bored ;) Right. Good for any school project ;) result is only an approximation: 136K or so ;) And webdav used 92K? Weird. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk logging buffer
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]
RE: Tomcat metrics
Hola, And webdav used 92K? Weird. Not quite: total lines of code in methods was 92K. The webdav class mentioned had the biggest method at 347 lines of code. (And to complete the line, the average method had 8.37 LOC with a stdev of 18.761 LOC) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36169] New: - [PATCH] Enable chunked encoding for IIS JK connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36169 Summary: [PATCH] Enable chunked encoding for IIS JK connector Product: Tomcat 5 Version: 5.0.28 Platform: Other OS/Version: Windows 2000 Status: NEW Keywords: PatchAvailable Severity: major Priority: P1 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] While looking through the JK connector code for the IIS integration, I found that Chunked support is never turned on. The JK codebase has support for chunked encoding, but the IIS-specific packaging doesn't have any code to enable this. Attached is a patch to enable this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36169] - [PATCH] Enable chunked encoding for IIS JK connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36169 --- Additional Comments From [EMAIL PROTECTED] 2005-08-12 20:05 --- Created an attachment (id=16023) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16023action=view) Patch enabling chunked transfer encoding for IIS -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36153] - html:form action is blank
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36153. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36153 --- Additional Comments From [EMAIL PROTECTED] 2005-08-12 20:19 --- I'm currently unable to test it in a 5.5.9 environment in production where I see this issue. I will be setting up a test box today to try using a 1.5x jdk, struts 1.2.7, and tomcat 5.5.x ... -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36172] New: - getCharacterEncoding destroys POST data
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36172.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36172
Summary: getCharacterEncoding destroys POST data
Product: Tomcat 5
Version: Unknown
Platform: Sun
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Connector:Coyote
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
It's a known problem that most web browsers don't indicate the encoding of the
POST data in an HTTP request. If they fail to provide this information (i.e.
request.getCharacterEncoding() == null), I would like to assume UTF-8. The
problem is, calling getCharacterEncoding() destroys the POST data, I assume in
an attempt to parse out an encoding or charset parameter. In any case, I can't
find any specification of a contract that says the inputStream or
getParameter*() may be invalid after getCharacterData() and this would rather
seem like a bad idea anyway.
Sample code for a servlet receiving form input via POST:
if ( request.getCharacterEncoding() == null ) {
request.setCharacterEncoding( UTF-8 );
}
out.println( request encoding: + request.getCharacterEncoding()
);
out.println( request content-type: + request.getContentType() );
out.println( request content len: + request.getContentLength() );
out.println( request parameters by Map );
out.println( request.getParameterMap() );
The map printed is empty. If the if block is removed and the encoding is always
set to UTF-8, the map is populated correctly. If the character encoding is not
set (and getCharacterEncoding is not called but would return null), the map is
also not correct. If working with the inputStream, read returns -1 under the
same conditions that the map is empty.
My server log contains the following entry for a logged Exception. Of course,
no Exception is allowed to propogate to the level of my code.
Unable to set request encoding
java.io.UnsupportedEncodingException: hidden_value
at sun.io.Converters.getConverterClass(Converters.java:215)
at sun.io.Converters.newConverter(Converters.java:248)
at sun.io.ByteToCharConverter.getConverter(ByteToCharConverter.java:64)
at java.lang.StringCoding.decode(StringCoding.java:226)
at java.lang.String.init(String.java:320)
at java.lang.String.init(String.java:346)
at
org.apache.coyote.tomcat5.CoyoteRequest$1.run(CoyoteRequest.java:1560)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.coyote.tomcat5.CoyoteRequest.setCharacterEncoding(CoyoteRequest.java:1557)
at
com.sun.enterprise.web.connector.coyote.PECoyoteRequest.setRequestEncoding(PECoyoteRequest.java:151)
at
com.sun.enterprise.web.connector.coyote.PECoyoteRequest.getCharacterEncoding(PECoyoteRequest.java:76)
at
org.apache.coyote.tomcat5.CoyoteRequestFacade.getCharacterEncoding(CoyoteRequestFacade.java:298)
at FormEchoServlet.echo(FormEchoServlet.java:51)
at FormEchoServlet.doPost(FormEchoServlet.java:37)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:767)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAsPrivileged(Subject.java:500)
at
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
at
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
at
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
at
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
at
DO NOT REPLY [Bug 36172] - getCharacterEncoding destroys POST data
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36172. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36172 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-12 22:36 --- This is an issue with the Sun app server. (Sun modify the Tomcat code before they use it). Looking at the stack trace, it seems a call to getCharacterEncoding() results in a call to setRequestEncoding() which then fails. The Tomcat connector code does not do this. If you can reproduce this on a vanilla Tomcat installation, please re-open this report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36108] - Bug with FormAuthenticator
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36108. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36108 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-08-12 23:34 --- This works with vanilla Tomcat and is therefore a JBoss issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36173] New: - AssertionFailure in java.util.GregorianCalendar.computeFields() when sending response
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36173. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36173 Summary: AssertionFailure in java.util.GregorianCalendar.computeFields() when sending response Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Connector:HTTP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have occasional failed requests on our servers running tomcat 5.0.19 (working under java 1.5.0 with system assertions enabled via -esa option). This also seams to be an issue with newer versions of tomcat up to the current snapshot taken from the CVS repository. The following exception gets thrown: java.lang.AssertionError: cache control: inconsictency, cachedFixedDate=732122, computed=732107, date=2005-06-10T00:00:00.000Z at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2050) at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1971) at java.util.Calendar.setTimeInMillis(Calendar.java:1066) at java.util.Calendar.setTime(Calendar.java:1032) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:785) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:778) at java.text.DateFormat.format(DateFormat.java:314) at org.apache.tomcat.util.http.FastHttpDateFormat.getCurrentDate(FastHttpDateFormat.java:152) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1529) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:926) at org.apache.coyote.Response.action(Response.java:224) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:605) at org.apache.coyote.Response.doWrite(Response.java:586) at org.apache.coyote.tomcat5.OutputBuffer.realWriteBytes(OutputBuffer.java:411) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:436) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:356) at org.apache.coyote.tomcat5.OutputBuffer.writeBytes(OutputBuffer.java:444) at org.apache.coyote.tomcat5.OutputBuffer.write(OutputBuffer.java:431) at org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.java:108) at org.apache.coyote.tomcat5.CoyoteOutputStream.write(CoyoteOutputStream.java:102) at com.scene7.is.ImageServlet.sendResponse(ImageServlet.java:197) at com.scene7.is.ImageServlet.doGet(ImageServlet.java:147) at javax.servlet.http.HttpServlet.service(HttpServlet.java:743) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:257) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:199) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:184) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:578) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:567) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at
