DO NOT REPLY [Bug 39834] - JkLogLevel debug causes Segmentation fault

[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=39834





--- Additional Comments From [EMAIL PROTECTED]  2006-08-22 10:09 ---
hi

We are now facing the same problem.
We are using mod_jk 1.2.18 with Apache 2.0.58 in RHELv3.

When JkLogLevel is set to error (not only debug), "apachectl graceful" causes 
segmentation faults. 
Did the problem be fixed already?

Could you give us any idea to solve this problem?

- Reproduction steps
 1. making a rush with 10 multiple users
 2. # mv access_log access_log.1
(we'd like to rotate the log file when we reboot Apache(graceful).)
 3. # apachectl graceful


- error_log
[Tue Aug 22 15:35:06 2006] [notice] Graceful restart requested, doing restart  
httpd: Could not determine the server's fully qualified domain name, using 127.
.0.1 for ServerName
[Tue Aug 22 15:35:06 2006] [notice] Apache configured -- resuming normal operat
ons
[Tue Aug 22 15:35:09 2006] [error] (43)Identifier removed: apr_global_mutex_loc
(jk_log_lock) failed   
[Tue Aug 22 15:35:09 2006] [error] (43)Identifier removed: apr_global_mutex_loc
(jk_log_lock) failed   
[Tue Aug 22 15:35:09 2006] [error] (43)Identifier removed: apr_global_mutex_loc
(jk_log_lock) failed   
[Tue Aug 22 15:35:09 2006] [error] (43)Identifier removed: apr_global_mutex_loc
(jk_log_lock) failed   
[Tue Aug 22 15:35:10 2006] [notice] child pid 1958 exit signal Segmentation fau
t (11) 
[Tue Aug 22 15:35:10 2006] [notice] child pid 1960 exit signal Segmentation fau
t (11) 
[Tue Aug 22 15:35:10 2006] [notice] child pid 1962 exit signal Segmentation fau
t (11) 
[Tue Aug 22 15:35:10 2006] [notice] child pid 1963 exit signal Segmentation fau
t (11) 


-- 
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 34513] - jsp exception handling

[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=34513





--- Additional Comments From [EMAIL PROTECTED]  2006-08-22 14:43 ---
(In reply to comment #3)
> 
> Hi,
> I have experienced the same issue.
> To solve that, you can add some jsp directives:
> <%@ page autoFlush="false"%>
> <%@ page buffer="800kb"%>
> 
> - autoflush will prevent the jsp from flushing until the end of the jsp has 
> been
> reached
> - buffer will specify a higher buffer size to prevent buffer overflow 
> exception
> 
> this should solve the problem.
> Regards,
> Cyrille.
> 

Thank you for your advice. I think that will help to some extent.

-- 
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]

svn commit: r433689 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina: core/ApplicationContext.java session/StandardSession.java

[fhanik]

Author: fhanik
Date: Tue Aug 22 09:52:29 2006
New Revision: 433689

URL: http://svn.apache.org/viewvc?rev=433689&view=rev
Log:
Prepare for cluster integration

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java?rev=433689&r1=433688&r2=433689&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/ApplicationContext.java 
Tue Aug 22 09:52:29 2006
@@ -88,7 +88,7 @@
 /**
  * The context attributes for this context.
  */
-private Map attributes = new ConcurrentHashMap();
+protected Map attributes = new ConcurrentHashMap();
 
 
 /**

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java?rev=433689&r1=433688&r2=433689&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/session/StandardSession.java 
Tue Aug 22 09:52:29 2006
@@ -1243,6 +1243,27 @@
  *  invalidated session
  */
 public void setAttribute(String name, Object value) {
+setAttribute(name,value,true);
+}
+/**
+ * Bind an object to this session, using the specified name.  If an object
+ * of the same name is already bound to this session, the object is
+ * replaced.
+ * 
+ * After this method executes, and if the object implements
+ * HttpSessionBindingListener, the container calls
+ * valueBound() on the object.
+ *
+ * @param name Name to which the object is bound, cannot be null
+ * @param value Object to be bound, cannot be null
+ * @param notify whether to notify session listeners
+ * @exception IllegalArgumentException if an attempt is made to add a
+ *  non-serializable object in an environment marked distributable.
+ * @exception IllegalStateException if this method is called on an
+ *  invalidated session
+ */
+
+public void setAttribute(String name, Object value, boolean notify) {
 
 // Name cannot be null
 if (name == null)
@@ -1268,7 +1289,7 @@
 HttpSessionBindingEvent event = null;
 
 // Call the valueBound() method if necessary
-if (value instanceof HttpSessionBindingListener) {
+if (notify && value instanceof HttpSessionBindingListener) {
 // Don't call any notification if replacing with the same value
 Object oldValue = attributes.get(name);
 if (value != oldValue) {
@@ -1286,7 +1307,7 @@
 Object unbound = attributes.put(name, value);
 
 // Call the valueUnbound() method if necessary
-if ((unbound != null) && (unbound != value) &&
+if (notify && (unbound != null) && (unbound != value) &&
 (unbound instanceof HttpSessionBindingListener)) {
 try {
 ((HttpSessionBindingListener) unbound).valueUnbound
@@ -1296,7 +1317,9 @@
 (sm.getString("standardSession.bindingEvent"), t);
 }
 }
-
+
+if ( !notify ) return;
+
 // Notify interested application event listeners
 Context context = (Context) manager.getContainer();
 Object listeners[] = context.getApplicationEventListeners();



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

svn commit: r433690 - /tomcat/build/tc5.5.x/KEYS

[fhanik]

Author: fhanik
Date: Tue Aug 22 09:53:43 2006
New Revision: 433690

URL: http://svn.apache.org/viewvc?rev=433690&view=rev
Log:
Added PGP Key for release management

Modified:
tomcat/build/tc5.5.x/KEYS

Modified: tomcat/build/tc5.5.x/KEYS
URL: 
http://svn.apache.org/viewvc/tomcat/build/tc5.5.x/KEYS?rev=433690&r1=433689&r2=433690&view=diff
==
--- tomcat/build/tc5.5.x/KEYS (original)
+++ tomcat/build/tc5.5.x/KEYS Tue Aug 22 09:53:43 2006
@@ -292,3 +292,34 @@
 vpsTbAGW
 =r1gT
 -END PGP PUBLIC KEY BLOCK-
+-BEGIN PGP PUBLIC KEY BLOCK-
+Version: GnuPG v1.4.5 (MingW32) - GPGshell v3.52
+
+mQGiBETrKsYRBACQmyglB/jdLFSU1gczfd42MmO5tA6YeZjhzejU/JJtLpgdSW1S
+1me/2SYDLsyuwrE7P5DVz1geWSfqXqzO9ThzY1Ixgqrg6n6o/3wq5SMBCxrAJXcN
+Zi6Vbwxt/LMcOzOfUKFPkGBUM+qsj3ItmInfsWBgOrwxQ37KtjCMgNHOowCg5o+D
+Nmmw8JEWjHq8XVMvcGUJR1UD/3lU6qiqOUH+75UdyYfAO1OZkccnUeR+5r1ZcjZL
+hJl+0TT18twa5v3UC5812TGPsTo0RRwpEqeO7urv26XulfofKV9b8JBRIVpunBd1
+9NpEN/SBfSQ+RzFWhg7xRirlBV0C30toFqhkI72vkYvbKhbaQKGqSt0daXLz0dU3
+NgxVA/9yOisu/gNHs2IsrPjCPO5uU7BIaiLfvTENVcfenV1O/YG0DjCsaccUBh0b
+34agdWldR+ak6beGKp8My+6m4+v9Mh5GI372EovUU5Aqyts71fDPyC+RHL7pFIPf
+HQNR+asb+QvY6Fgon8HUxL/bPFKN1JjnT3yWZTZrX9xUhe5cMbQzRmlsaXAgSGFu
+aWsgKEZpbGlwcyBBcGFjaGUgS2V5KSA8ZmhhbmlrQGFwYWNoZS5vcmc+iGAEExEC
+ACAFAkTrKsYCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRB7h+KW17ZYZFm8
+AKDTdlIxDHP802gyr22mQaB5xPsqnwCeI07ItFbIWz2izl5wltluNzfiUdu5Ag0E
+ROsq0hAIANOpE8Z+bXbiPp8W/0fkzgjtMojmF2sqFg728kzPrtADfqfsS8javY18
+Zu2kxbmiAnUxVhisfOB4DMeCqpKT1DNlPeNowXeO7x1XJcFyzc59cl9fPC52+qwS
+fb3w1R7/nbFZqZXgsNg0IuOUJ29weAWvhugLrd2mRqUO6NtmCvH8NlBVpminESLE
+L4hpfyGGSJeAxeEAT0B3amwJ77cv2xIoVD5zowiS+WM1qDvpXQm+b7uiz4YxviWO
+4ZKSHSQ2iq8SQc2JxoOOPlTHe8+h1MI+Uqmb7eQKEik8Y3hXuY7g+55cLYT0NMz0
+2Tn2tblghqu2QPphN9IQ/5iA1AQ4/SMAAwYH/2cTjiBXa6/2bAywR6csbrW1r0/s
+ugY882+p6xM1HFzl9pv9zdS9je8kWcDv3sEvhVfdAqeQ0SCA/5ZrjuIn0f77P/vR
+U4cZjjJUecrD2YjkFkXETd1Fr4TwtbiVWiDqLGZOaZnDYdhDNKXF0zfcAixjSP3x
+IXd9R3Slrg33TLYmWHdVWpp0GR+rdQwPFFXbi036aPLT2YB7kFjGeb/qUnlFPVn4
+my+STMKLuvl4qIZl9UE6TRc0G5L2vJeJ/43BNEEovyQpV0TIJ3NSK5wMUOF6bCA0
+yVoMPkWmQIGKk0bSD5L+LbV2zqKebpG9jbTcKmP8aSrnPsTzDC3rUkolj6iISQQY
+EQIACQUCROsq0gIbDAAKCRB7h+KW17ZYZJLjAJ9Av5B/TShKgq2C+D64050m871p
+4QCcD5ciTfRByolZe+fQ3lktOpO0Mpc=
+=ttOX
+-END PGP PUBLIC KEY BLOCK-
+



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

Re: possible mod_jk "feature"

[Jim Jagielski]

On Aug 21, 2006, at 8:51 AM, Jim Jagielski wrote:


I agree that the solution is not pretty, so in many ways
I look at the "feature" as similar to the flush_packets
feature: a help to those admin's who are stuck.


I'm looking at something like this:

Index: jk/native/apache-1.3/mod_jk.c
===
--- jk/native/apache-1.3/mod_jk.c   (revision 433241)
+++ jk/native/apache-1.3/mod_jk.c   (working copy)
@@ -476,6 +476,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 */
@@ -1515,6 +1521,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,

   "'", NULL);
Index: jk/native/common/jk_ajp_common.c
===
--- jk/native/common/jk_ajp_common.c(revision 433241)
+++ jk/native/common/jk_ajp_common.c(working copy)
@@ -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;
Index: jk/native/common/jk_service.h
===
--- jk/native/common/jk_service.h   (revision 433241)
+++ jk/native/common/jk_service.h   (working copy)
@@ -254,6 +254,12 @@
  * Flush a chunk of response data back to the browser.
  */
 void (JK_METHOD * flush) (jk_ws_service_t *s);
+
+/*
+ * If set do not reuse socket after each full response
+ */
+int disable_reuse;
+
};
/*
Index: jk/native/common/jk_global.h
===
--- jk/native/common/jk_global.h(revision 433241)
+++ jk/native/common/jk_global.h(working copy)
@@ -241,6 +241,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 */
Index: jk/native/apache-2.0/mod_jk.c
===
--- jk/native/apache-2.0/mod_jk.c   (revision 433241)
+++ jk/native/apache-2.0/mod_jk.c   (working copy)
@@ -501,6 +501,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);
@@ -1547,6 +1553,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,

"'", NULL);


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

svn commit: r433703 [2/14] - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/catalina/ha/ java/org/apache/catalina/ha/context/ java/org/apache/catalina/ha/deploy/ java/org/apache/catalina/ha/session/ jav

[fhanik]

Added: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java?rev=433703&view=auto
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java 
(added)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/ha/deploy/FileMessageFactory.java 
Tue Aug 22 10:28:09 2006
@@ -0,0 +1,311 @@
+/*
+ * Copyright 1999,2004 The Apache Software Foundation.
+ * 
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.catalina.ha.deploy;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.FileInputStream;
+import java.io.FileOutputStream;
+import java.io.FileNotFoundException;
+
+/**
+ * This factory is used to read files and write files by splitting them up into
+ * smaller messages. So that entire files don't have to be read into memory.
+ * 
+ * The factory can be used as a reader or writer but not both at the same time.
+ * When done reading or writing the factory will close the input or output
+ * streams and mark the factory as closed. It is not possible to use it after
+ * that. 
+ * To force a cleanup, call cleanup() from the calling object. 
+ * This class is not thread safe.
+ * 
+ * @author Filip Hanik
+ * @version 1.0
+ */
+public class FileMessageFactory {
+/*--Static Variables*/
+public static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory
+.getLog(FileMessageFactory.class);
+
+/**
+ * The number of bytes that we read from file
+ */
+public static final int READ_SIZE = 1024 * 10; //10kb
+
+/**
+ * The file that we are reading/writing
+ */
+protected File file = null;
+
+/**
+ * True means that we are writing with this factory. False means that we 
are
+ * reading with this factory
+ */
+protected boolean openForWrite;
+
+/**
+ * Once the factory is used, it can not be reused.
+ */
+protected boolean closed = false;
+
+/**
+ * When openForWrite=false, the input stream is held by this variable
+ */
+protected FileInputStream in;
+
+/**
+ * When openForWrite=true, the output stream is held by this variable
+ */
+protected FileOutputStream out;
+
+/**
+ * The number of messages we have read or written
+ */
+protected int nrOfMessagesProcessed = 0;
+
+/**
+ * The total size of the file
+ */
+protected long size = 0;
+
+/**
+ * The total number of packets that we split this file into
+ */
+protected long totalNrOfMessages = 0;
+
+/**
+ * The bytes that we hold the data in, not thread safe.
+ */
+protected byte[] data = new byte[READ_SIZE];
+
+/**
+ * Private constructor, either instantiates a factory to read or write. 

+ * When openForWrite==true, then a the file, f, will be created and an
+ * output stream is opened to write to it. 
+ * When openForWrite==false, an input stream is opened, the file has to
+ * exist.
+ * 
+ * @param f
+ *File - the file to be read/written
+ * @param openForWrite
+ *boolean - true means we are writing to the file, false means
+ *we are reading from the file
+ * @throws FileNotFoundException -
+ * if the file to be read doesn't exist
+ * @throws IOException -
+ * if the system fails to open input/output streams to the file
+ * or if it fails to create the file to be written to.
+ */
+private FileMessageFactory(File f, boolean openForWrite)
+throws FileNotFoundException, IOException {
+this.file = f;
+this.openForWrite = openForWrite;
+if (log.isDebugEnabled())
+log.debug("open file " + f + " write " + openForWrite);
+if (openForWrite) {
+if (!file.exists())
+file.createNewFile();
+out = new FileOutputStream(f);
+} else {
+size = file.length();
+totalNrOfMessages = (size / READ_SIZE) + 1;
+in = new FileInputStream(f);
+}//end if
+
+}
+
+/**
+ * Creates a factory to read or write from a file. When opening for read,
+ * the readMessage can be invoke

Does anyone know how to override the security web.xml deploy descriptors using the embedded tomcat Context security methods?

[Lisa Balducci]

Hi all,

 

I am trying to override the web.xml SecurityConstraints using the
Context addConstraint/removeConstraint methods.  The context.xml
contains the following element
WEB-INF/web.xml

 I tried the following to override the SecurityConstraints:   

 // adding the authConstraint  

   SecurityConstraint sc = new SecurityConstraint();


  sc.setAuthConstraint(false);

 

I've tried to use both the addConstraint(sc) and removeConstraint(sc)
methods to remove the auth-constraint element.  

 context.addConstraint(sc);  

 host.addChild(context);

 

The methods are set correctly but the web.xml security constraints
override these security constraint changes.  Is there a way to override
the web.xml security constraints using the
catalina.deploy.SecurityConstaint and Context methods?   

 

 

Lisa

 

 

Re: possible mod_jk "feature"

[Rainer Jung]

I checked the whole thread, but I found no technical description of the
problem observed. So apart from discussing the uses and stability of any
do-not-reuse implementation, I would be interested in understanding the
real problem, which started the discussion.

- What is known about the TCP behaviour of the firewall, i.e. what
exactly has been observed with respect to TCP packets?
- What are the platforms and versions of the used components on the
Apache and the Tomcat side?

W.r.t. the problem of shutting down a socket from the apache side and
wasting tomcat threads, I never experienced a problem with that on *nix
systems. I'll check again carefully, but I would be interested in any
concrete information on which platforms and how such a problem can be
reproduced.

Regards,

Rainer

Jim Jagielski schrieb:
> I and other have run into issues where the socket
> between Apache and Tomcat (due to a in-between firewall)
> isn't closed as it should be... I'm digging further into
> this as far as why the timeout isn't being honored, but
> it got me thinking that a "no reuse" option might be
> nice. Basically, it prevents reuse from ever being set
> to TRUE...
> 
> PS: Also to be done with mod_proxy_ajp as well, but that's
> a different list :)
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: possible mod_jk "feature"

[Jim Jagielski]

In a nutshell, there are many cases where Apache httpd and
Tomcat are separated by a firewall, and, as such, there
isn't a one-to-one direct connection. The firewall
will close a connection but one side doesn't
know about it. As such, new requests create more
sockets until TC runs out of threads. mod_jk is
not recycling connections as it should, and
setting the various params (eg: connection_pool_timeout)
does not solve the problem. It's similar to the old
Apache http lingering close problem.

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
is one example of such problems, in which case you
responded and agreed that don't reuse is a last resort
solution.

I just think it would be nice to provide that last
resort :)

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

Re: possible mod_jk "feature"

[Rainer Jung]

Results concerning setting reuse to JK_FALSE:

I tested closing the connections in ajp_done after each request. It
shows the following behaviour:

- TCP packet dump shows a correct Fin-Ack... sequence, i.e. a regular
TCP connection shutdown.

- mod_jk logs opening of a new connection for each request

- Tomcat 5.5.17 logs

DEBUG (ChannelSocket.java:675) - server has been restarted or reset t
his connection

at the end of each connection. The line comes from:

org/apache/jk/common/ChannelSocket.java

...
   663  /** Process a single ajp connection.
   664   */
   665  void processConnection(MsgContext ep) {
   666  try {
   667  MsgAjp recv=new MsgAjp();
   668  while( running ) {
   669  if(paused) { // Drop the connection on pause
   670  break;
   671  }
   672  int status= this.receive( recv, ep );
   673  if( status <= 0 ) {
   674  if( status==-3)
   675  log.debug( "server has been restarted or
reset this connection" );
   676  else
   677  log.warn("Closing ajp connection " +
status );
   678  break;
   679  }
   680  ep.setLong( MsgContext.TIMER_RECEIVED,
System.currentTimeMillis());
   681
...

This block hasn't changed in the last two years.

The "-3" comes from read() in the same Class:

   621  // connection just closed by remote.
   622  if (got <= 0) {
   623  // This happens periodically, as apache restarts
   624  // periodically.
   625  // It should be more gracefull ! - another
feature for Ajp14
   626  // log.warn( "server has closed the current
connection (-1)" );
   627  return -3;
   628  }

- API docs for getInputStream() in Socket say:

==
Under abnormal conditions the underlying connection may be broken by the
remote host or the network software (for example a connection reset in
the case of TCP connections). When a broken connection is detected by
the network software the following applies to the returned input stream:

...

If there are no bytes buffered on the socket, or all buffered bytes have
been consumed by read, then all subsequent calls to read will throw an
IOException.
==

So it looks like this situation should be the same on all platforms.

- Even under "ab -n 1 -c 20" and several JVM Thread-Dumps, I can not
find any Threads in bad stacks.

So I think the Tomcat problem with recent code is a non-issue. If anyone
has different experience please correct me.

Regards,

Rainer


Rainer Jung schrieb:
> I checked the whole thread, but I found no technical description of the
> problem observed. So apart from discussing the uses and stability of any
> do-not-reuse implementation, I would be interested in understanding the
> real problem, which started the discussion.
> 
> - What is known about the TCP behaviour of the firewall, i.e. what
> exactly has been observed with respect to TCP packets?
> - What are the platforms and versions of the used components on the
> Apache and the Tomcat side?
> 
> W.r.t. the problem of shutting down a socket from the apache side and
> wasting tomcat threads, I never experienced a problem with that on *nix
> systems. I'll check again carefully, but I would be interested in any
> concrete information on which platforms and how such a problem can be
> reproduced.
> 
> Regards,
> 
> Rainer
> 
> Jim Jagielski schrieb:
>> I and other have run into issues where the socket
>> between Apache and Tomcat (due to a in-between firewall)
>> isn't closed as it should be... I'm digging further into
>> this as far as why the timeout isn't being honored, but
>> it got me thinking that a "no reuse" option might be
>> nice. Basically, it prevents reuse from ever being set
>> to TRUE...
>>
>> PS: Also to be done with mod_proxy_ajp as well, but that's
>> a different list :)
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: possible mod_jk "feature"

[Rainer Jung]

Jim Jagielski schrieb:
> In a nutshell, there are many cases where Apache httpd and
> Tomcat are separated by a firewall, and, as such, there
> isn't a one-to-one direct connection. The firewall
> will close a connection but one side doesn't
> know about it.

I would call this a broken firewall, right? This kind of behaviour is
expected to produce problems for nearl every communication (I don't say,
we shouldn't provide a workaround).

Still: do you know, what happened in the actual problem case:

- which side of the communication has been shut down by the firewall,
Apache-FW or FW-Tomcat?

- did it reset it, do a full Fin-Ack... or did it just start to silently
drop packets?

- was keep_alive anbled for the worker? This is a standard socket
option, that is used to simulate traffic on a connection. The default
settings for many OSes are interval equals 7200 seconds, so that only
onc every 2 hours a TCP keep alive packet is being sent. Depending on
the FW admins idea about idleness, it might be enough to simply lower
the keep alive interval in the OS TCP configuration. Has this been tried?

> As such, new requests create more
> sockets until TC runs out of threads. mod_jk is
> not recycling connections as it should, and

What do you mean by "not recycling"? I think this symptom hasn't been
reported until now.

> setting the various params (eg: connection_pool_timeout)
> does not solve the problem. It's similar to the old
> Apache http lingering close problem.
> 
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
> is one example of such problems, in which case you
> responded and agreed that don't reuse is a last resort
> solution.

I don't find lingering close in this message. The primary situation for
this user was the need to connect a lot of Apache threads to a tomcat.
In the meantim the APR connector got more stable, so that would be the
best choice for him. If he will still run out of threads on the tomcat
side, he will need to segment his setup into smaller cells. Trying to
"solve" this kind of situation by not reusing connections is really no
solution, but a broken system design.

> I just think it would be nice to provide that last
> resort :)

With this I agree. There is another possible solution:
we could add another parameter to the pool sizing, the max idle count.
This would be exactly analogous to the httpd and tomcat pool semantics.
Setting it to 0 would mean, that no connection will be put back into the
pool and instead all connections are being closed after a request. Comments?

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

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

DO NOT REPLY [Bug 39834] - JkLogLevel debug causes Segmentation fault

[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=39834





--- Additional Comments From [EMAIL PROTECTED]  2006-08-22 20:53 ---
I could not reproduce the segfaults with mod_jk 1.2.18/httpd 2.0.58:

Setting JkLogLevel to error and stressing apache with requests going to tomcat 
and sleeping there for 50 ms with a parallelity of 20 did not produce any 
problem during "apachectl graceful".

When I increased JkLogLevel to debug, I could reproduce the apr_global_mutex_* 
messages, but still *not* the segfaults.

Platform was Linux x86_64 (SLES 9 SP2).

Do you use piped logs for mod_jk? Is it possible, that the reason for the 
segfaults is another module? Are you loading any unusual modules?

In case you want to discuss this further, please open another bugzilla.


-- 
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]

Re: possible mod_jk "feature"

[Jean-frederic Clere]

Rainer Jung wrote:


Jim Jagielski schrieb:
 


In a nutshell, there are many cases where Apache httpd and
Tomcat are separated by a firewall, and, as such, there
isn't a one-to-one direct connection. The firewall
will close a connection but one side doesn't
know about it.
   



I would call this a broken firewall, right?


Yep, but that happends ,-(


This kind of behaviour is
expected to produce problems for nearl every communication (I don't say,
we shouldn't provide a workaround).

Still: do you know, what happened in the actual problem case:

- which side of the communication has been shut down by the firewall,
Apache-FW or FW-Tomcat?
 

I think I have seen a case where the connection Apache-FW was closed 
correctly and the FW-Tomcat just "forgotten".



- did it reset it, do a full Fin-Ack... or did it just start to silently
drop packets?
 

I don't know exactly what happends the only thing I have seen is that 
the TC thread stays in the Socket.read() for about 7 minutes and during 
those 7 minutes httpd creates new connections until TC gets out of threads.



- was keep_alive anbled for the worker? This is a standard socket
option, that is used to simulate traffic on a connection. The default
settings for many OSes are interval equals 7200 seconds, so that only
onc every 2 hours a TCP keep alive packet is being sent. Depending on
the FW admins idea about idleness, it might be enough to simply lower
the keep alive interval in the OS TCP configuration. Has this been tried?

 


As such, new requests create more
sockets until TC runs out of threads. mod_jk is
not recycling connections as it should, and
   



What do you mean by "not recycling"? I think this symptom hasn't been
reported until now.
 


In my case it is but too late!!!

 


setting the various params (eg: connection_pool_timeout)
does not solve the problem. It's similar to the old
Apache http lingering close problem.

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg75444.html
is one example of such problems, in which case you
responded and agreed that don't reuse is a last resort
solution.
   



 


That is not the problem I have seen!

Cheers

Jean-Frederic

+++ CUT  +++

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

Re: possible mod_jk "feature"

[Jim Jagielski]

Jean-frederic Clere wrote:
> Rainer Jung wrote:
> >Jim Jagielski schrieb:
> >  
> >
> >I would call this a broken firewall, right?
> >
> Yep, but that happends ,-(
> 
> I think I have seen a case where the connection Apache-FW was closed 
> correctly and the FW-Tomcat just "forgotten".
> 
> I don't know exactly what happends the only thing I have seen is that 
> the TC thread stays in the Socket.read() for about 7 minutes and during 
> those 7 minutes httpd creates new connections until TC gets out of threads.
> 

Yeah, once it happens, you quickly fall off the cliff.

With the increasing number of environs that are shoving a firewall
between Apache and Tomcat, I've been seeing this more and more
often. Disabling reuse does address the problem; the other "fixes"
involve either crippling Apache (setting MaxRequestsPerChild to 1!)
or dropping AJP all together.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."

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

Re: possible mod_jk "feature"

[Jean-frederic Clere]

Jim Jagielski wrote:


Jean-frederic Clere wrote:
 


Rainer Jung wrote:
   


Jim Jagielski schrieb:


I would call this a broken firewall, right?

 


Yep, but that happends ,-(

I think I have seen a case where the connection Apache-FW was closed 
correctly and the FW-Tomcat just "forgotten".


I don't know exactly what happends the only thing I have seen is that 
the TC thread stays in the Socket.read() for about 7 minutes and during 
those 7 minutes httpd creates new connections until TC gets out of threads.


   



Yeah, once it happens, you quickly fall off the cliff.

With the increasing number of environs that are shoving a firewall
between Apache and Tomcat, I've been seeing this more and more
often. Disabling reuse does address the problem;

Well that is a last chance option. The  socket  has to be reopened the  
whole stuff will be very slow... (What happends with keep-alive...).

Won't |recover_time be more helpfull for that case?|


the other "fixes"
involve either crippling Apache (setting MaxRequestsPerChild to 1!)
 


That adds a fork() to the close/open.


or dropping AJP all together.
 


That isn't a mod_jk feature ;-)

Cheers

Jean-Frederic


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

Re: possible mod_jk "feature"

[Jean-frederic Clere]

Jim Jagielski wrote:


Jean-frederic Clere wrote:
 


Rainer Jung wrote:
   


Jim Jagielski schrieb:


I would call this a broken firewall, right?

 


Yep, but that happends ,-(

I think I have seen a case where the connection Apache-FW was closed 
correctly and the FW-Tomcat just "forgotten".


I don't know exactly what happends the only thing I have seen is that 
the TC thread stays in the Socket.read() for about 7 minutes and during 
those 7 minutes httpd creates new connections until TC gets out of threads.


   



Yeah, once it happens, you quickly fall off the cliff.

With the increasing number of environs that are shoving a firewall
between Apache and Tomcat, I've been seeing this more and more
often. Disabling reuse does address the problem; the other "fixes"
involve either crippling Apache (setting MaxRequestsPerChild to 1!)
or dropping AJP all together.
 

What about a timeout in TC and keep-alive via a PING/PONG initiated by 
httpd before the timeout when nothing send to TC on the worker?

Something like the |worker.maintain enhanced.

Cheers

Jean-Frederic
|

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

DO NOT REPLY [Bug 39834] - JkLogLevel debug causes Segmentation fault

[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=39834





--- Additional Comments From [EMAIL PROTECTED]  2006-08-23 01:41 ---
I have tried to reproduce the graceful segv, but cannot reproduce too.
Platform is: RHEL4U3, kernel-2.6.9-34.EL, httpd-2.0.52-22.ent, mod_jk 1.2.18.

-- 
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]