accept() errors

[Michael Smith]

Hi,

My server (tomcat 4.0, nightly built from about a week ago, running on a
linux system) stopped responding some time last night. The logs contain
nothing of substance except this:

java.net.SocketException: Connection reset by peer
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:413)
at java.net.ServerSocket.implAccept(ServerSocket.java:243)
at java.net.ServerSocket.accept(ServerSocket.java:222)
at
org.apache.catalina.connector.http.HttpConnector.run(HttpConnector.java:764)
at java.lang.Thread.run(Thread.java:484)

So, looking through this, I found that the HttpConnector() just breaks
out of the connect loop when accept() throws a SocketException, after
logging the above message. As a result, the connector stops responding,
so things don't work too well.

So, this is obviously not the best behaviour - a socket exception on
accept is usually not fatal. Unfortunately, java gives us absolutely no
way to find out whether or not it was one of the fatal socket errors.
Most of the time, it's safe to just continue in the main accept loop
here. However, sometimes it's neccesary to close and reopen the socket. 

We don't (can't - java doesn't propogate the info out of the native
methods) know which is the case here. So, it seems we need to
close/reopen the server socket either way - unfortunate, since pending
connections could get dropped, but not too terrible, since accept errors
are fairly rare.

I think the correct thing to do is (in this code from
HttpConnector.java)
try {
socket = serverSocket.accept();
if (connectionTimeout > 0)
socket.setSoTimeout(connectionTimeout);
} catch (IOException e) {
if (started && !stopped)
log("accept: ", e);
break;
}

Change the 'break' to something like:
  serverSocket.close();
  serverSocket = open();
  continue;

I'm not familiar with the tomcat code, though, so I'm not certain this
is correct. Also, this is very difficult to reproduce (it's only
happened once, more or less randomly). Comments? Ideas? People with more
knowledge of low-level socket code?

Michael

chunked input bugfix

[Michael Smith]

Yesterday I saw a bunch of 500 errors come up from a servlet we're
running. 
Fortunately, it turned out that there was a full stacktrace in the log
file.
I think the error itself was due to transient network faults (or client
bugs)at the client end of things, so it's not a problem that tomcat
rejects it - but it shouldn't be throwing a NullPointerException and
returning a 500 error.

This should fix it.

Michael


Index: HttpRequestStream.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpRequestStream.java,v
retrieving revision 1.8
diff -u -r1.8 HttpRequestStream.java
--- HttpRequestStream.java  2001/02/20 21:38:44 1.8
+++ HttpRequestStream.java  2001/06/01 03:14:14
@@ -267,7 +267,9 @@
 chunkPos = 0;
 
 try {
-String numberValue = readLineFromStream().trim();
+String numberValue = readLineFromStream();
+if(numberValue != null)
+numerValue.trim();
 chunkLength = 
 Integer.parseInt(numberValue, 16);
 } catch (NumberFormatException e) {

RE: Jakarta PMC Meeting Agenda / Info

[Michael . Smith]

Since you've posted the URL again, I went back and read the initial proposal
again.  Each time I read the proposal, I'm left with the same thoughts.  

First, let me quote part Craig's message that started the thread and the
voting:

"To facilitate development of Tomcat 4.0, without compromising our
ability to support and enhance the existing Tomcat 3.x code base, I am
hereby submitting three "Long Term Plan" proposals to be discussed and
voted on by the Tomcat developer community."

Based on this and the actual proposed "long term plans" that followed, I'm
not sure how this thread addresses when 3.x code development should end.  In
fact, in that same thread, there seemed to be support for ongoing
enhancements on the 3.x code line, even to the point of supporting the
latest specs:  
http://w6.metronet.com/~wjm/tomcat/2000/Aug/msg00486.html

Therefore, I really don't see how Costin wanting to do a 3.3 is "against
what everyone voted for."  I think it is a separate issue:  How long will
the Jakarta Project and its community support the 3.x codebase in terms of
enhancements, improvements, security fixes, etc.  Or, as you say:  "When
does it stop?"

Have fun at the meeting tomorrow...  :)

michael

---
[EMAIL PROTECTED]
http://www.epiphany.com

> -Original Message-
> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 15, 2001 4:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Jakarta PMC Meeting Agenda / Info
> 
> 
> on 1/15/01 12:56 PM, "Kief Morris" <[EMAIL PROTECTED]> wrote:
> 
> > I think that's _your_ reason for thinking he should go. I 
> get the impression
> > his own reasons for saying he wants to go has a lot more to 
> do with the
> > pressure he's getting to either conform to the party line 
> or get lost. What
> > you say above reads to me as "if he decides to leave it's 
> his own fault for
> > not conforming, it's not my fault for constantly pressuring 
> him to conform".
> 
> No. What I am saying is that as a group, we choose to go in a certain
> direction and voted on it (with zero -1's).
> 
> Let me refer you to this link (again):
> 
> 
> 
> Now, he wants to go against what everyone voted for by 
> continuing on with
> the development of Tomcat 3.x indefinitely. I'm going to call 
> him on that
> because I don't see that as being right. I also don't see a 
> problem with
> questioning the fact that he has completely ignored what we 
> have voted on
> (to the point where he didn't even vote himself!). I don't 
> understand how
> you all can accept Costin's lone wolf mentality when this is 
> supposed to
> really be a community effort.
> 
> My question that I'm going to bring up at the PMC meeting is:
> 
> Where does it stop? If we release 3.3 and there are bugs in 
> it, do we then
> release 3.3.1...3.3.2...3.3.3...3.4...etc...or do we call it 
> quits on that
> tree and focus on 4.0?
> 
> Costin has already stated that he is going to disappear. I 
> have yet to see a
> real solid answer on *when* he is going to disappear, but 
> that probably
> primarily depends on whether or not there will be a 3.3 
> release from the
> Jakarta Project (as decided by the PMC).
> 
> If he decides to disappear after 3.3 is released (which is what he has
> currently stated he will do), then I would be very against 
> making a 3.3
> release within the Jakarta project as the primary developer 
> is not going to
> be around to support it. I would much rather see the 3.3 
> release happen in
> the forum that he is going to be support it under as that 
> will be better for
> the community.
> 
> Heck, today, anyone could go to sourceforge and do their own 
> release of the
> software and call it FooBar 3.3. Same exact code. What is the real
> difference?
> 
> > I don't really see that everyone needs to be marching in 
> lock step, and I
> > don't see the need to bully people who aren't toeing the 
> party line. Tomcat
> > 4 isn't ready yet, does everyone still loyal to the old 3.x 
> order really need
> > to be purged?
> 
> Please follow along more closely. That isn't the issue.
> 
> thanks,
> 
> -jon
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 

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

RE: String/StringBuffer (was Re: An alternative to JSP)

[Michael . Smith]

> Last paragraph in the java.lang.String javadoc says:
> 
> The Java language provides special support for the string 
> concatentation operator
> ( + ), and for conversion of other objects to strings. String 
> concatenation is
> implemented through the StringBuffer class and its append 
> method. String
> conversions are implemented through the method toString, 
> defined by Object and
> inherited by all classes in Java. For additional information 
> on string concatenation
> and conversion, see Gosling, Joy, and Steele, The Java 
> Language Specification. 

And the Java Language Specification (Section 3.10.5: String Literals) says
this:

"Strings computed by constant expressions (§15.27) are computed at compile
time and then treated as if they were literals"

http://java.sun.com/docs/books/jls/html/3.doc.html#101083


> > Just thought that I would point out that: 
> > "My " + "dog " + "has " + "fleas." will be compiled as one String:
> > "My dog has fleas." and incurs no runtime penalties.  In the case
> 
> Paul,
> 
> Actually, my investigations in the past have shown that (at least in
> Sun's JDK 1.2) this is implemented as:
> 
> new StringBuffer 
> ("My").append("dog").append("has").append("fleas").toString();

If this is actually the case, Sun's JDK is not in compliance with the spec.
However, in my tests, this is not the case. 

>From this class: 

public class StringTest {
  static String blah = "My " + "dog " + "has " + "fleas.";
}

The following is the result from "javap -c StringTest" after compiling:

Compiled from StringTest.java
public class StringTest extends java.lang.Object {
static java.lang.String blah;
static {};
public StringTest();
}

Method static {}
   0 ldc #1 
   2 putstatic #5 
   5 return

Method StringTest()
   0 aload_0
   1 invokespecial #4 
   4 return


regards,
michael

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

tomcat4, webdav, and IIS

[Michael Smith]

Hi all,

I'm trying to set up tomcat4.0 (cvs, few days old), talking through
mod_jk (java bits compiled today from cvs, native bits the most recent
compiled version I could find - I don't have a copy of devstudio here)
to IIS (5.0, on win2k), using isapi_redirect.dll .

That bit works fine. Then I throw webdav into the mix - using both
tomcat's built-in webdav servlet and jakarta-slide (well, one then the
other). That _mostly_ works. However, using microsoft web folders, it
fails. Exactly the same server, but a different client (the slide
command line client, for instance), and everything works (same URL, etc.
also).

Has anyone here had any experience with debugging this sort of thing? Am
I going in totally the wrong direction (jk seemed to be the only thing
that had IIS support)? 

>From looking at log files, it seems like this is happening (roughly):
 Normal client:
IIS receives request, forwards to isapi_redirect.dll. This matches
the request to a tomcat 'worker'.
Request gets sent off to tomcat worker, tomcat processes, client
gets useful response.  

 MS Webfolders:
IIS receives request, forwards to isapi_redirect. isapi_redirect
maps it to a tomcat worker.
Request never actually gets sent to tomcat worker (tomcat never sees
anything, as far as I can tell - certainly nothing is logged, and I have
all the debugging on). 
Client gets _some sort_ (unknown details) of response from IIS (NOT
from tomcat), but the response is wrong, so webfolders rejects it
completely.

Note that the config seems to be fine - the requests (according to the
log files) get mapped to the tomcat instance correctly in either case,
it's just that with webfolders thrown in, the request then doesn't
actually get to tomcat. 
Also, a 'normal' HTTP request (i.e. not webdav. GET, for example) works
from everything.

Any advice as to a) what I did wrong, or b) where to start looking for
debugging this myself, would be very much appreciated.



Michael

PATCH: jakarta-tomcat-connectors build on MSVC6

[Michael Smith]

Here's a patch for clean builds on MSVC6 - includes a couple of missing
headers, and adds JK_METHOD attributes to the neccesary functions
(otherwise calling conventions are declared differently, and you get
compilation-fatal errors).

Michael Smith

Index: jk_channel_socket.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_channel_
socket.c,v
retrieving revision 1.2
diff -u -r1.2 jk_channel_socket.c
--- jk_channel_socket.c 2001/11/16 22:48:55 1.2
+++ jk_channel_socket.c 2001/11/19 01:06:39
@@ -73,6 +73,8 @@
 #include "jk_env.h"
 #include "jk_channel.h"
 #include "jk_global.h"
+#include "jk_util.h"
+#include "jk_connect.h"

 #include 

@@ -110,13 +112,13 @@
 static int jk_channel_socket_resolve(char *host, short port,
 struct sockaddr_in *rc);

-static int jk_channel_socket_getProperty(jk_channel_t *_this, 
+static int JK_METHOD jk_channel_socket_getProperty(jk_channel_t *_this, 
 char *name, char **value)
 {
 return JK_FALSE;
 }

-static int jk_channel_socket_setProperty(jk_channel_t *_this, 
+static int JK_METHOD jk_channel_socket_setProperty(jk_channel_t *_this, 
 char *name, char *value)
 {
 jk_channel_socket_private_t *socketInfo=
@@ -134,7 +136,7 @@

 /** resolve the host IP ( jk_resolve ) and initialize the channel.
  */
-static int jk_channel_socket_init(jk_channel_t *_this, 
+static int JK_METHOD jk_channel_socket_init(jk_channel_t *_this, 
  jk_map_t *props,
  char *worker_name,
  jk_worker_t *worker,
@@ -203,7 +205,7 @@

 /** connect to Tomcat (jk_open_socket)
  */
-static int jk_channel_socket_open(jk_channel_t *_this, jk_endpoint_t
*endpoint)
+static int JK_METHOD jk_channel_socket_open(jk_channel_t *_this,
jk_endpoint_t 
*endpoint)
 {
 jk_logger_t *l=_this->logger;
 int err=jk_log(l, JK_LOG_DEBUG, "Into jk_channel_socket_open\n");
@@ -273,7 +275,7 @@

 /** close the socket  ( was: jk_close_socket )
 */
-int jk_channel_socket_close(jk_channel_t *_this, jk_endpoint_t
*endpoint)
+static int JK_METHOD jk_channel_socket_send(jk_channel_t *_this,
  jk_endpoint_t *endpoint,
  char *b, int len)
 {
@@ -340,7 +342,7 @@
  *>0: length of the received data.
  * Was: tcp_socket_recvfull
  */
-static int jk_channel_socket_recv( jk_channel_t *_this,
+static int JK_METHOD jk_channel_socket_recv( jk_channel_t *_this,
   jk_endpoint_t *endpoint,
   char *b, int len )
 {

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

PATCH: more fixes for jakarta-tomcat-connectors

[Michael Smith]

Ok, so with the previous patch stuff built - this one fixes some
_really_ dodgy casts and type errors that were going on (someone 'fixed'
these by casting them to void pointers.). Also added some JK_METHOD
attributes to a couple more methods, and removed the corresponding void
pointer casts for those.

Everything builds nicely under MSVC6 now.

Michael Smith


Index: jk_env.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_env.c,v
retrieving revision 1.3
diff -u -r1.3 jk_env.c
--- jk_env.c2001/11/11 01:17:43 1.3
+++ jk_env.c2001/11/19 01:44:43
@@ -63,10 +63,10 @@
 /* Private methods
 */
 static jk_env_initEnv( jk_env_t *env, char *id );
-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env, 
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t
*env, 
 char *type,
 char *name );
-static void jk_env_registerFactory(jk_env_t *env, 
+static void JK_METHOD jk_env_registerFactory(jk_env_t *env, 
   char *type,
   char *name,
   jk_env_objectFactory_t fact);
@@ -88,14 +88,14 @@
 static jk_env_initEnv( jk_env_t *env, char *id ) {
   /*   env->logger=NULL; */
   /*   map_alloc( & env->properties ); */
-  env->getFactory= (void *)jk_env_getFactory; 
-  env->registerFactory= (void *)jk_env_registerFactory; 
+  env->getFactory= jk_env_getFactory; 
+  env->registerFactory= jk_env_registerFactory; 
   map_alloc( & env->_registry);
   jk_registry_init(env);

 }

-static jk_env_objectFactory_t *jk_env_getFactory(jk_env_t *env, 
+static jk_env_objectFactory_t * JK_METHOD jk_env_getFactory(jk_env_t
*env, 
 char *type,
 char *name )
 {
@@ -111,7 +111,7 @@
   return result;
 }

-static void jk_env_registerFactory(jk_env_t *env, 
+static void JK_METHOD jk_env_registerFactory(jk_env_t *env, 
  char *type,
  char *name,
  jk_env_objectFactory_t fact)
Index: jk_env.h
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_env.h,v
retrieving revision 1.2
diff -u -r1.2 jk_env.h
--- jk_env.h2001/11/11 01:17:43 1.2
+++ jk_env.h2001/11/19 01:44:43
@@ -100,10 +100,9 @@
  * for the various web servers (since the only link is through
  * jk_worker_list.h).
  */
-typedef int (JK_METHOD *jk_env_objectFactory_t)(jk_env_t *env,
- void **result, 
- char *type,
- char *name);
+typedef int (JK_METHOD *jk_env_objectFactory_t)(jk_worker_t **w,
+   const char *name,
+   jk_logger_t *l);

 /** Get a pointer to the jk_env. We could support multiple
  *  env 'instances' in future - for now it's a singleton.
Index: jk_registry.c
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/native/common/jk_registry
.c,v
retrieving revision 1.5
diff -u -r1.5 jk_registry.c
--- jk_registry.c   2001/11/16 22:59:06 1.5
+++ jk_registry.c   2001/11/19 01:44:44
@@ -123,11 +123,11 @@
 printf("jk_registry_init: Assertion failed, env==NULL\n" );
 return;
   }
-  env->registerFactory( env, "worker", "ajp13", (void
*)&ajp13_worker_factory )
;
-  env->registerFactory( env, "worker", "ajp14", (void
*)&ajp14_worker_factory )
;
-  env->registerFactory( env, "worker", "lb",(void
*)&lb_worker_factory );
+  env->registerFactory( env, "worker", "ajp13", &ajp13_worker_factory
);
+  env->registerFactory( env, "worker", "ajp14", &ajp14_worker_factory
);
+  env->registerFactory( env, "worker", "lb",&lb_worker_factory );
 #ifdef HAVE_JNI
-  env->registerFactory( env, "worker", "jni",   (void
*)&jni_worker_factory );
+  env->registerFactory( env, "worker", "jni",   &jni_worker_factory );
 #endif

   env->registerFactory( env, "channel", "socket",

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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.c jk_env.c jk_channel_socket.c

[Michael Smith]

[EMAIL PROTECTED] wrote:
> 
> costin  01/11/19 10:14:38
> 
>   Modified:jk/native/common jk_registry.c jk_env.c jk_channel_socket.c
>   Log:
>   Patch from  Michael Smith.
> 
>   One change I didn't apply is the signature change in jk_env_objectFactory_t.
>   The problem with the worker_factory is that it is specific to workers,
>   while objectFactory can create any kind of jk object.
> 
>   In time we should replace worker_factory and use the new method. ( I'll start
>   this soon, I'm working on a proposal )
> 

Ah. That'd be my misunderstanding of how things work...
_without_ that signature change, though, things still won't compile
(well, they probably will. With _really_ nasty warnings). I suppose the
right thing to do here is to change env->registerFactory() to take a
void * as the last argument - then we're making _explicit_ the fact that
we're doing Very Dodgy Things :-)

Since we're casting this argument later on anyway (because it isn't what
it's declared at) this should be a local change, but I'll have to check.
Does this sound sensible?

It's worth noting (but not actually worth changing things) that C
doesn't allow you to portably cast function pointers to data pointers
(and a void pointer IS a data pointer). I've not yet encountered an
actual implementation where this is an issue, but a lot of compilers
warn about it.

Michael

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

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_registry.cjk_env.c jk_channel_socket.c

[Michael Smith]

[EMAIL PROTECTED] wrote:
> 
> On Tue, 20 Nov 2001, Michael Smith wrote:
> 
> > Ah. That'd be my misunderstanding of how things work...
> > _without_ that signature change, though, things still won't compile
> > (well, they probably will. With _really_ nasty warnings). I suppose the
> > right thing to do here is to change env->registerFactory() to take a
> 
> Well, the right thing would be to change the workers to use the
> right factory method. It is on my todo list, I hope to get to it
> this week.

oh, ok - that's fine then. Things work anyway because everything gets
cast in 15 different directions before it actually get used, but I tend
to be fairly zealous in trying to get code I work on or use to compile
without warnings :-)


> 
> > It's worth noting (but not actually worth changing things) that C
> > doesn't allow you to portably cast function pointers to data pointers
> > (and a void pointer IS a data pointer). I've not yet encountered an
> > actual implementation where this is an issue, but a lot of compilers
> > warn about it.
> 
> Sorry, it's a long time since I last programmed C. I have a hard time
> re-getting used with it :-)  Exceptions/stackTrace are the thing I miss the most,
> followed by getters/setters. ( for the second - I think I'll add get/setProperty to
> all new objects, for the first - I'm still looking for a trick that doesn't
> involve setjmp )

Not a problem.. Just thought I'd point it out. Exceptions are nice, but
there isn't any portable way to implement them in C (apart from setjmp
tricks, but that has a tendency to play havoc with... well, everything,
if you use them in a larger program.) - when you do most of your
programming in C, you get used to it and find different ways to design
your code (and hey, I _like_ C. Call me insane if you will - you
wouldn't be the first :-))

Michael

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

PATCH: DbcpDataSourceFactory

[Michael Smith]

The DataSource factory wasn't setting maxIdle, and was incorrectly
setting maxActive
on the connection pool. This fixes it:

Michael


Index: DbcpDataSourceFactory.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/DbcpDataSourceFactory.java,v
retrieving revision 1.4
diff -u -r1.4 DbcpDataSourceFactory.java
--- DbcpDataSourceFactory.java  26 Dec 2001 01:22:10 -  1.4
+++ DbcpDataSourceFactory.java  10 May 2002 02:23:17 -
@@ -248,7 +248,7 @@
 }
 try {
 if (maxIdle != null)
-connectionPool.setMaxActive(Integer.parseInt(maxIdle));
+connectionPool.setMaxIdle(Integer.parseInt(maxIdle));
 } catch (Throwable t) {
 log("Error setting maxIdle", t);
 }

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?

[Michael Smith]

micael wrote:
> 
> I cannot access a webapp with the normal
> http://localhost:8080/myapp/servlet/mydirectory.MyServlet with Tomcat
> 4.1.12.  (Also, the embedded Tomcat 4.1.12 in JBoss 3.0.3 runs fine except
> that it won't access the examples servlets.)  The error shown is a 404 "The
> requested resource (/myapp/servlet/mydirectory.MyServlet) is not
> available.".  The same thing runs fine with Tomcat 4.1.0., both with and
> without JBoss.  Is this a BUG in Tomcat 4.1.12, or are there new
> constraints on reaching servlets from outside the container in 4.1.12?
> 

For security reasons (see the release notes for details), the invoker
servlet is disabled by default now. This servlet is what makes
/webapp/servlet/... paths invoke the given servlet. It's recommended
that you give explicit servlet definitions and mappings in the webapps's
web.xml instead.

Michael

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.1.12 and Servlet Access 404 Errors: BUG?

[Michael Smith]

micael wrote:
> 
> I cannot see any difference relative to the invoker filter, ExampleFilter,
> in the web.xml for Tomcat 4.1.10 versus 4.1.12.  Nothing seems to be
> commented out.  I must be missing some point here.  What is it?

The invoker servlet, whilst still defined in 4.1.12, has no
servlet-mapping defined for it in that version (it's commented out). All
of this is in the default/fallback conf/web.xml

Michael

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Bug 13736

[Michael Smith]

Remy Maucherat wrote:
> 
> Bill Barker wrote:
> 
> > I don't remember anything like that for 3.3.x (and nothing even close is
> > open in BZ).  But, then again, I don't imagine that very many people
> > try and
> > use the Http10Connector in production, and Coyote is only available in the
> > nightly for 3.3 until 3.3.2 comes out.
> >
> > o.a.t.u.net.PoolTcpEndpoint won't close the ServerSocket itself without
> > shutting down.  It looks like the root cause is from the JVM, nio, O/S, or
> > some other place we can't see.
> 
> (forwarding to tomcat-dev)
> 
> Ok, I looked at it more, and the TCP endpoint code considers an
> exception during accept a normal event:

Yes. This is correct - from memory, I think it can happen if the client
disconnects mid-way through the TCP handshaking. Not entirely sure,
though. Really, you have to look down at the system call level, see what
the BSD socket interface defines on accept(2) - java rightfully doesn't
really document this in the detail you need to determine what's going
on.

However, there are probably OTHER cases where an IOException (or other
exception) from accept is a (fatal?) error. Unfortunately, java doesn't
give any way to distinguish between these two cases. I suspect the best
one can do is a highly platform-and-implementation-specific string
comparison on the message in the exception. Nasty.

> 
> OTOH, I don't think this should be the case, and I think we should
> stop/start the server socket in that particular case, as was done in the
> old HTTP connector:

Though this is sometimes better (in the case when there's a real/fatal
error), the much more common case is that it was just a straightforward
client disconnect (at a particularly inconvenient point, admittedly). In
this case, shutting down the server socket and reopening it is wrong for
at least two major reasons:
  1) Any other connections sitting in the socket accept queue are
unceremoniously dropped. Legitimate client requests are lost.
  2) In some cases, it won't be possible to reopen the socket. Consider
a unix system that starts as root, binds to port 80, then drops privs.
(It SHOULD be possible to work around this, by keeping the socket bound,
but reopening it. The current code doesn't do this, and it's possible
that java won't let you).

If you can't distinguish between the fatal/normal cases (both of which
are reported as IOException), there is NO WAY to do the correct thing -
whichever way you do it will be wrong sometimes.

Michael

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat memory management

[Michael Smith]

Scott Johnson wrote:
> 
> Hello,
> 
> We've got an application that is replicated for clients, each
> replication runs in its own context. We're running jdk1.4.1, RH7.2,
> Tomcat 4.0.6
> 
> Even though the application itself can run fine on 10mb RAM, as each
> context initializes, EVERY thread allocates more memory until we get
> 20-30 contexts up with each context taking 60-90mb RAM:
> 
> An example process output will have one entry like this for every
> context:
> root  2900  0.0  6.6 257624 68556 pts/1  S18:32   0:00
> /usr/java/jdk1.4.1_01/bin/java -Xmx10m
> -Djava.endorsed.dirs=/usr/java/tomcat/bin:/usr/java/tomcat/common/lib
> -classpath
> /usr/java/jdk1.4.1_01/lib/tools.jar:/usr/java/tomcat/bin/bootstrap.jar -
> 
> As you can see, the -Xmx... argument is of no effect as these processes
> are taking 68mb.
> 
> For us the optimal solution would be to have a single process handling
> all of the contexts, or have each context limited to 10mb.
> 
> I've searched for a configuration to allow the former, and the Xmx arg
> isn't working on the latter. Does anyone have any ideas?

Under linux, the distinction between threads and processes is fairly
small - and ps doesn't (in that version) display threads differently.

What you _actually_ have here are threads - but only a single process.
The memory usage you see on each of these threads is actually shared
across all of the threads for that JVM (the JVM is a single process). So
this isn't really a problem - you have 70 megs (or whatever) used _in
total_ by the JVM, across 20-30 threads. 

Michael

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Thread priority

[Michael Smith]

Remy Maucherat wrote:

Hi,

I was wondering about how expensive the Thread.setPriority method is, 
and to which extent it does what it advetises.

Remy,

Thread.setPriority will (in a native threading implementation, rather 
than something like the old green-threads JVM) be a system call, so it's 
not free - but it's not a particularly expensive syscall. Expense is 
probably similar to the various socket calls like setTimeout(), etc. So 
it's cheap enough to do once or twice per connection.

The extent to which it has an effect is very much platform (and probably 
JVM) dependent. It's also dependent on the permissions a user has - on 
many (all?) unix systems, only root may set a process or thread to 
higher than normal priority (unless the JVM itself is doing some 
scheduling, which I doubt is the case with modern native-threading JVMs).

I suspect that this will mean that your suggested use of these calls 
will either fail, or have no effect (the latter being more likely) on 
most common JVM implementations. It's still worth setting the background 
reloader thread(s) to low priority, though.

In short - this shouldn't hurt in any noticable way, but it's pretty 
unlikely to make any noticable difference in performance.

Mike Smith


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: MOVE method processing of WebdavServlet

[Michael Smith]

Yokota Takehiko wrote:

Hi, all.

There is a question about WebdavServlet in Tomcat4.1.12.

I tried to send MOVE request to WebdavServlet
and I expected that a file was moved, but it was copied and deleted.

I think org.apache.catalina.servlets.WebdavServlet#doMove() should
move resource instead of copying and deleting. (Or first try to move,
and then copy and delete if it failed).

What do you think this idea is?


The webdav spec says that a MOVE should be treated as a COPY followed by 
a DELETE. It's difficult to precisely maintain these semantics without 
actually _doing_ a copy then a delete (though in the fairly limited 
catalina webdav servlet it shouldn't be too hard). There's no compelling 
reason to make this change.

Mike



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Shutdown.sh does not work when long lasting operations, suchas SQL Queries, are still active!

[Michael Smith]

Tim Funk wrote:

Why is a kill done instead of a System.exit()?


System.exit() is a cleaner solution, but there are plenty of cases where 
tomcat won't shut down at all with this solution, so a kill is needed 
(either as suggested, or manually/externally). For example, I had a bug 
in a webapp a while ago (the servlet was marked as load-on-startup, so 
it was starting up before tomcat was fully running) where the servlet 
was hanging, so tomcat never fully started up. As a result, it wasn't 
listening on the shutdown socket, so anything requiring in-process 
intervention such as System.exit() would fail.

Perhaps have both?




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

Re: JK2 module for AOLserver

[Michael Smith]

Alexander Leyke wrote:
Hi,

A question about enhancement adoption process - how long does it 
typically take for new code to show up in CVS, in nightly builds? What 
is the verification process for new code? I have posted enhancement 
request to the mailing list and to Bugzilla 
(http://issues.apache.org/bugzilla/show_bug.cgi?id=18283).

Thanks,
Alex
Alex,

This tends to vary a lot. For features which a lot of people want, or 
for features that one of the committers is personally interested in, 
adoption (assuming the code is of appropriate quality - I've seen more 
than a few patches that have simply been ignored because they're 
absolutely terrible (I'm not suggesting this is the case for you)) tends 
to be very fast - within a day or two.

For less widely used things like your contribution here, it can take 
quite a long time sometimes, and perhaps a bit of nagging at one or two 
of the contributors (though that can, of course, have negative impact as 
well - don't annoy them too much :-)

Taking a large patch, checking it for quality/acceptability, etc. is not 
a trivial amount of work, so it could be a while until someone has the 
time to integrate this. Don't despair, though!

Mike



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

Re: [PROPOSAL] Add Post to the clear list for protected pages

[Michael Smith]

Costin Manolache wrote:
Bill Barker wrote:


At the moment (with the default settings), Tomcat 4.1.x and higher add
HTTP headers to non-SSL protected pages to prevent intermediate proxies
from
caching them.  According to the HTTP/1.1 RFC (and even the HTTP/1.0 RFC),
POSTed pages are not allowed to be cached by proxies (for the obvious
reasons).  I'd like to add request.getMethod().equals("POST") to the list
of conditions to *not* add the headers.


Not sure I understand :-)

The RFC requires that proxies don't cache POST requests. Are you saying 
we should *not* include the headers, because proxies will not cache anyway ?
Or to add the headers ? And what does it has to do with SSL ?

(as an interested observer who has been fighting caching problems both 
with and without SSL for the last couple of days...)

Currently tomcat sets no-cache headers (Pragma: no-cache, Cache-Control: 
 no-cache, and an Expires header) IF:
The resource is protected (requires authentication)
AND The resource is NOT accessed via SSL (since intermediaries 
won't ache things that are using SSL, I think). This is also neccesary 
to get internet explorer to behave sanely when serving files that it 
needs to open in an external program.

There's also a flag that disables this behaviour entirely.

As you correctly interpreted, Bill's suggestion is that these headers 
should _not_ be added for POST requests, because intermediaries will not 
cache these anyway. Disallowing caching has a tendency to cause 
undesirable behaviour on the client end (at least with IE, which many of 
us have to support), so my guess is that that is why Bill doesn't want 
these headers added in this case.

Mike Smith

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