cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java
remm2004/09/10 00:28:58
Modified:catalina/src/share/org/apache/catalina/authenticator Tag:
TOMCAT_5_0 FormAuthenticator.java
Log:
- Port patch.
- Set the notes even when caching. This is harmless from a performance standpoint,
but since the principal might not be serializable
it would cause issues with SSO and clustering.
- Submitted by Brian Stransberry.
Revision ChangesPath
No revision
No revision
1.9.2.1 +9 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.9
retrieving revision 1.9.2.1
diff -u -r1.9 -r1.9.2.1
--- FormAuthenticator.java31 Mar 2004 08:34:53 - 1.9
+++ FormAuthenticator.java10 Sep 2004 07:28:57 - 1.9.2.1
@@ -176,6 +176,12 @@
register(request, response, principal, Constants.FORM_METHOD,
(String) session.getNote(Constants.SESS_USERNAME_NOTE),
(String) session.getNote(Constants.SESS_PASSWORD_NOTE));
+// If we're caching principals we no longer need the username
+// and password in the session, so remove them
+if (cache) {
+session.removeNote(Constants.SESS_USERNAME_NOTE);
+session.removeNote(Constants.SESS_PASSWORD_NOTE);
+}
if (restoreRequest(request, session)) {
if (log.isDebugEnabled())
log.debug(Proceed to restored request);
@@ -256,10 +262,8 @@
session.setNote(Constants.FORM_PRINCIPAL_NOTE, principal);
// If we are not caching, save the username and password as well
-if (!cache) {
-session.setNote(Constants.SESS_USERNAME_NOTE, username);
-session.setNote(Constants.SESS_PASSWORD_NOTE, password);
-}
+session.setNote(Constants.SESS_USERNAME_NOTE, username);
+session.setNote(Constants.SESS_PASSWORD_NOTE, password);
// Redirect the user to the original request URI (which will cause
// the original request to be restored)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2004/09/10 00:33:53 Modified:webapps/docs Tag: TOMCAT_5_0 changelog.xml Log: - Update changelog. Revision ChangesPath No revision No revision 1.70.2.32 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.70.2.31 retrieving revision 1.70.2.32 diff -u -r1.70.2.31 -r1.70.2.32 --- changelog.xml 3 Sep 2004 18:21:28 - 1.70.2.31 +++ changelog.xml 10 Sep 2004 07:33:53 - 1.70.2.32 @@ -66,6 +66,9 @@ fix bug29914/bug: Better lifecycle support for DefaultContext. (yoavs) /fix + fix +Set the FORM notes even when caching so that clustering with SSO works properly. (remm) + /fix /changelog /subsection subsection name=Webapps - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30324] - ERROR [JkCoyoteHandler] Error in action code
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=30324. 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=30324 ERROR [JkCoyoteHandler] Error in action code --- Additional Comments From [EMAIL PROTECTED] 2004-09-10 09:52 --- I get a similar error using Tomcat 5.0.19 and JK2 on Suse 9.1 /jesper 10-Sep-2004 10:39:28 org.apache.jk.server.JkCoyoteHandler action SEVERE: Error in action code java.net.SocketException: Broken pipe at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:489) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:697) at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:487) at org.apache.coyote.Response.action(Response.java:226) at org.apache.coyote.Response.finish(Response.java:348) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:344) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:415) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:716) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:650) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:829) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:688) at java.lang.Thread.run(Thread.java:534) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 30324] -
SexyMonk Entertainment International Limited Website: 1. http://cn.pg.photos.yahoo.com/ph/smtemp01/detail?.dir=/23d7.dnm=d34c.jpg 2. http://67.19.71.215 3. http://67.19.71.198 4. http://www.sexymonk.com 5. http://www1.sexymonk.com 6. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 11748] - Location header for redirection does not contain the port number
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=11748.
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=11748
Location header for redirection does not contain the port number
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2004-09-10 11:54 ---
there is an actual bug here. In HttpProcessor, when the Host: header has no port
(eg because the client is buggy as described above) the code does this:
if (n 0) {
if (connector.getScheme().equals(http)) {
request.setServerPort(80);
} else if (connector.getScheme().equals(https)) {
request.setServerPort(443);
}
if (proxyName != null)
request.setServerName(proxyName);
else
request.setServerName(value);
}
note that in the above only the proxyName is processed, not the proxyPort. In
other words, if you explicitly tell tomcat to ignore the host header and use
proxy host/port combo, it doesnt in this case, it only uses the host.
the code for host header handling *should* look like this:
} else if (header.equals(DefaultHeaders.HOST_NAME)) {
int n = value.indexOf(':');
// parse and apply host header
if (n 0) {
if (connector.getScheme().equals(http)) {
request.setServerPort(80);
} else if (connector.getScheme().equals(https)) {
request.setServerPort(443);
}
request.setServerName(value);
} else {
request.setServerName(value.substring(0, n).trim());
int port = 80;
try {
port = Integer.parseInt(value.substring(n+1).trim());
} catch (Exception e) {
throw new ServletException
(sm.getString
(httpProcessor.parseHeaders.portNumber));
}
request.setServerPort(port);
}
// apply proxy overrides
if (proxyName != null)
request.setServerName(proxyName);
if (proxyPort != 0)
request.setServerPort(proxyPort);
} ...
the intent here is that any proxy host/port settings are always applied.
We reproduced the problem following a link from Word 2000, linking to tomcat via
the axis tcpmon proxy. linking to any content that returns a redirect shows the
problem (eg http://host:port/foo; redirects to http://host:port/foo/;) Word
sends a host header without the port, obviously a bug, but tomcat's response
ignores the proxy settings due to the bug described above.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [ANN] Apache Jakarta Tomcat 5.5.1 Released
Hi, OK, then we have a difference of opinion. Have a good weekend ;) Yoav Shapira Millennium Research Informatics -Original Message- From: Joseph Shraibman [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 5:15 PM To: Tomcat Developers List Subject: Re: [ANN] Apache Jakarta Tomcat 5.5.1 Released Yes, it should be. More novice users will see problems with tomcat and not know how to fix it. Even if they read the release notes and see to avoid stability problems they won't connect the two because the problem results in a freeze of some threads, not an outright crash. Shapira, Yoav wrote: Hi, -1. The ASSUME_KERNEL is a suggestion meant at more advanced users and should not be imposed on everyone using RH9 by default. Yoav Shapira Millennium Research Informatics -Original Message- From: Joseph Shraibman [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 5:00 PM To: Tomcat Developers List Subject: Re: [ANN] Apache Jakarta Tomcat 5.5.1 Released The release notes say: Redhat Linux 9.0 users should use the following setting to avoid stability problems: export LD_ASSUME_KERNEL=2.4.1 This simple shell script can tell you if you are running redhat 9: if [ -f /etc/redhat-release ] grep -q Shrike /etc/redhat-release ; then echo is redhat 9 else echo is not redhat 9 fi So the following should be added to catalina.sh: if [ -f /etc/redhat-release ] grep -q Shrike /etc/redhat-release ; then export LD_ASSUME_KERNEL=2.4.1 fi Yoav Shapira wrote: The Apache Jakarta Tomcat team is proud to announce the immediate availability of Tomcat 5.5.1. This second build in the 5.5 branch contains a number of significant stability improvements over 5.5.0, as well as a host of documentation updates and minor fixes. Release notes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/RELEASE- NOTES Please refer to the change log for the list of changes: http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html Downloads: Binaries: http://jakarta.apache.org/site/binindex.cgi Sources: http://jakarta.apache.org/site/sourceindex.cgi The Apache Jakarta Tomcat Team - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25055] - bypass of apache authentication
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=25055. 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=25055 bypass of apache authentication --- Additional Comments From [EMAIL PROTECTED] 2004-09-10 13:52 --- The link to the same bug submitted in Apache 2 bugzilla. http://issues.apache.org/bugzilla/show_bug.cgi?id=29834 It can be reassigned, but I think the problem might lay - either in the mod_jk/mod_jk2 implementation for Apache 2 - or in the Apache 2 API ? So, it can be useful to leave it in both databases as long as we don't know which one is concerned... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31171] New: - ClassCastException in org.apache.jasper.runtime.PageContextImpl.getException
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=31171.
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=31171
ClassCastException in org.apache.jasper.runtime.PageContextImpl.getException
Summary: ClassCastException in
org.apache.jasper.runtime.PageContextImpl.getException
Product: Tomcat 5
Version: 5.0.19
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am writing to report a case where calling PageContextImpl.getException()
can result in a ClassCastException. This occurred in tomcat 5.0.19,
but examination of tomcat 5.0.28's source code, the problem could
occur there as well.
In my application, I have an jsp declared as an error page. This
error page uses a tag to record some additional information. The
first few lines of this tag are as follows:
public void doTag() throws IOException, JspException
{
try {
PageContext context = (PageContext)getJspContext();
JspWriter out = context.getOut();
HttpServletRequest request = (HttpServletRequest) context.getRequest();
Throwable error = context.getException();
// proceed to log the exception and some of the
// surrounding contextual information
In one case, the `catch' associated with this try caught a
ClassCastException from PageContextImpl.getException():
// line 608 in 5.0.19's PageContextImpl.java
// line 560 in 5.0.28's PageContextImpl.java
public Exception getException() { return (Exception)request.getAttribute(EXCEPTION);
}
This would occur if the error was a result of a java.lang.Throwable.
What possible paths might lead up to this?
The _jspService() generated by JspC typically terminates with
something like the following:
} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(t);
}
} finally {
if (_jspxFactory != null) _jspxFactory.releasePageContext(pageContext);
}
It's catching a Throwable.
PageContextImpl.handlePageException() (lines 730 - 745 in version
5.0.28) does this:
public void handlePageException(final Throwable t)
throws IOException, ServletException
{
if (t == null)
throw new NullPointerException(null Throwable);
if (System.getSecurityManager() != null){
try{
AccessController.doPrivileged(new PrivilegedExceptionAction(){
public Object run() throws Exception{
doHandlePageException(t);
return null;
}
});
It's dealing with throwables.
Continuing on to doHandlePageException(), (lines 763 - 786 in version
5.0.28):
private void doHandlePageException(Throwable t)
throws IOException, ServletException {
if (errorPageURL != null !errorPageURL.equals()) {
/*
* Set request attributes.
* Do not set the javax.servlet.error.exception attribute here
* (instead, set in the generated servlet code for the error page)
* in order to prevent the ErrorReportValve, which is invoked as
* part of forwarding the request to the error page, from
* throwing it if the response has not been committed (the response
* will have been committed if the error page is a JSP page).
*/
request.setAttribute(javax.servlet.jsp.jspException, t);
request.setAttribute(javax.servlet.error.status_code,
new Integer(HttpServletResponse.SC_INTERNAL_SERVER_ERROR));
request.setAttribute(javax.servlet.error.request_uri,
((HttpServletRequest) request).getRequestURI());
request.setAttribute(javax.servlet.error.servlet_name,
config.getServletName());
try {
forward(errorPageURL);
It's also dealing with Throwables.
The following two (short) jsp files reproduce the problem consistently.
--- Page: foo.jsp ---
%@ page session=false
language=java
errorPage=/myerror.jsp
%
htmlbodyhello world/body/html
%
if (1 + 1 == 2) {
throw new Throwable(The cake fell in the mud);
}
%
--
--- Page: myerror.jsp
!-- myerror.jsp --
%@ page
DO NOT REPLY [Bug 31172] New: - Memory leak in Clustered environment
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=31172. 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=31172 Memory leak in Clustered environment Summary: Memory leak in Clustered environment Product: Tomcat 5 Version: 5.0.19 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We've recently moved our code from Tomcat 3.3 (running for 2+ yrs)to Tomcat 5.0.19 with session replication and have noticed memory leaks which we have not seen before in Tomcat 3.3. We have to restart the application everyday to prevent OutOfMemoryError problems. Could this be related to the session replication not clearing JavaGroups' message queue after it's been sent ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
luehe 2004/09/10 11:54:04 Modified:webapps/docs changelog.xml Log: Added average time an expired session had been alive to set of monitorable session manager attributes Revision ChangesPath 1.103 +3 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.102 retrieving revision 1.103 diff -u -r1.102 -r1.103 --- changelog.xml 9 Sep 2004 16:52:21 - 1.102 +++ changelog.xml 10 Sep 2004 18:54:04 - 1.103 @@ -105,6 +105,9 @@ add Added longest time an expired session had been alive to set of monitorable session manager attributes. (luehe) /add + add +Added average time an expired session had been alive to set of monitorable session manager attributes. (luehe) + /add fix Clear a reference in the digester where a context would be referenced for more time than it needed, until the next context deployment operation. (remm) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS Connector and chunked encoding
I've found what I believe is a bug in the 2.0.4 connector for IIS that prevents it from handling a POST with a transfer encoding of chunked properly. I did some searching across the bug database and couldn't find a direct hit on this issue, and had no luck on multiple googles either. This is the first time I've been in this code, so would love help/info from anyone that has worked with this source before with finishing this chase so I can submit a patch to any interested committer. My test case that causes the failure consists of a 56,662 byte text/xml POST with chunked encoding that gets passed to the Tomcat servlet as a 0 byte request with all the valid headers including the chunked transfer encoding one. I downloaded the 2.0.4 source and built a version of isapi_redirector2.dll with some extra logging messages that I added for diagnostics. The first issue that popped out is in module jk_service_iis.c. Method jk2_service_iis_initService initializes the jk_ws_service_t structure for my chunked request, but the is_chunked flag in that structure never gets set to 1. This causes the chunked content to be skipped in later code as the content length is -1 which causes 0 bytes to be read and passed to Tomcat. I found code in various places in multiple modules that rely on this flag being set, but I couldn't find anywhere that actually sets it. So then I added these two lines at line 391 of module jk_service_iis.c which is in method jk2_service_iis_initService) : if (s-content_length == -1) s-is_chunked = 1; This version read all the content from the incoming POST. Unfortunately I have more chasing to do yet because the data that gets passed on to Tomcat from the filter includes my entire payload of 56,662 bytes, followed by repeating junk for a total length of 57302. The trace shows it read too many bytes: [Fri Sep 10 12:43:21 2004] (debug ) [jk_service_iis.c (216)] jk_ws_service_t::read actually readed 0 from already 57302 of total -1 bytes 57302 = 7 blocks of 8186 bytes each. 8186 is the number of bytes read by the filter in each block from the chunked POST. So there's still some issue left to get it to properly handle the end of the message that I'm still chasing when the message length is not an exact multiple of 8186. Once I have the end-of-chunked-message-byte-count issue chased and have a final patch to propose, I'll post again. But I'd love to hear from anyone that's familiar with this code to get input on whether this patch is valid, whether you feel I'm heading in a decent direction, whether someone else has already worked this and I just haven't seen it, etc. Thanks in advance for any info/tips. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS Connector and chunked encoding
[EMAIL PROTECTED] wrote: I've found what I believe is a bug in the 2.0.4 connector for IIS that prevents it from handling a POST with a transfer encoding of chunked Issue been mentioned couple of times: http://www.apache.org/~mturk/isapi_redirector2.zip This is 2.0.5 pre-release (if the 2.0.5 ever sees daylight :). Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
cvs commit: jakarta-tomcat-catalina/modules/cluster to-do.txt
fhanik 2004/09/10 14:52:32 Added: modules/cluster to-do.txt Log: to do list for clusters Revision ChangesPath 1.1 jakarta-tomcat-catalina/modules/cluster/to-do.txt Index: to-do.txt === 1. Fix farm deployment for 5.5 2. Extend StandardSession if possible 3. Implement primary/secondary replication logic 4. Implement fragmentation of large replication objects 5. Implementa NonSerializable interface for session attributes that do not wish to be replicated 6. Implement context attribute replication (?) 7. JMX friendly 8. Documentation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster to-do.txt
[EMAIL PROTECTED] wrote: fhanik 2004/09/10 14:52:32 Added: modules/cluster to-do.txt Log: to do list for clusters Revision ChangesPath 1.1 jakarta-tomcat-catalina/modules/cluster/to-do.txt Index: to-do.txt === 1. Fix farm deployment for 5.5 2. Extend StandardSession if possible 3. Implement primary/secondary replication logic This is a good set of priorities. +1. 4. Implement fragmentation of large replication objects 5. Implementa NonSerializable interface for session attributes that do not wish to be replicated 6. Implement context attribute replication (?) I have no idea what this is either ;) 7. JMX friendly Stats ? :) 8. Documentation Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31172] - Memory leak in Clustered environment
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=31172. 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=31172 Memory leak in Clustered environment [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |High - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
