Remove the jni worker from mod_jk
I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [SECURITY] CVE-2008-4308: Tomcat information disclosure vulnerability
Hi, Mark. > The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected I checked Tomcat 5.0.x source code and I've found that org.apache.coyote.http11.filters.SavedRequestInputFilter is NOT included. Does this mean Tomcat 5.0.x is not affected by this vulnerability? Advice, please. Kazu Nambo From: ma...@apache.org Subject: [SECURITY] CVE-2008-4308: Tomcat information disclosure vulnerability Date: Wed, 25 Feb 2009 23:17:37 + > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > CVE-2008-4308: Tomcat information disclosure vulnerability > > Severity: Low > > Vendor: > The Apache Software Foundation > > Versions Affected: > Tomcat 4.1.32 to 4.1.34 > Tomcat 5.5.10 to 5.5.20 > Tomcat 6.0.x is not affected > The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected > > Note: Although this vulnerability affects relatively old versions of > Apache Tomcat, it was only discovered and reported to the Apache Tomcat > Security team in October 2008. Publication of this issue was then > postponed until now at the request of the reporter. > > Description: > Bug 40771 (https://issues.apache.org/bugzilla/show_bug.cgi?id=40771) may > result in the disclosure of POSTed content from a previous request. For > a vulnerability to exist the content read from the input stream must be > disclosed, eg via writing it to the response and committing the > response, before the ArrayIndexOutOfBoundsException occurs which will > halt processing of the request. > > Mitigation: > Upgrade to: > 4.1.35 or later > 5.5.21 or later > 6.0.0 or later > > Example: > See original bug report for example of how to create the error condition. > > Credit: > This issue was discovered by Fujitsu and reported to the Tomcat Security > Team via JPCERT. > > References: > http://tomcat.apache.org/security.html > > Mark Thomas > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJpdGRb7IeiTPGAkMRAkK+AKC1m5WunqOmwuFYSYEoASF/AokgDQCffmxM > U3IdbfYNVtRIzCW5XTvhv2E= > =rJGg > -END PGP SIGNATURE- > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46802] Unable to locate mod_jk for 64-bit machine
https://issues.apache.org/bugzilla/show_bug.cgi?id=46802 Rainer Jung changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Rainer Jung 2009-03-05 00:31:43 PST --- The page says "IIS 5 and later". Also note, that http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.27/ia64/ contains the binaries for itanium systemas, and http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.27/amd64/ contains the ones for simple 64 Bit systems (AMD and Intel). Please post futher questions to the Tomcat users list before opening a new issue, or reopening this one. Regards, Rainer -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
On 05.03.2009 09:23, Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is very unlikely, that it still works (although I didn't test that) and we had a discussion long ago, that we'll drop the JNI worker latest when we do a new major release (and we never did one). I'm a little uncomfortable about dropping it before that, but actually before we decide, we should know, whether it is broken or not. If it is broken, we had to decide to either repair or drop, which might make the decision easier ;) Others? Did someone observe the use of the JNI worker in the wild during the last say 2 years? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Going for jk 1.2.28
On 05.03.2009 07:38, Mladen Turk wrote: Rainer Jung wrote: On 19.02.2009 16:39, Mladen Turk wrote: Hi, We have a bug in 1.2.27 that cause core in some configuration scenarios (#46352). The fix is in the SVN for more then a month. Beyond that there are two additional bug fixes one preventing Netware build, and other fixing IIS advanced configuration (#46579) There are also few valuable updates like dynamic contact address change for workers. Given all that I plan to go for a new release. I'll use our standard release system with pre-release build and then call for a vote giving 72 hours between each step. Comments, objections? Do you have more changes you want in 1.2.28, or are we done? Nope, that's it. Well, workers.properties auto reload for IIS, but that's too much for now thought. I think there's enough, and more makes breaking more likely. It would be good to have a smaller release after the big 1.2.27. Agreed. So I think we are now in a position for a dev testing tarball? Do you want to do the next steps, or should I? Feel free to roll, I'll create the bins as needed. OK, so I'll roll later today. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is already disabled by default. You need a special configure flag --enable-jni to include it in build. But I agree, it's unsupported and simply doesn't work. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Going for jk 1.2.28
On 05.03.2009 07:50, Mladen Turk wrote: Rainer Jung wrote: Do you want to do the next steps, or should I? BTW, I'd like that we this time use the common httpd 2.0 and 2.2 versions for producing the binaries. For 2.0 I'd suggest 2.0.52 (or 2.0.49) and for 2.2 version 2.2.3. For 1.3, 1.3.23 should be fine. All later versions have the same ABI so this would fit into the majority of httpd deployments. In theory for the platforms which use configure, one should add the --enable-api-compatibility switch to configure. This will activate defines in the mod_jk.c to not use post GA ABI features, even if the httpd you are building against has them. So that's a distribution build switch. I used it for my 1.2.27 builds. The fact that I'm still adding the used httpd info to the binaries file names is more like double safety net. Since the configure switch seems to work pretty well, and the httpd MMN versioning is very strict, we could drop that info from the file names, and simply put it into the text displayed below the file list, including the info, that the binaries should work with all httpd versions starting from I'll have another look at the MMN history, especially for 2.0 (for 2.2 this will work very well). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46802] Unable to locate mod_jk for 64-bit machine
https://issues.apache.org/bugzilla/show_bug.cgi?id=46802 --- Comment #2 from Rajat 2009-03-05 01:01:34 PST --- (In reply to comment #1) > The page says "IIS 5 and later". > > Also note, that > > http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.27/ia64/ > > contains the binaries for itanium systemas, and > > http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/jk-1.2.27/amd64/ > > contains the ones for simple 64 Bit systems (AMD and Intel). > > Please post futher questions to the Tomcat users list before opening a new > issue, or reopening this one. > > Regards, > > Rainer Hi Rainer, Thanks for your reply. Where can I get for Apache 2.0 or 2.2. The apache website has got ".so" file for win32 platform. http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.27/ Similarly I want for 64-bit platform. I tried building using VC++ but no luck.. I get error "Unable to open libapr.lib". Any help will be appreciated... Regards Rajat -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
Mladen Turk wrote: > Mark Thomas wrote: >> I stumbled across some code in trunk for this. I had a poke around and >> as far as >> I can tell this hasn't been supported for quite some time. What do >> people think >> about removing it from mod_jk and trunk? >> > > It is already disabled by default. You need a special configure flag > --enable-jni to include it in build. > But I agree, it's unsupported and simply doesn't work. Any objections to removing it then? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46802] Unable to locate mod_jk for 64-bit machine
https://issues.apache.org/bugzilla/show_bug.cgi?id=46802 --- Comment #3 from Rainer Jung 2009-03-05 01:18:19 PST --- Bugzilla is not a support forum. Please proceed this discussion on the users list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
On 05.03.2009 10:03, Mark Thomas wrote: Mladen Turk wrote: Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is already disabled by default. You need a special configure flag --enable-jni to include it in build. But I agree, it's unsupported and simply doesn't work. Any objections to removing it then? Not from me, I have never seen it used. Would it be good, to anounce the future removal in the 1.2.28 news and then do it in 1.2.29? Others? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
Rainer Jung wrote: On 05.03.2009 10:03, Mark Thomas wrote: Mladen Turk wrote: Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is already disabled by default. You need a special configure flag --enable-jni to include it in build. But I agree, it's unsupported and simply doesn't work. Any objections to removing it then? Not from me, I have never seen it used. Would it be good, to anounce the future removal in the 1.2.28 news and then do it in 1.2.29? Others? Yes, mark it as deprecated somehow. Perhaps a warning during configure and some note in docs. Also, instead removing it completely just use the empty stub, so that we don't need to change the makefiles and stuff. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Going for jk 1.2.28
Rainer Jung wrote: On 05.03.2009 07:50, Mladen Turk wrote: Rainer Jung wrote: Do you want to do the next steps, or should I? BTW, I'd like that we this time use the common httpd 2.0 and 2.2 versions for producing the binaries. For 2.0 I'd suggest 2.0.52 (or 2.0.49) and for 2.2 version 2.2.3. For 1.3, 1.3.23 should be fine. In theory for the platforms which use configure, one should add the --enable-api-compatibility switch to configure. This will activate defines in the mod_jk.c to not use post GA ABI features, even if the httpd you are building against has them. So that's a distribution build switch. If --enable-api-compatibily works, then the version number in binaries is wrong and makes users wonder weather it will work on previous versions or not. We should be clear about that thought. Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Going for jk 1.2.28
On 05.03.2009 10:38, Mladen Turk wrote: Rainer Jung wrote: On 05.03.2009 07:50, Mladen Turk wrote: Rainer Jung wrote: Do you want to do the next steps, or should I? BTW, I'd like that we this time use the common httpd 2.0 and 2.2 versions for producing the binaries. For 2.0 I'd suggest 2.0.52 (or 2.0.49) and for 2.2 version 2.2.3. For 1.3, 1.3.23 should be fine. In theory for the platforms which use configure, one should add the --enable-api-compatibility switch to configure. This will activate defines in the mod_jk.c to not use post GA ABI features, even if the httpd you are building against has them. So that's a distribution build switch. If --enable-api-compatibily works, then the version number in binaries is wrong and makes users wonder weather it will work on previous versions or not. We should be clear about that thought. I'm just in the process of clearing up the README files in dev/dist for 1.2.28 appropriately. You can use the same feature for your Windows builds, simply define API_COMPATIBILITY. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46764] Tomcat 6 and xmlValidation="false" not working
https://issues.apache.org/bugzilla/show_bug.cgi?id=46764
--- Comment #2 from Sergio Montesa 2009-03-05 02:52:19 PST
---
(In reply to comment #1)
> Can you please supply the simplest JSP that exhibits this error on a clean
> 6.0.18 installation.
My code is as follows:
URL urlXMLIdioma=new URL("http://machine.com/idioma.xml";);
org.w3c.dom.Document docIdioma=null;
org.xml.sax.InputSource isXMLIdioma=null;
javax.xml.parsers.DocumentBuilderFactory
docbfIdioma=javax.xml.parsers.DocumentBuilderFactory.newInstance();
docbfIdioma.setNamespaceAware(false);
docbfIdioma.setValidating(false);
isXMLIdioma=new org.xml.sax.InputSource(urlXMLIdioma.openStream());
isXMLIdioma.setEncoding("ISO-8859-1");
docIdioma=docbfIdioma.newDocumentBuilder().parse(isXMLIdioma);
The last line throws the exception: org.xml.sax.SAXParseException: The
declaration for the entity "HTML.Version" must end with '>'.
If "idioma.xml" not exists then server returns a 404 error page. The 404 page
begins like this:
http://www.w3.org/TR/html4/loose.dtd";>
...
and then the exception occurs.
Why? I disabled all xmlValidation (tomcat, in jsp, etc.)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r750420 - /tomcat/connectors/trunk/jk/native/configure.in
Author: rjung
Date: Thu Mar 5 11:13:05 2009
New Revision: 750420
URL: http://svn.apache.org/viewvc?rev=750420&view=rev
Log:
Mark jni related options as deprecated in the help
message and add a warning at the end of configure if
user enables jni.
Modified:
tomcat/connectors/trunk/jk/native/configure.in
Modified: tomcat/connectors/trunk/jk/native/configure.in
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/configure.in?rev=750420&r1=750419&r2=750420&view=diff
==
--- tomcat/connectors/trunk/jk/native/configure.in (original)
+++ tomcat/connectors/trunk/jk/native/configure.in Thu Mar 5 11:13:05 2009
@@ -421,11 +421,12 @@
dnl Check for enable-jni
JK_JNI_WORKER=""
AC_ARG_ENABLE(jni,
-[AS_HELP_STRING([--enable-jni],[Build jni_connect.so and enable jni_worker])],
+[AS_HELP_STRING([--enable-jni],[DEPRECATED: Build jni_connect.so and enable
jni_worker])],
[
AC_MSG_RESULT(jni enable (need JDK))
CFLAGS="${CFLAGS} -DHAVE_JNI"
JK_JNI_WORKER="\${JK}jk_jni_worker\${OEXT}"
+WARN_JNI=1
])dnl
AC_SUBST(JK_JNI_WORKER)
@@ -567,7 +568,7 @@
JAVA_PLATFORM="1"
AC_ARG_WITH(java-home,
-[AS_HELP_STRING([--with-java-home=DIR],[Where is your JDK root directory])],
+[AS_HELP_STRING([--with-java-home=DIR],[DEPRECATED: Where is your JDK root
directory])],
[
# This stuff works if the command line parameter --with-java-home was
@@ -670,7 +671,7 @@
AC_ARG_WITH(java-platform,
[AS_HELP_STRING([--with-java-platform=VAL],
-[Force the Java platform
+[DEPRECATED: Force the Java platform
(value is 1 for 1.1.x or 2 for 1.2.x or greater)])],
[
dnl This requires a bit of tweaking to be handled properly, but
@@ -692,7 +693,7 @@
dnl guess OS = OS_TYPE for jni_md.h
OS=""
AC_ARG_WITH(os-type,
-[AS_HELP_STRING([--with-os-type=SUBDIR],[Where is your JDK os-type
subdirectory])],
+[AS_HELP_STRING([--with-os-type=SUBDIR],[DEPRECATED: Where is your JDK os-type
subdirectory])],
[
OS=${withval}
@@ -763,7 +764,23 @@
jni/Makefile
])
+if ${TEST} -n "${WARN_JNI}" ; then
+AC_MSG_WARN([===])
+AC_MSG_WARN([You have used one of the following options:])
+AC_MSG_WARN([--enable-jni])
+AC_MSG_WARN([--with-java-home])
+AC_MSG_WARN([--with-java-platform])
+AC_MSG_WARN([--with-os-type])
+AC_MSG_WARN([These options are only necessary if])
+AC_MSG_WARN([you want to use a worker of type jni.])
+AC_MSG_WARN([These workers have been deprecated.])
+AC_MSG_WARN([They do not work and will be removed from])
+AC_MSG_WARN([a future release])
+AC_MSG_WARN([===])
+fi
+
if ${TEST} -n "${WARN_CC}" ; then
+AC_MSG_WARN([===])
AC_MSG_WARN([Using CC from environment:])
AC_MSG_WARN([CC="$CC"])
AC_MSG_WARN([instead of CC from apxs:])
@@ -773,4 +790,5 @@
AC_MSG_WARN(["libtool: compile: specify a tag with `--tag'"])
AC_MSG_WARN([try running configure without setting CC,])
AC_MSG_WARN([or at least CC should start with "$APXSCC"])
+AC_MSG_WARN([===])
fi
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r750428 - /tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c
Author: rjung
Date: Thu Mar 5 11:41:25 2009
New Revision: 750428
URL: http://svn.apache.org/viewvc?rev=750428&view=rev
Log:
Add a deprecation log warning when a JNI worker
is instantiated.
Modified:
tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c
Modified: tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c?rev=750428&r1=750427&r2=750428&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_jni_worker.c Thu Mar 5
11:41:25 2009
@@ -645,6 +645,11 @@
JK_TRACE_ENTER(l);
+jk_log(l, JK_LOG_WARNING,
+ "Worker '%s' is of type jni, which is deprecated "
+ "and will be removed in a future release.",
+ name ? name : "(null)");
+
if (!name || !w) {
JK_LOG_NULL_PARAMS(l);
JK_TRACE_EXIT(l);
@@ -1251,6 +1256,10 @@
int JK_METHOD jni_worker_factory(jk_worker_t **w,
const char *name, jk_logger_t *l)
{
+jk_log(l, JK_LOG_WARNING,
+ "Worker '%s' is of type jni, which is deprecated "
+ "and will be removed in a future release.",
+ name ? name : "(null)");
if (w)
*w = NULL;
return 0;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r750429 - in /tomcat/connectors/trunk/jk/xdocs: generic_howto/workers.xml miscellaneous/changelog.xml miscellaneous/faq.xml news/20090301.xml reference/workers.xml webserver_howto/apache.x
Author: rjung Date: Thu Mar 5 11:42:14 2009 New Revision: 750429 URL: http://svn.apache.org/viewvc?rev=750429&view=rev Log: Add deprecation warning about JNI to the docs. Modified: tomcat/connectors/trunk/jk/xdocs/generic_howto/workers.xml tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml tomcat/connectors/trunk/jk/xdocs/miscellaneous/faq.xml tomcat/connectors/trunk/jk/xdocs/news/20090301.xml tomcat/connectors/trunk/jk/xdocs/reference/workers.xml tomcat/connectors/trunk/jk/xdocs/webserver_howto/apache.xml Modified: tomcat/connectors/trunk/jk/xdocs/generic_howto/workers.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/generic_howto/workers.xml?rev=750429&r1=750428&r2=750429&view=diff == --- tomcat/connectors/trunk/jk/xdocs/generic_howto/workers.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/generic_howto/workers.xml Thu Mar 5 11:42:14 2009 @@ -103,7 +103,7 @@ TypeDescription ajp12This worker knows how to forward requests to out-of-process Tomcat workers using the ajpv12 protocol. ajp13This worker knows how to forward requests to out-of-process Tomcat workers using the ajpv13 protocol. - jniThis worker knows how to forward requests to in-process Tomcat workers using JNI. + jniDEPRECATED: This worker knows how to forward requests to in-process Tomcat workers using JNI. lbThis is a load-balancing worker; it knows how to provide round-robin based sticky load balancing with a certain level of fault-tolerance. statusThis is a status worker for managing load balancers. @@ -123,8 +123,6 @@ worker.local.type=ajp12 # Defines a worker named "remote" that uses the ajpv13 protocol to forward requests to a Tomcat process. worker.remote.type=ajp13 - # Defines a worker named "fast" that uses JNI to forward requests to a Tomcat process. - worker.fast.type=jni # Defines a worker named "loadbalancer" that loadbalances several Tomcat processes transparently. worker.loadbalancer.type=lb @@ -308,19 +306,17 @@ You can define "macros" in the property files. These macros let you define properties and later on use them while -constructing other properties and it's very useful when you want to -change your Java Home, Tomcat Home or OS path separator +constructing other properties. - # property example, don't hardcode path separator - ps=\ - workers.tomcat_home=d:\tomcat - workers.java_home=d:\sdk\jdk1.2.2 - # Using macros we'll have : worker.inprocess.class_path=d:\tomcat\classes - worker.inprocess.class_path=$(workers.tomcat_home)$(ps)classes - # Using macros we'll have : worker.inprocess.class_path=d:\sdk\jdk1.2.2\lib\tools.jar - worker.inprocess.class_path=$(workers.java_home)$(ps)lib$(ps)tools.jar + # property example, like a network base address + mynet=194.226.31 + # Using the above macro to simplify the address definitions + # for a farm of workers. + worker.node1.host=$(mynet).11 + worker.node2.host=$(mynet).12 + worker.node3.host=$(mynet).13 Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?rev=750429&r1=750428&r2=750429&view=diff == --- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Thu Mar 5 11:42:14 2009 @@ -44,6 +44,9 @@ +JNI: Deprecate JNI workers. (rjung) + + Docs: Add a new HowTo page about reverse proxies. (rjung) Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/faq.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/faq.xml?rev=750429&r1=750428&r2=750429&view=diff == --- tomcat/connectors/trunk/jk/xdocs/miscellaneous/faq.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/faq.xml Thu Mar 5 11:42:14 2009 @@ -263,6 +263,7 @@ +JNI workers have been deprecated. They will likely not work. Do not use them. JNI support requires a multi-threaded environment which is not the general case for Apache 1.3. You should verify if Apache 1.3 has been build with thread support and if not you could add the @@ -281,6 +282,7 @@ +JNI workers have been deprecated. They will likely not work. Do not use them. Under Linux, you should set some environment variables BEFORE launching your Apache server : Modified: tomcat/connectors/trunk/jk/xdocs/news/20090301.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/news/20090301.xml?rev=750429&r1=750428&r2=750429&view=diff == --- tomcat/connectors/trunk/jk/xdocs/news/20090301.x
Re: [SECURITY] CVE-2008-4308: Tomcat information disclosure vulnerability
nambo.k...@oss.ntt.co.jp wrote: > Hi, Mark. > >> The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected > I checked Tomcat 5.0.x source code and I've found that > org.apache.coyote.http11.filters.SavedRequestInputFilter is NOT included. > Does this mean Tomcat 5.0.x is not affected by this vulnerability? I would assume so but haven't confirmed this as 5.0.x is unsupported. Mark > > Advice, please. > Kazu Nambo > > > From: ma...@apache.org > Subject: [SECURITY] CVE-2008-4308: Tomcat information disclosure vulnerability > Date: Wed, 25 Feb 2009 23:17:37 + > > CVE-2008-4308: Tomcat information disclosure vulnerability > > Severity: Low > > Vendor: > The Apache Software Foundation > > Versions Affected: > Tomcat 4.1.32 to 4.1.34 > Tomcat 5.5.10 to 5.5.20 > Tomcat 6.0.x is not affected > The unsupported Tomcat 3.x, 4.0.x and 5.0.x versions may be also affected > > Note: Although this vulnerability affects relatively old versions of > Apache Tomcat, it was only discovered and reported to the Apache Tomcat > Security team in October 2008. Publication of this issue was then > postponed until now at the request of the reporter. > > Description: > Bug 40771 (https://issues.apache.org/bugzilla/show_bug.cgi?id=40771) may > result in the disclosure of POSTed content from a previous request. For > a vulnerability to exist the content read from the input stream must be > disclosed, eg via writing it to the response and committing the > response, before the ArrayIndexOutOfBoundsException occurs which will > halt processing of the request. > > Mitigation: > Upgrade to: > 4.1.35 or later > 5.5.21 or later > 6.0.0 or later > > Example: > See original bug report for example of how to create the error condition. > > Credit: > This issue was discovered by Fujitsu and reported to the Tomcat Security > Team via JPCERT. > > References: > http://tomcat.apache.org/security.html > > Mark Thomas >> >> > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
On 05.03.2009 10:36, Mladen Turk wrote: Rainer Jung wrote: On 05.03.2009 10:03, Mark Thomas wrote: Mladen Turk wrote: Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is already disabled by default. You need a special configure flag --enable-jni to include it in build. But I agree, it's unsupported and simply doesn't work. Any objections to removing it then? Not from me, I have never seen it used. Would it be good, to anounce the future removal in the 1.2.28 news and then do it in 1.2.29? Others? Yes, mark it as deprecated somehow. Perhaps a warning during configure and some note in docs. Also, instead removing it completely just use the empty stub, so that we don't need to change the makefiles and stuff. I added - the word DEPRECATED to the help string of the jni related options in configure - a fat warning at the end of the configure run, when enable-jni was chosen - a log warning to the jni worker factory - lots of warnings to the docs - a note to the 1.2.28 news and changelog and change one jni based example for an unrelated feature in the docs. So things should be set pretty well for removal of the support in 1.2.29 or 30. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r750438 - /tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
Author: rjung Date: Thu Mar 5 12:21:46 2009 New Revision: 750438 URL: http://svn.apache.org/viewvc?rev=750438&view=rev Log: Fix typo that breaks compilation. Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?rev=750438&r1=750437&r2=750438&view=diff == --- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original) +++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Thu Mar 5 12:21:46 2009 @@ -661,9 +661,9 @@ s->vhost_to_text = ws_vhost_to_text; s->vhost_to_uw_map = ws_vhost_to_uw_map; -s->auth_type = get_env_string(r, r->connection->ap_auth_type +s->auth_type = get_env_string(r, r->connection->ap_auth_type, conf->auth_type_indicator, 1); -s->remote_user = get_env_string(r, r->connection->user +s->remote_user = get_env_string(r, r->connection->user, conf->remote_user_indicator, 1); s->protocol = r->protocol; - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r750459 - /tomcat/connectors/trunk/jk/xdocs/index.xml
Author: rjung Date: Thu Mar 5 13:52:03 2009 New Revision: 750459 URL: http://svn.apache.org/viewvc?rev=750459&view=rev Log: Add 2009 news to the docs front page. Modified: tomcat/connectors/trunk/jk/xdocs/index.xml Modified: tomcat/connectors/trunk/jk/xdocs/index.xml URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/index.xml?rev=750459&r1=750458&r2=750459&view=diff == --- tomcat/connectors/trunk/jk/xdocs/index.xml (original) +++ tomcat/connectors/trunk/jk/xdocs/index.xml Thu Mar 5 13:52:03 2009 @@ -45,6 +45,16 @@ +XX March 2009 - JK-1.2.28 released +The Apache Tomcat team is proud to announce the immediate availability +of Tomcat Connectors 1.2.28 Stable. This release contains mainly bug fixes and some small improvements. + +Download the http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.28/tomcat-connectors-1.2.28-src.tar.gz";>JK 1.2.28 release sources + | http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.28/tomcat-connectors-1.2.28-src.tar.gz.asc";>PGP signature + +Download the http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/";>binaries for selected platforms. + + 28 October 2008 - JK-1.2.27 released The Apache Tomcat team is proud to announce the immediate availability of Tomcat Connectors 1.2.27 Stable. This release contains interesting improvements. @@ -213,6 +223,8 @@ +2009 + 2008 2007 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Testing tarball mod_jk 1.2.28-dev available - please provide binaries
Hi, I uploaded testing tarballs of mod_jk 1.2.28-dev to http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source CAUTION: at this point in time the web server still shows the older revision 750390. The revision I uploaded last was 750438. I already waited 2 hours, but the sync seems to take longer. Please do not use the 750390. The docs are available at http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs Binaries for Solaris Sparc and Linux can be found in the respective folders under http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/binaries I'm sure Mladen will also provide testing binaries for Windows. It would be nice, if we could get those for other platforms as well. Although this is not a final release, so you will have to make the builds again for the final release, this will be the best moment to ensure, that the builds actually work. I will post again to dev and users about the opportunity to test, once the correct revision of the source is visible and we have at least also the Windows binaries in place. Assuming no major problems will be found, we could proceed with tagging etc. early next week. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46803] New: Configuration fix for jsvc daemon
https://issues.apache.org/bugzilla/show_bug.cgi?id=46803 Summary: Configuration fix for jsvc daemon Product: Tomcat 6 Version: 6.0.18 Platform: Other OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: jtrim...@cc.ysu.edu The configure script does not take into account for AIX5.3 servers. After three days of looking on the web, the following patch fixes this problem (at least for tomcat 6 implementation of jsvc daemon): In the stanza: $as_echo_n "checking C flags dependant on host system type... " >&6; } case $host_os in - +aix5*) + CFLAGS="$CFLAGS -DOS_AIX -DDSO_DLFCN" + LDFLAGS="$LDFLAGS -ldl" + ;; This seems to have fix the configure issue. JSVC runs the daemon normally, now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
Please go ahead and remove it. 10 years ago it seemed a good idea to avoid the IPC. Now it seems even running them on the same machine is obsolete. Costin On Thu, Mar 5, 2009 at 1:03 AM, Mark Thomas wrote: > Mladen Turk wrote: > > Mark Thomas wrote: > >> I stumbled across some code in trunk for this. I had a poke around and > >> as far as > >> I can tell this hasn't been supported for quite some time. What do > >> people think > >> about removing it from mod_jk and trunk? > >> > > > > It is already disabled by default. You need a special configure flag > > --enable-jni to include it in build. > > But I agree, it's unsupported and simply doesn't work. > > Any objections to removing it then? > > Mark > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
DO NOT REPLY [Bug 46792] NullPointerException in org.apache.catalina.connector
https://issues.apache.org/bugzilla/show_bug.cgi?id=46792 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution||INVALID --- Comment #5 from Mark Thomas 2009-03-05 07:58:34 PST --- Tomcat re-uses Request objects between requests. getMethod() will only return null after the Request object has been re-cycled at the end of the previous request and before it has been initialised at the start of the next request. It appears as some code somewhere is retaining a reference to a Request object from a previous request and is attempting to use it after the request has ended. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
> Please go ahead and remove it. > 10 years ago it seemed a good idea to avoid the IPC. Now it seems even > running them > on the same machine is obsolete. +1 The simpler the better and we're in cloud computing today :) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
Costin Manolache wrote: Please go ahead and remove it. 10 years ago it seemed a good idea to avoid the IPC. Now it seems even running them on the same machine is obsolete. LOL. But don't forget the good old one ... What goes around, comes around Cheers -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remove the jni worker from mod_jk
On Mar 5, 2009, at 4:36 AM, Mladen Turk wrote: Rainer Jung wrote: On 05.03.2009 10:03, Mark Thomas wrote: Mladen Turk wrote: Mark Thomas wrote: I stumbled across some code in trunk for this. I had a poke around and as far as I can tell this hasn't been supported for quite some time. What do people think about removing it from mod_jk and trunk? It is already disabled by default. You need a special configure flag --enable-jni to include it in build. But I agree, it's unsupported and simply doesn't work. Any objections to removing it then? Not from me, I have never seen it used. Would it be good, to anounce the future removal in the 1.2.28 news and then do it in 1.2.29? Others? Yes, mark it as deprecated somehow. Perhaps a warning during configure and some note in docs. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46807] New: Cannot disable jsp tag pooling
https://issues.apache.org/bugzilla/show_bug.cgi?id=46807
Summary: Cannot disable jsp tag pooling
Product: Tomcat 6
Version: 6.0.18
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
AssignedTo: dev@tomcat.apache.org
ReportedBy: eabb...@crunchtime.com
Set jvm param -Dorg.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false.
In web.xml set enablePooling to false.
Created a custom tag that extends
import javax.servlet.jsp.tagext.BodyTagSupport;
Verified by adding member field
private long creation_time = System.currentTimeMillis();
inside doInitBody()...
public void doInitBody() {
System.out.println("creation_time="+ creation_time);
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 44382] Need to add support for HTTPOnly session cookie parameter
https://issues.apache.org/bugzilla/show_bug.cgi?id=44382 --- Comment #18 from Jim Manico 2009-03-05 12:47:18 PST --- As the original poster of the feature request back in Feb 08, I want to extend my sincere gratitude to the Mark and the Tomcat team for adding this patch to trunk! Thank you, Gents! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46807] Cannot disable jsp tag pooling
https://issues.apache.org/bugzilla/show_bug.cgi?id=46807 --- Comment #1 from Eric Abbott 2009-03-05 14:00:43 PST --- It appears that once a jsp is compiled (pre or live), tag pooling is no longer changeable via web.xml nor the jvm compiler flag. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46807] Cannot disable jsp tag pooling
https://issues.apache.org/bugzilla/show_bug.cgi?id=46807 --- Comment #2 from Eric Abbott 2009-03-05 15:05:32 PST --- http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html The documentation is misleading when it states: "Use java system property at server runtime to disable tag pooling org.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false. and limit the buffering with org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true. Note that changing from the defaults may affect performance, but it will vary depending on the application." The pooling for a given jsp can only be determined at compile time, be it precompiled or compiled by the server. Also the ant jasper precompile task attribute poolingEnabled unfortunately differs from the web.xml value of enablePooling which can cause confusion. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46808] New: mod_jk 1.2.27 can't detect network error
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808
Summary: mod_jk 1.2.27 can't detect network error
Product: Tomcat Connectors
Version: 1.2.27
Platform: PC
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: Common
AssignedTo: dev@tomcat.apache.org
ReportedBy: mashm...@gmail.com
Created an attachment (id=23337)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23337)
patch for jk_lb_worker.c
For instance, assume to use one lb worker with two sub workers.
When the network cable of one AP server is pulled out,
ajp_send_request() returns JK_FATAL_ERROR.
Because the state of lbworker doesn't become JK_LB_STATE_ERROR when
"rec->s->busy" is larger than 0, there is a possibility that the next
request is transmitted to the server to which the network cable has
been pulled out.
In this case, the request wasted additional time for connecting.
This additional time depends on "socket_timeout"( or "socket_connect_timeout")
and "retries".
Actually, when the network cable was pulled out by intention in the load test,
such a situation was generated.
And the waste of time continued until the network cable was reconnected.
If the request has stickyness, it seems that the waste of time can be reduced
by using JvmRouteBinderValve on the Tomcat.
In case of mod_jk 1.2.22, the situation like 1.2.27 was not generated
because it made an error of the state of the lbworker if the connection
failed.
In the following cases, ajp_service() returns JK_FATAL_ERROR.
In these cases, it seems that there might be no problem even if the
state of lbworker becomes an error state.
* JK_FATAL_ERROR JK_FALSE ajp_connection_tcp_send_message()
returns JK_FATAL_ERROR
* Endpoint belongs to unknown protocol.
* JK_FATAL_ERRORJK_TRUE
ajp_connection_tcp_send_message() returns JK_FALSE
* Sending request or request body in jk_tcp_socket_sendfull()
returns with error.
* JK_FATAL_ERROR JK_TRUE Could not connect to backend
* JK_FATAL_ERROR ? ajp_process_callback() returns
JK_AJP13_ERROR
* JK_AJP13_ERROR: protocol error, or JK_INTERNAL_ERROR: chunk size
to large
Index: mod_jk-head/native/common/jk_lb_worker.c
===
--- mod_jk-head/native/common/jk_lb_worker.c(revision 750704 (
https://svn.apache.org/viewcvs.cgi?view=rev&rev=750704 ))
+++ mod_jk-head/native/common/jk_lb_worker.c(working copy)
@@ -1339,12 +1339,8 @@
* Time for fault tolerance (if possible)...
*/
rec->s->errors++;
-if (rec->s->busy) {
-rec->s->state = JK_LB_STATE_OK;
-}
-else {
-rec->s->state = JK_LB_STATE_ERROR;
-}
+rec->s->state = JK_LB_STATE_ERROR;
+
p->states[rec->i] = JK_LB_STATE_ERROR;
rec->s->error_time = time(NULL);
rc = JK_FALSE;
Best regards.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing tarball mod_jk 1.2.28-dev available - please provide binaries
On 05.03.2009 15:23, Rainer Jung wrote: Hi, I uploaded testing tarballs of mod_jk 1.2.28-dev to http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source CAUTION: at this point in time the web server still shows the older revision 750390. The revision I uploaded last was 750438. I already waited 2 hours, but the sync seems to take longer. Please do not use the 750390. Did anybody use them already? Because of BZ 46808 and the fact, that deletions are only done once a day, I would like to quickly move the 750438 files out of the folders in order to be able to update the revision without waiting another night. It seems the remove job didn't yet do it's work. If you want 750438 back, because you alrady put work into it, please let me know. Otherwise I'll generate a new revision. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46808] mod_jk 1.2.27 can't detect network error
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808 --- Comment #1 from Mladen Turk 2009-03-05 23:38:00 PST --- Your patch breaks other things that are more important. The check fof busy is deliberate because athough one connection can be rejected others might still work. This would mean that next request on keep-alive connection will fail. So, -1 for the patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing tarball mod_jk 1.2.28-dev available - please provide binaries
Rainer Jung wrote: On 05.03.2009 15:23, Rainer Jung wrote: Hi, I uploaded testing tarballs of mod_jk 1.2.28-dev to http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source CAUTION: at this point in time the web server still shows the older revision 750390. The revision I uploaded last was 750438. I already waited 2 hours, but the sync seems to take longer. Please do not use the 750390. Did anybody use them already? Because of BZ 46808 and the fact, that deletions are only done once a day, I would like to quickly move the 750438 files out of the folders in order to be able to update the revision without waiting another night. It seems the remove job didn't yet do it's work. If you want 750438 back, because you alrady put work into it, please let me know. Otherwise I'll generate a new revision. There's nothing in dev/dist. Can you cc the dist files to your people's dir as well Regared -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46808] mod_jk 1.2.27 can't detect network error
https://issues.apache.org/bugzilla/show_bug.cgi?id=46808 --- Comment #2 from Rainer Jung 2009-03-05 23:51:05 PST --- I'm also investigating this and try to fully understand all implications of r647085 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=647085 ) One first question (to Mladen): In this revision you introduced the local states and an additional busy counter. From your changelog entry I assume you want to be able to behave differently depending on whether the process handling the request has a concurrent request running on the problematic backend, or not. My question is: the freshly introduced busy for the lb sub worker is located in shared memory. Shouldn't it be in the process local sub worker data? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Testing tarball mod_jk 1.2.28-dev available - please provide binaries
On 06.03.2009 08:39, Mladen Turk wrote: Rainer Jung wrote: On 05.03.2009 15:23, Rainer Jung wrote: Hi, I uploaded testing tarballs of mod_jk 1.2.28-dev to http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/source CAUTION: at this point in time the web server still shows the older revision 750390. The revision I uploaded last was 750438. I already waited 2 hours, but the sync seems to take longer. Please do not use the 750390. Did anybody use them already? Because of BZ 46808 and the fact, that deletions are only done once a day, I would like to quickly move the 750438 files out of the folders in order to be able to update the revision without waiting another night. It seems the remove job didn't yet do it's work. If you want 750438 back, because you alrady put work into it, please let me know. Otherwise I'll generate a new revision. There's nothing in dev/dist. That's what I tied to express with the previous Email ;) Can you cc the dist files to your people's dir as well Did that: http://people.apache.org/~rjung/mod_jk-dev/ But as described above, it would be nice to first check BZ 46808 before building binaries. I saw your comment, but also added another one. Please have a look. The problem with the dev/dist is: It is easy to add or overwrite files, but once there, you need to wait over night if you want to remove them from the web. The delete sync is not done hourly, it is only done daily. So purging an old snapshot is much slower than adding a new one. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
