Re: possible mod_jk "feature"

[Mladen Turk]

Filip Hanik - Dev Lists wrote:

Rainer Jung wrote:

Mladen Turk schrieb:
 

The patch the Jim provided, gives us the functionality of turning off
the keep alive from the "clients" (httpd in this case) perspective.
  

I do not agree, although its a hack and easy fix for
the problem itself.



I like ideals and ideas too, however, I believe Jim presented a very 
simple patch, that solves a very *real* problem in a very simple manner,
very simple -> very real -> very simple, I like the simple part of this 
patch.




Sure, I have no problem with that, since it's a configurable
and optional directive, so +0 for the patch.

Anyhow, I still think its a hack, that does not address the
problem in the real fashion. I have some ideas, and I'll
concentrate on the way how to improve the Tomcat side to
detect the hanged connections instead of downgrading the
AJP protocol and loosing performance.

Regards,
Mladen.

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

svn commit: r434345 - in /tomcat/connectors/trunk/jk/native: apache-1.3/mod_jk.c apache-2.0/mod_jk.c common/jk_ajp_common.c common/jk_global.h common/jk_service.h

[rjung]

Author: rjung
Date: Thu Aug 24 02:02:09 2006
New Revision: 434345

URL: http://svn.apache.org/viewvc?rev=434345&view=rev
Log:
Workaround patch from Jim Jagielski to disable persistent connections
in case of silent connection drops by firewalls.
Stiil needs documentation with a couple of disclaimers
(performance, resource usage, prefered solution TCP keep alive).

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_global.h
tomcat/connectors/trunk/jk/native/common/jk_service.h

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=434345&r1=434344&r2=434345&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 Aug 24 02:02:09 
2006
@@ -500,6 +500,12 @@
 s->flush_packets = 1;
 else
 s->flush_packets = 0;
+
+if (conf->options & JK_OPT_DISABLEREUSE)
+s->disable_reuse = 1;
+else
+s->disable_reuse = 0;
+
 /* get server name */
 /* s->server_name  = (char *)(r->hostname ? r->hostname : 
r->server->server_hostname); */
 /* XXX : à la jk2 */
@@ -1538,6 +1544,9 @@
 }
 else if (!strcasecmp(w, "FlushPackets")) {
 opt = JK_OPT_FLUSHPACKETS;
+}
+else if (!strcasecmp(w, "DisableReuse")) {
+opt = JK_OPT_DISABLEREUSE;
 }
 else
 return ap_pstrcat(cmd->pool, "JkOptions: Illegal option '", w,

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=434345&r1=434344&r2=434345&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Thu Aug 24 02:02:09 
2006
@@ -523,6 +523,12 @@
 s->flush_packets = 1;
 else
 s->flush_packets = 0;
+
+if (conf->options & JK_OPT_DISABLEREUSE)
+s->disable_reuse = 1;
+else
+s->disable_reuse = 0;
+
 /* get server name */
 s->server_name = (char *)ap_get_server_name(r);
 
@@ -1023,7 +1029,7 @@
  */
 
 static const char *jk_set_auto_alias(cmd_parms * cmd,
- void *dummy, char *directory)
+ void *dummy, const char *directory)
 {
 server_rec *s = cmd->server;
 jk_server_conf_t *conf =
@@ -1568,6 +1574,9 @@
 }
 else if (!strcasecmp(w, "FlushPackets")) {
 opt = JK_OPT_FLUSHPACKETS;
+}
+else if (!strcasecmp(w, "DisableReuse")) {
+opt = JK_OPT_DISABLEREUSE;
 }
 else
 return apr_pstrcat(cmd->pool, "JkOptions: Illegal option '", w,

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=434345&r1=434344&r2=434345&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Thu Aug 24 
02:02:09 2006
@@ -1456,12 +1456,17 @@
 */
 jk_log(l, JK_LOG_INFO, " Protocol error: Reuse is set to false");
 }
+else if (r->disable_reuse) {
+ae->reuse = JK_FALSE;
+}
+else {
+/* Reuse in all cases */
+ae->reuse = JK_TRUE;
+}
 /* Flush after the last write */
 if (r->flush && !r->flush_packets)
 r->flush(r);
 
-/* Reuse in all cases */
-ae->reuse = JK_TRUE;
 JK_TRACE_EXIT(l);
 return JK_AJP13_END_RESPONSE;
 break;

Modified: tomcat/connectors/trunk/jk/native/common/jk_global.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_global.h?rev=434345&r1=434344&r2=434345&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_global.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_global.h Thu Aug 24 02:02:09 
2006
@@ -240,6 +240,7 @@
 /* Forward local instead remote address */
 #define JK_OPT_FWDLOCAL 0x0010
 #define JK_OPT_FLUSHPACKETS 0x0020
+#define JK_OPT_DISABLEREUSE 0x0040
 
 /* Check for EBCDIC systems */
 

Modified: tomcat/connectors/trunk/jk/native/common/jk_service.h
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_service.h?rev=434345&r1=434344&r2=434345&view=dif

Re: possible mod_jk "feature"

[Jim Jagielski]

On Aug 24, 2006, at 4:12 AM, Mladen Turk wrote:


Filip Hanik - Dev Lists wrote:

Rainer Jung wrote:

Mladen Turk schrieb:

The patch the Jim provided, gives us the functionality of  
turning off
the keep alive from the "clients" (httpd in this case)  
perspective.



I do not agree, although its a hack and easy fix for
the problem itself.



I like ideals and ideas too, however, I believe Jim presented a  
very simple patch, that solves a very *real* problem in a very  
simple manner,
very simple -> very real -> very simple, I like the simple part of  
this patch.


Sure, I have no problem with that, since it's a configurable
and optional directive, so +0 for the patch.

Anyhow, I still think its a hack, that does not address the
problem in the real fashion. I have some ideas, and I'll
concentrate on the way how to improve the Tomcat side to
detect the hanged connections instead of downgrading the
AJP protocol and loosing performance.




I'd like to propose that I commit the patch, and then we
add in the additional awareness of keepalives from
the TCP as well as AJP PoVs.

Sound OK?

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

Re: possible mod_jk "feature"

[Mladen Turk]

Jim Jagielski wrote:



I'd like to propose that I commit the patch, and then we
add in the additional awareness of keepalives from
the TCP as well as AJP PoVs.

Sound OK?



Sure. Think Rainer already committed your patch.

--
Mladen.

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

Re: possible mod_jk "feature"

[Filip Hanik - Dev Lists]

Jim Jagielski wrote:


On Aug 24, 2006, at 4:12 AM, Mladen Turk wrote:


Filip Hanik - Dev Lists wrote:

Rainer Jung wrote:

Mladen Turk schrieb:

The patch the Jim provided, gives us the functionality of turning 
off

the keep alive from the "clients" (httpd in this case) perspective.


I do not agree, although its a hack and easy fix for
the problem itself.



I like ideals and ideas too, however, I believe Jim presented a very 
simple patch, that solves a very *real* problem in a very simple 
manner,
very simple -> very real -> very simple, I like the simple part of 
this patch.


Sure, I have no problem with that, since it's a configurable
and optional directive, so +0 for the patch.

Anyhow, I still think its a hack, that does not address the
problem in the real fashion. I have some ideas, and I'll
concentrate on the way how to improve the Tomcat side to
detect the hanged connections instead of downgrading the
AJP protocol and loosing performance.




I'd like to propose that I commit the patch, and then we
add in the additional awareness of keepalives from
the TCP as well as AJP PoVs.

Sound OK?

rainer committed it last night, Thanks Rainer
Filip



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


--No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 8/23/2006





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

Re: possible mod_jk "feature"

[Jim Jagielski]

On Aug 24, 2006, at 9:37 AM, Mladen Turk wrote:


Jim Jagielski wrote:

I'd like to propose that I commit the patch, and then we
add in the additional awareness of keepalives from
the TCP as well as AJP PoVs.
Sound OK?



Sure. Think Rainer already committed your patch.


yeah, I see... :)

teach me to be on-the-road for 24 hours ;)

Thanks!

PS: I'll update the docs.


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

DO NOT REPLY [Bug 39404] - Tomcat 5.0.28 service fails without error message on Windows2003

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39404





--- Additional Comments From [EMAIL PROTECTED]  2006-08-24 15:26 ---
We are also witnessing this behaviour with Tomcat 5.0.28.  It has died during 
startup, while idle, and while actively being used.  It dies as a service, and 
on the command line.  No particular action seems to cause the silent death, as 
I've had some instances run for weeks without fail.
Windows XP Pro, JDK 1.4.2_08, using separate CATALINA_BASE directories for a 
single CATALINA_HOME.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

SSL JNDIRealm implementation

[Perry Nguyen]

Hi,

It seems Tomcat does not support SSL through the JNDIRealm that is implemented 
with Catalina.


A while ago, I was looking for a solution to this, and stumbled across the 
Cougaar security work.  They seem to have provided a SecureJNDIRealm 
implementation that is compatible with the existing JNDIRealm, easy to 
implement in server.xml and agreeable with the Apache/Tomcat license.


http://cougaar.org/cgi-bin/viewcvs.cgi/securityservices/src/org/cougaar/core/security/crypto/ldap/?cvsroot=securitycore

The required classes are SecureJNDIRealm and JNDISSLFactory

It appears to have been implemented for Tomcat 4, but I have it running 
successfully without modification (that I recall) on Tomcat 5.5.12 since 
before December 2005.


It would be a nice boon if Tomcat integrated this functionality.  Clear-text 
simple bind to LDAP is garbage, and running an stunnel to hack around it is... 
to put it simply, lame.


Thanks, from a happy user.


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

DO NOT REPLY [Bug 39404] - Tomcat 5.0.28 service fails without error message on Windows2003

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=39404





--- Additional Comments From [EMAIL PROTECTED]  2006-08-24 19:53 ---
Probably.

Usually these are caused by JVM bugs. The JVM crash often leaves files behind
called "hs_err_pid_*" with stack traces (unless the JVM is running out of a
working directory where it doesn't have write permission). Look for those.

Be sure that you have the very latest JVM version (in whatever version stream
you use - 1.4 or 1.5). 

Also, for Solaris (not this bug, but point needs to be noted): make sure you
install all the recommended patchsets.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 40315] New: - WebAppClassLoader behavior when getting resource "/"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=40315

   Summary: WebAppClassLoader behavior when getting resource "/"
   Product: Tomcat 5
   Version: 5.5.14
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Call to class.getResourceAsStream("/") on a class loaded from webapp classpath
(e.g. from a jar in WEB-INF/lib) returns directory listing for directory from
where catalina was started. Apart from a potential security issue, this causes
inconsistency in the classloader behavior (different results depending on how
the container got started).

In our case, we use C3P0 connection pool which for some strange reason happens
to read "/" resource during initialization, and executing startup.sh from a
read-protected directory causes webapp fail to load with an NPE with the
following stack trace (only the relevant portion shown):

Caused by: java.lang.NullPointerException
at java.util.Arrays$ArrayList.(Arrays.java:2355)
at java.util.Arrays.asList(Arrays.java:2341)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:67)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at java.net.URL.openStream(URL.java:1007)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1161)
at
org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1170)
...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Jk 1.2.18 binary for win32 won't load

[Mark Thomas]

Haven't been able to determine why, but the win32 binary for JK 1.2.18
 doesn't work with IIS5. JK 1.2.15 works without a hitch.

There have been a number of similar reports on the users list.

Mark

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