cvs commit: jakarta-tomcat-5 build.properties.default
remm2003/11/06 02:57:51
Modified:.build.properties.default
Log:
- New Xerces 2.5.0 location.
Revision ChangesPath
1.111 +2 -2 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.110
retrieving revision 1.111
diff -u -r1.110 -r1.111
--- build.properties.default 23 Oct 2003 17:33:32 - 1.110
+++ build.properties.default 6 Nov 2003 10:57:51 - 1.111
@@ -127,7 +127,7 @@
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.5.0.tar.gz
+xerces.loc=http://archive.apache.org/dist/xml/xerces-j/binaries/Xerces-J-bin.2.5.0.tar.gz
# --
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] New: - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 Summary: mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 Product: Tomcat 4 Version: 4.1.27 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm would like to report a file descriptor leak that occurs with Apache-1.3.28 and mod_jk-1.2.5 on Solaris 7 and Solaris 8. Both Apache and mod_jk were compiled from sources. mod_jk is being used as DSO (not statically linked). The problem appears when apache is restarted via SIGHUP (aka apachectl restart) SIGUSR1 (apachectl graceful). Each time the server is signaled, the parent server process will have open one additional file descriptor for each file given in a JkLogFile directive. Below is a short series of annotated lsof output that shows the behavior. For this, two JkLogFile directives are use; each in a different VirtualHost container element. (However, the same behavior also exists when JkLogFile is used at the server config level, outside of any container elements). ## ## lsof output after a cold start of Apache, filtered to include only ## files matching _jk. /etc/httpd.pid is the file named by the ## servers PidFile directive. ## ## logs/localhost/one_mod_jk_log and logs/localhost/two_mod_jk_log ## are the files named by JkLogFile. JkLogFile appears twice in ## the server configuration. No requests have been made to the server. ## $ lsof -p `cat /etc/httpd.pid ` | grep _jk COMMAND PID USER FD TYPEDEVICE SIZE/OFF NODE NAME httpd 21307 root txt VREG 136,0 834728 958215 /l/apache/libexec/mod_jk.so httpd 21307 root4u VREG 136,0 3023 848146 /l/apache/logs/localhost/two_mod_jk_log httpd 21307 root5u VREG 136,0 3023 848147 /l/apache/logs/localhost/one_mod_jk_log httpd 21307 root6u VREG 136,0 3023 848146 /l/apache/logs/localhost/two_mod_jk_log httpd 21307 root7u VREG 136,0 3023 848147 /l/apache/logs/localhost/one_mod_jk_log ## ## SIGHUP server; then another snapshot of files containing _jk. ## Below, where two descriptors were open to one_mod_jk_log, there ## are now three. Likewise, where there were two descriptors open ## to two_mod_jk_log there are also three. ## $ kill -HUP `cat /etc/httpd.pid ` $ lsof -p `cat /etc/httpd.pid ` | grep _jk httpd 21307 root txt VREG 136,0 834728 958215 /l/apache/libexec/mod_jk.so httpd 21307 root4u VREG 136,0 5028 848146 /l/apache/logs/localhost/two_mod_jk_log httpd 21307 root5u VREG 136,0 5029 848147 /l/apache/logs/localhost/one_mod_jk_log httpd 21307 root6u VREG 136,0 5028 848146 /l/apache/logs/localhost/two_mod_jk_log httpd 21307 root7u VREG 136,0 5029 848147 /l/apache/logs/localhost/one_mod_jk_log httpd 21307 root8u VREG 136,0 5028 848146 /l/apache/logs/localhost/two_mod_jk_log httpd 21307 root9u VREG 136,0 5029 848147 /l/apache/logs/localhost/one_mod_jk_log A subsequence SIGHUP (or SIGUSR1) will result in allocation of one more file descriptor per each file named by JkLogFile. (i.e. - the more times JkLogFile is used, the faster it leaks). Eventually, successive SIGHUPs will exhaust the number of descriptors available to the server, causing it to crash. In my particular case, this would occur during nightly log rotations. A few days ago, I brought this issue up on the tomcat-users mailing list: http://marc.theaimsgroup.com/?t=106797123900012r=1w=2 However, none of the respondents indicated whether they had, or had not observed this behavior in their own installations. Finally, mod_jk-1.2.3 also exhibits the same behavior. If there's additional information needed, I would be happy to provide it. Likewise, if I could assist the maintainers by performing some additional testing, I would be more than happy to do so. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
web.xml editor
Hi, I would like to know if Tomcat Team has plans to build a web app that helps the developer to edit the web.xml file descriptor of the web apps deployed at Tomcat. Luiz Ricardo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: web.xml editor
Howdy, No. Any XML editor can do that for you. There are many, like XMLmind or XMLSpy, and a lot of general editors like JEdit or TextPad that can do it as well. Yoav Shapira Millennium ChemInformatics -Original Message- From: Luiz Ricardo [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 9:36 AM To: [EMAIL PROTECTED] Subject: web.xml editor Hi, I would like to know if Tomcat Team has plans to build a web app that helps the developer to edit the web.xml file descriptor of the web apps deployed at Tomcat. Luiz Ricardo - 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 24455] - allow to override 'cookies=false' on a per user/session basis.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24455 allow to override 'cookies=false' on a per user/session basis. [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW Summary|allow to override |allow to override |'cookies=false' on a per |'cookies=false' on a per |session basis. |user/session basis. --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 15:50 --- As per http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1, cookies=false appears to apply only to persistent cookies. Thus the use-case would be slightly different from my initial description, but still a valid one, I hope ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
luehe 2003/11/06 10:23:20
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
Moved the adjustment of maxThreads settings 10 from setMaxThreads()
to adjustLimits()
Revision ChangesPath
1.17 +6 -8
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ThreadPool.java 3 Nov 2003 21:54:24 - 1.16
+++ ThreadPool.java 6 Nov 2003 18:23:20 - 1.17
@@ -201,14 +201,7 @@
}
public void setMaxThreads(int maxThreads) {
-if (maxThreads MAX_THREADS_MIN) {
-log.warn(sm.getString(threadpool.max_threads_too_low,
- new Integer(maxThreads),
- new Integer(MAX_THREADS_MIN)));
-this.maxThreads = MAX_THREADS_MIN;
-} else {
-this.maxThreads = maxThreads;
-}
+this.maxThreads = maxThreads;
}
public int getMaxThreads() {
@@ -477,6 +470,11 @@
protected void adjustLimits() {
if(maxThreads = 0) {
maxThreads = MAX_THREADS;
+} else if (maxThreads MAX_THREADS_MIN) {
+log.warn(sm.getString(threadpool.max_threads_too_low,
+ new Integer(maxThreads),
+ new Integer(MAX_THREADS_MIN)));
+maxThreads = MAX_THREADS_MIN;
}
if(maxSpareThreads = maxThreads) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/res LocalStrings.properties
luehe 2003/11/06 11:05:23
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
util/java/org/apache/tomcat/util/threads/res
LocalStrings.properties
Log:
More i18n: added 'threadpool.thread_error' error code
Revision ChangesPath
1.18 +6 -5
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ThreadPool.java 6 Nov 2003 18:23:20 - 1.17
+++ ThreadPool.java 6 Nov 2003 19:05:23 - 1.18
@@ -647,7 +647,7 @@
try {
while(true) {
try {
- /* Wait for work. */
+/* Wait for work. */
synchronized(this) {
if(!shouldRun !shouldTerminate) {
this.wait();
@@ -683,8 +683,9 @@
}
}
} catch(Throwable t) {
- p.log.error(Caught exception executing + toRun.toString() +
, terminating thread, t);
-/*
+ p.log.error(sm.getString(threadpool.thread_error,
+ t, toRun.toString()));
+ /*
* The runnable throw an exception (can be even a
ThreadDeath),
* signalling that the thread die.
*
@@ -698,8 +699,8 @@
if(shouldRun) {
shouldRun = false;
/*
- * Notify the pool that the thread is now idle.
-*/
+ * Notify the pool that the thread is now idle.
+ */
p.returnController(this);
}
}
1.3 +2 -1
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/res/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/res/LocalStrings.properties,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- LocalStrings.properties 3 Nov 2003 21:54:24 - 1.2
+++ LocalStrings.properties 6 Nov 2003 19:05:23 - 1.3
@@ -1,2 +1,3 @@
threadpool.busy=All threads ({0}) are currently busy, waiting. Increase maxThreads
({1}) or check the servlet status
-threadpool.max_threads_too_low=maxThreads setting ({0}) too low, set to {1}
\ No newline at end of file
+threadpool.max_threads_too_low=maxThreads setting ({0}) too low, set to {1}
+threadpool.thread_error=Caught exception ({0}) executing {1}, terminating thread
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24478] New: - Incorrect usage of perl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24478. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24478 Incorrect usage of perl Summary: Incorrect usage of perl Product: Tomcat 4 Version: 4.1.29 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Servlets:CGI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CGIServlet always attempts to use perl to execute any CGI command (line 1585). This obviously causes problems for non-Perl CGI scripts. Moreover, all parameters passed to the Perl interpreter enclosed in quotation marks (lines 1566 and 1571). This prevents the Perl interpreter from finding the command. [Sorry, no diffs, I am not setup to build Tomcat.] To illustrate, here are a few lines from the debug log: 2003-11-06 18:29:17 cgi: findCGI: path=/printenv.cgi, /usr/local/www/data/WEB-INF/cgi 2003-11-06 18:29:17 cgi: findCGI: currentLoc=/usr/local/www/data/WEB-INF/cgi 2003-11-06 18:29:17 cgi: findCGI: currentLoc=/usr/local/www/data/WEB-INF/cgi 2003-11-06 18:29:17 cgi: findCGI: FOUND cgi at /usr/local/www/data/WEB-INF/cgi/printenv.cgi 2003-11-06 18:29:17 cgi: findCGI calc: name=printenv.cgi, path=/usr/local/www/data/WEB-INF/cgi/printenv.cgi, scriptname=/cgi-bin/printenv.cgi, cginame=/printenv.cgi [clipped long environment dump] 2003-11-06 18:29:17 cgi: runCGI (stderr):Can't open perl script /usr/local/www/cgi-bin.default/printenv.cgi: No such file or directory 2003-11-06 18:29:17 cgi: runCGI: 1 lines received on stderr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24478] - Incorrect usage of perl
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24478. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24478 Incorrect usage of perl --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 20:22 --- The quotes are there to fix bug22857. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4543] - RMI fails if tomcat is installed in directory with white space
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4543. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4543 RMI fails if tomcat is installed in directory with white space --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 21:01 --- Even thought, it is a problem with URL class, you can get around by using getURI () of File class. For example, jakarta-tomcat-4.0 \catalina\src\share\org\apache\catalina\startup\ClassLoaderFactory.java has following line: URL url = new URL(file, null, file.getCanonicalPath()); I solved the malFormedURL issue by changing as following: URL url = file.toURI().toURL(); Hope this helps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24385] - text conversion fails with jsp:forward/param on linux server
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24385 text conversion fails with jsp:forward/param on linux server --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 21:33 --- request.getParameter() uses the request encoding when reading the parameters, while jsp:param in 4.1.x encodes the parameter with URLEncoder.encode(String), which uses the platform default encoding. If they are different, you'll likely get problem like this. Try setting the request encoding to the platform default encoding by inserting a % request.setCharacterEncoding(ISO-8859-1); % at the beginning of test1.jsp. Alternately, you can also use JSTL: fmt:requestEncoding value=ISO-8859-1/ This bug is unlikely to get fixed for 4.1.x, since the JSP 1.2 spec is unclear regarding parameter encodings. JSP 2.0 specifies that the jsp:param values should be encoded with the request encoding, so Tomcat 5 might work better for you. Since most browsers do not set request encodings, you are still advised to explictily set it with request.setCharacterEncoding(), but then you can set it anything other than the platform default, such as UTF-8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: web.xml editor
Le jeu 06/11/2003 à 15:47, Shapira, Yoav a écrit : Howdy, No. Any XML editor can do that for you. There are many, like XMLmind or XMLSpy, and a lot of general editors like JEdit or TextPad that can do it as well. Yoav Shapira Millennium ChemInformatics http://pollo.sourceforge.net Is a generic XML editor, easily configurable ( XML Schema ) to edit any XML File. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java
amyroh 2003/11/06 15:43:18
Modified:catalina/src/share/org/apache/catalina/core
StandardHostValve.java
catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
Log:
Apply patch for bugzilla 9723 and bugtraq 4701571 - Avoid unneccessray calls to
RequestUtil.filter.
Patch submitted by Arvind Srinivasan[EMAIL PROTECTED]
Revision ChangesPath
1.12 +7 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Index: StandardHostValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- StandardHostValve.java2 Sep 2003 21:22:04 - 1.11
+++ StandardHostValve.java6 Nov 2003 23:43:18 - 1.12
@@ -321,9 +321,6 @@
if (!(response.getResponse() instanceof HttpServletResponse))
return;
int statusCode = hresponse.getStatus();
-String message = RequestUtil.filter(hresponse.getMessage());
-if (message == null)
-message = ;
// Handle a custom error page for this status code
Context context = request.getContext();
@@ -337,6 +334,9 @@
ServletResponse sresp = response.getResponse();
sreq.setAttribute(Globals.STATUS_CODE_ATTR,
new Integer(statusCode));
+ String message = RequestUtil.filter(hresponse.getMessage());
+if (message == null)
+message = ;
sreq.setAttribute(Globals.ERROR_MESSAGE_ATTR, message);
sreq.setAttribute
(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR,
1.12 +8 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
Index: ErrorReportValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ErrorReportValve.java 12 Sep 2003 13:17:06 - 1.11
+++ ErrorReportValve.java 6 Nov 2003 23:43:18 - 1.12
@@ -238,9 +238,6 @@
return;
HttpServletResponse hres = (HttpServletResponse) response;
int statusCode = hresponse.getStatus();
-String message = RequestUtil.filter(hresponse.getMessage());
-if (message == null)
-message = ;
// Do nothing on a 1xx, 2xx and 3xx status
if (statusCode 400)
@@ -265,6 +262,10 @@
}
+String message = RequestUtil.filter(hresponse.getMessage());
+if (message == null)
+message = ;
+
// Do nothing if there is no report for the specified status code
String report = null;
try {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9723] - Avoid unnecessary calls to RequestUtil.filter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9723. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9723 Avoid unnecessary calls to RequestUtil.filter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 00:15 --- Patch is applied to Tomcat 5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24314] - jk2/AJP13: jkstatus unsafely prints jk_stat-active
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24314. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24314 jk2/AJP13: jkstatus unsafely prints jk_stat-active --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 00:19 --- Created an attachment (id=8968) Make sure to null terminate what is treated as a string - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16901] - [PATCH] mod_jk2 wrong server port when using NAT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16901. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16901 [PATCH] mod_jk2 wrong server port when using NAT --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 00:21 --- Created an attachment (id=8969) I'll add my own patch, against CVS HEAD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24482] New: - DOC creating a patch example doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24482. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24482 DOC creating a patch example doesn't work Summary: DOC creating a patch example doesn't work Product: Tomcat 5 Version: Nightly Build Platform: All URL: http://jakarta.apache.org/tomcat/tomcat-4.1- doc/jk2/common/doccontrib.html OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Connector:JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The example command to create doco patch doesn't work, it lacks redirection (). It also doesn't quite look like the other examples on the page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24482] - DOC creating a patch example doesn't work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24482. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24482 DOC creating a patch example doesn't work --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 00:28 --- Created an attachment (id=8970) fix create patch example, CVS head - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 00:50 --- How are your logs config'ed? You have 3 log files, correct? Are all 3 of them seeing output? Crank up your debug level and verify that all 3 are actually active. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 03:00 --- Created an attachment (id=8971) JkLogFile excerpts showing file opens/closes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24462] - mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24462 mod_jk-1.2.5/Apache 1.3.28 - file descriptor leak on SIGHUP/SIGUSR1 --- Additional Comments From [EMAIL PROTECTED] 2003-11-07 03:02 --- How are your logs config'ed? Below are the log configuration directives for one vhost: VirtualHost 172.19.30.41 JkLogFile logs/localhost/one_mod_jk_log JkLogLevel debug /VirtualHost Below is the log configuration for the second virtual host: VirtualHost 172.19.30.41 JkLogFile logs/localhost/two_mod_jk_log JkLogLevel debug /VirtualHost (172.19.30.41 is a NameVirtualHost). These are the only JkLogFile directives. You have 3 log files, correct? Just two logfiles; but after sending apache successive SIGHUPs to apache, there are multiple file descriptors open to each logfile. (More SIGHUPs = more open descriptors to each file). Are all 3 of them seeing output? Both log files are seeing output. The output appears to be normal. Crank up your debug level and verify that all 3 are actually active. Both logfile are active -- looking at the logs themselves, they appear normal. I've done this as an experiment. Hopefully it will help. - raise log level to info (otherwise, same as shown above) - added a few calls to jk_log in jk_util.c; one in jk_open_file_logger(), immediately after the log file is opened, another in jk_close_file_logger, immediately before the file is closed. (Both log the logger's address, and fileno of it's FILE). Both of these lines contain the string SREVILAK. - stop Apache, delete logfiles. - Start apache, send a series of 5 sighups - Stop apache - Attached the contents of both JkLogFiles. Appended to that is a diff of jk_util.c, in case you want to see where the log statements are. This is the puzzling thing. Immediately after starting the server, file desriptors 5 7 were open to one_mod_jk_log. Immediately before stopping the server, file descriptors 5, 7, 9, 11, 13, 15 and 20. The logging I added seems to show each of the files getting an fclose(), but the descriptor is never released. :( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
Jan Luehe wrote: Bill Barker wrote: Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? This seems a possible use case, but is that really useful ? I would always put the connector at the engine level, personally. Regardless of where you put it, you still have one connector per V-Host IP address. I may be totally off here, but in the most common cases, all your domain names (one for each V-Host) will map to the same IP address, in which case you cannot have more than one Connector listening on the same port (if you do that, you'll get a java.net.BindException when starting the 2nd and so forth Connector). Not quite :-) It is common to have multiple IP addresses - either by using multiple ethernet cards, or by using ifconfig aliases. That's how virtual hosting worked in the old days, and it is still used if you want to support old clients ( or command line / other tools that don't include Host ). For vhost - it is probably valid to have different engines or configs for different vhosts. I think it would be a bad idea to use only the port ( which will be 80 for most hosts anyway ). If mangling the IPv6 address is not a solution, then we'll need some unique name or something. Costin You can only have more than one Connector listening on the same port when they're listening on different IP addresses on the same server. This is the case we need to resolve, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Connector ObjectName includes address
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 9:05 PM Subject: Re: Connector ObjectName includes address Jan Luehe wrote: Bill Barker wrote: Currently, connector objectname includes address in this format: domain:type=Connector,port=8080,address=0.0.0.0. This causes a problem when IPV6 addresses are used since IPV6 addresses include colons. The javax.management.ObjectName doesn't allow to have colon character in it and this causes javax.management.MalformedObjectNameException: ObjectName: invalid character ':' in value part of property. I propose to exclude address as connector objectname property since port number alone should keep the objectnames unique. What about the case where I have several V-Hosts, each with it's own Connector listening on port 80? This seems a possible use case, but is that really useful ? I would always put the connector at the engine level, personally. Regardless of where you put it, you still have one connector per V-Host IP address. I may be totally off here, but in the most common cases, all your domain names (one for each V-Host) will map to the same IP address, in which case you cannot have more than one Connector listening on the same port (if you do that, you'll get a java.net.BindException when starting the 2nd and so forth Connector). Not quite :-) It is common to have multiple IP addresses - either by using multiple ethernet cards, or by using ifconfig aliases. That's how virtual hosting worked in the old days, and it is still used if you want to support old clients ( or command line / other tools that don't include Host ). For vhost - it is probably valid to have different engines or configs for different vhosts. If the port happens to be 443 instead of 80, then that is still the way it works :-). You can't used NamedVirtualHosts with SSL. I think it would be a bad idea to use only the port ( which will be 80 for most hosts anyway ). If mangling the IPv6 address is not a solution, then we'll need some unique name or something. I'm surprised that this thread has lasted as long as it has. I'd just assumed that Amy would do something like replacing ':' in the address with, say, '%3a', and be done with it. I'm all for mangling the IPv6 address. Costin You can only have more than one Connector listening on the same port when they're listening on different IP addresses on the same server. This is the case we need to resolve, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More Admin Application: Service Reloading Question
I am evaluating Tomcat 5.0.14 for use in a ASP Hosting environment. As part of this environment I would need to routinely create (or destroy) virtual hosts. One major showstopper seems to be that if I create a virtual host and click on the Commit Changes, then the service reloads, including all of the virtual hosts, and their associated contexts. Is there some setting I don't see that can affect this restarting behavior? Without the capability to create virtual hosts on the fly, I will have to schedule routine re-starts of the servlet engine. This is really less than optimal. Any ideas would be appreciated. George Sexton MH Software, Inc. Voice: 303 438 9585 http://www.mhsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
