cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[billbarker]

billbarker2003/09/12 21:01:24

  Modified:util/java/org/apache/tomcat/util/net Tag: coyote_10
PoolTcpEndpoint.java
  Log:
  Port patch.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.12.2.2  +4 -4  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.12.2.1
  retrieving revision 1.12.2.2
  diff -u -r1.12.2.1 -r1.12.2.2
  --- PoolTcpEndpoint.java  12 Sep 2003 03:53:03 -  1.12.2.1
  +++ PoolTcpEndpoint.java  13 Sep 2003 04:01:24 -  1.12.2.2
  @@ -380,7 +380,7 @@
   if (accepted != null) {
   try {
   accepted.close();
  -} catch(Exception ex) {
  +} catch(Throwable ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  accepted, ex);
   log.warn(msg, ex);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[billbarker]

billbarker2003/09/12 20:59:57

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Catch all throwables when trying to close the socket.
  
  Revision  ChangesPath
  1.17  +4 -4  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- PoolTcpEndpoint.java  12 Sep 2003 03:51:36 -  1.16
  +++ PoolTcpEndpoint.java  13 Sep 2003 03:59:57 -  1.17
  @@ -389,7 +389,7 @@
   if (accepted != null) {
   try {
   accepted.close();
  -} catch(Exception ex) {
  +} catch(Throwable ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  accepted, ex);
   log.warn(msg, ex);
  
  
  

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

Re: [PATCH] Performance Problems in Coyote Chunking

[Marc Slemko]

On Fri, 12 Sep 2003, Remy Maucherat wrote:

> Steve Appling wrote:
>
> > The following patch combines the 3 packets that were generated for each
> > chunk into just one packet.  There are more optimizations elsewhere - I'll
> > keep looking.
> >
> > Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27
> > src.
>
> After testing and benching, implementing buffering at the lower layer is
> much better, as it avoids introducing complexity in all the levels of
> processing, and is more powerful. The performance impact of the new
> behavior is minimal (using a worst case scenario of a static file, the
> difference is about 2-3%).
> I believe the updated implementation will meet your needs.
>
> What's the most optimal packet size overall, BTW ? 1500 ?

there is nothing inherently relating chunk sizes in chunked output to
packet sizes.

>From the network perspective, you want some reasonably sized (at a minimum
8k; that is what Apache uses)  buffer between the code generating content
and the network, and you never want to explicitly flush that to the
network unless you are actually at the end of a response.

You have no idea what the MTU on the network is, and your code shouldn't
care.  It should just present the data to the network stack in as big of a
buffer as practical (ie. in one write call), and let it worry about that.

You don't want to be creating HTTP chunks arbitrarily, you only want to do
that when you are writing a buffer to the network layer.  Normally one
HTTP chunk should span multiple packets when the network layer puts it on
the wire.

In an ideal world, you could just use a GatheringByteChannel to present
the chunk header and the chunk to the network layer at the same time (ie.
ala writev()), but compatibility issues are a problem for now.

In addition, when serving truly static content where you can determine the
content length in advance (eg. serving an image from disk), avoiding
chunking alltogether and just setting a content length is definitely
preferred.

At the end, if you are sending a response with 300 bytes of headers and
800 bytes of content, the content should be in at most one chunk and the
headers and content should end up on the network in the same packet,
assuming a MTU of at least 1500.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Remy Maucherat]

Bill Barker wrote:
I don't know. From traces I saw, there are conditions where there could
be no thread listening on the socket (at that point, the connector was
dead, of course), while everything else in the TP was looking ok
(including no deadlock). There didn't seem to be anything in the logs
related to an error during accept.
If you max out the threads, then the thread that is waiting in ThreadPool is
the one that will do the next accept.  It's supposed to be a temporary
condition (since a thread should get returned to to Pool soon).  Porting the
connectionTimeout throttling back to 4.1 should make it more responsive in
this case (since Tomcat will stop doing keep-alives).  Of course, what it's
really telling you is that your maxProcessors is set too low :).
I haven't been able to measure the effects of this, so I am unsure of 
the usefulness of the feature. Anyone having conducted more serious 
testing with TC 5 yet ?

Remy

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

DO NOT REPLY [Bug 22625] - Removing a webapp(context) doesn't close its datasources(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://nagoya.apache.org/bugzilla/show_bug.cgi?id=22625

Removing a webapp(context) doesn't close its datasources(resource)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 20:10 ---
See reasoning in bug 22626.

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

Re: [PATCH] Performance Problems in Coyote Chunking

[Remy Maucherat]

Steve Appling wrote:

The following patch combines the 3 packets that were generated for each
chunk into just one packet.  There are more optimizations elsewhere - I'll
keep looking.
Patch of org.apache.coyote.http11.filters.ChunkedOutputFilter from 4.1.27
src.
After testing and benching, implementing buffering at the lower layer is 
much better, as it avoids introducing complexity in all the levels of 
processing, and is more powerful. The performance impact of the new 
behavior is minimal (using a worst case scenario of a static file, the 
difference is about 2-3%).
I believe the updated implementation will meet your needs.

What's the most optimal packet size overall, BTW ? 1500 ?

Remy



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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util RequestUtil.java

[luehe]

luehe   2003/09/12 12:54:57

  Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
  Log:
  Reverted patch for 4918152 ("using % in the value of jsp:param
  corrupts the query string"), as it is not needed for JSP 2.0.
  
  JSP.5.6 ("") has clarified the potential trouble spot as follows:
  
The parameter names and values specified should be left unencoded by the
page author. The JSP container must encode the parameter names and values
using the character encoding from the request object when necessary. For
example, if the container chooses to append the parameters to the URL in
the dispatched request, both the names and values must be encoded as per
the content type application/x-www-form-urlencoded in the HTML specification.
  
  Revision  ChangesPath
  1.6   +6 -11 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/RequestUtil.java
  
  Index: RequestUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/RequestUtil.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- RequestUtil.java  11 Sep 2003 01:59:51 -  1.5
  +++ RequestUtil.java  12 Sep 2003 19:54:56 -  1.6
  @@ -536,13 +536,8 @@
   data[ox++] = (byte)' ';
   break;
   case '%':
  -if ((ix <= (data.length - 2)) &&
  -((char)data[ix] != '&') && ((char)data[ix+1] != '&')) {
  -data[ox++] = (byte)((convertHexDigit(data[ix++]) << 4)
  -   + convertHexDigit(data[ix++]));
  -} else {
  -data[ox++] = c;
  -}
  +data[ox++] = (byte)((convertHexDigit(data[ix++]) << 4)
  ++ convertHexDigit(data[ix++]));
   break;
   default:
   data[ox++] = c;
  
  
  

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

DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146

Calling socket.setTcpNoDelay causes connector to disconnect





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 19:49 ---
You should move to using the CoyoteConnector.  Its a lot better in general. 
Luckily, it calls setTcpNoDelay in the WorkerThread, rather than in the
ServerSocket thread.  So your problem doesn't occur.  Although as far as I can
tell there is less, although likely still some threads serving the request.  

java.net.SocketException: Invalid argument
at java.net.PlainSocketImpl.socketSetOption(Native Method)
at java.net.PlainSocketImpl.setOption(PlainSocketImpl.java:240)
at java.net.Socket.setTcpNoDelay(Socket.java:745)
at 
org.apache.tomcat.util.net.PoolTcpEndpoint.setSocketOptions(PoolTcpEndpoint.java:468)
at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:564)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:536)

>From some of the open bugs, I think the Catalina HttpConnector is basically
unmaintained.

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

DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146

Calling socket.setTcpNoDelay causes connector to disconnect





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 19:40 ---
I think that's good, but it doesn't really change the fact that the exception 
isn't being checked for at all.

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

DO NOT REPLY [Bug 23146] - Calling socket.setTcpNoDelay causes connector to disconnect

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146

Calling socket.setTcpNoDelay causes connector to disconnect





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 19:38 ---
We are getting this on a Solaris box.  Occasionally occurs.

I have filed a bug with Sun, because I can't see why this should be failing.   
I searched the web and found two previous cases of this, one Jetty and one
Tomcat, but no solution was found for either.  Both on solaris boxes.

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

DO NOT REPLY [Bug 23146] New: - Calling socket.setTcpNoDelay causes connector to disconnect

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23146

Calling socket.setTcpNoDelay causes connector to disconnect

   Summary: Calling socket.setTcpNoDelay causes connector to
disconnect
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:HTTP/1.1 (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In org.apache.catalina.connector.HttpConnector, line 1028, the connector calls 
setTcpNoDelay on the newly created socket.  This method can throw a 
SocketException, which is not caught.  The exception causes the HttpConnector 
thread to finish, removing the Socket object without explicitly closing the 
underlying network socket.  Tomcat then attempts to recreate the HttpConnector, 
which attempts to open a new socket with the same address binding.  This will 
fail, and the application will then cease to respond on the given HTTP port.

This is happening very intermittently on a production machine we have.  This is 
very difficult to replicate, but I hope that we have given enough details to 
fix the underlying problem, which is the uncaught SocketException.

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

RE: BindException :: Shutdown Port 8005 :: Solaris 5.9

[Ricardo Mattier]

Hey,
I'm new to the Tomcat experience.  I don't know it this helps,
but have you tried to create a virtual ip and start Tomcat that way?  I
ran into the same problem, so I ran it on its own IP and it works fine
now.

-Original Message-
From: Juanpablo Lajud [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 12, 2003 3:20 PM
To: [EMAIL PROTECTED]
Subject: BindException :: Shutdown Port 8005 :: Solaris 5.9

Hi all,

I am experiencing difficulties with port 8005. It crashes
with a BindException after trying to start it.

OS:  SunOS 5.9
www2# java -showversion
java version "1.4.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.0_03-b04)
Java HotSpot(TM) Client VM (build 1.4.0_03-b04, mixed mode)


I have tried 5 different Tomcat Versions:

3.3.1a  - Works

4.1.18  - Crashes
4.1.27  - Crashes
5.0.11  - Crashes
Sun JWSDP 1.2   - Crashes

In all cases after waiting for $CATALINA_HOME/bin/startup.sh quite a
while.
I get the following error at  $CATALINA_HOME/logs/catalina.out:

StandardServer.await: create[8005]: java.net.BindException: Cannot
assign
requested address
java.net.BindException: Cannot assign requested address
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:321)
at java.net.ServerSocket.bind(ServerSocket.java:308)
at java.net.ServerSocket.bind(ServerSocket.java:266)
at java.net.ServerSocket.(ServerSocket.java:182)
at
org.apache.catalina.core.StandardServer.await(StandardServer.java:523)
at org.apache.catalina.startup.Catalina.await(Catalina.java:633)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces



I have checked if I have a server using that specific port and
it  doesn´t seem to be the case.

www2# netstat -an | grep 8080
www2#


I even tried by changing the port on the server.xml file to another and
it
continues
to crash.

The user with which I am trying to start the service is root. I don´t
see
why
it wouldn´t have permission to start it.

I have checked who is the owner of the Tomcat Files, and in all cases it
is
root.

www2# ls -la
-rwxr-xr-x   1 root root 788 Dec 19  2002 startup.sh


Do you have a clue on what is going on here, is there any well known
problem
or




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

BindException :: Shutdown Port 8005 :: Solaris 5.9

[Juanpablo Lajud]

Hi all,

I am experiencing difficulties with port 8005. It crashes
with a BindException after trying to start it.

OS:  SunOS 5.9
www2# java -showversion
java version "1.4.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_03-b04)
Java HotSpot(TM) Client VM (build 1.4.0_03-b04, mixed mode)


I have tried 5 different Tomcat Versions:

3.3.1a  - Works

4.1.18  - Crashes
4.1.27  - Crashes
5.0.11  - Crashes
Sun JWSDP 1.2   - Crashes

In all cases after waiting for $CATALINA_HOME/bin/startup.sh quite a while.
I get the following error at  $CATALINA_HOME/logs/catalina.out:

StandardServer.await: create[8005]: java.net.BindException: Cannot assign
requested address
java.net.BindException: Cannot assign requested address
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:321)
at java.net.ServerSocket.bind(ServerSocket.java:308)
at java.net.ServerSocket.bind(ServerSocket.java:266)
at java.net.ServerSocket.(ServerSocket.java:182)
at
org.apache.catalina.core.StandardServer.await(StandardServer.java:523)
at org.apache.catalina.startup.Catalina.await(Catalina.java:633)
at org.apache.catalina.startup.Catalina.start(Catalina.java:595)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces



I have checked if I have a server using that specific port and
it  doesn´t seem to be the case.

www2# netstat -an | grep 8080
www2#


I even tried by changing the port on the server.xml file to another and it
continues
to crash.

The user with which I am trying to start the service is root. I don´t see
why
it wouldn´t have permission to start it.

I have checked who is the owner of the Tomcat Files, and in all cases it is
root.

www2# ls -la
-rwxr-xr-x   1 root root 788 Dec 19  2002 startup.sh


Do you have a clue on what is going on here, is there any well known problem
or




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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Bill Barker]

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, September 12, 2003 1:38 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


> Bill Barker wrote:
> >>On 12 Sep 2003, <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> +++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
> >>> @@ -389,12 +389,12 @@
> >>>  if (accepted != null) {
> >>>  try {
> >>>  accepted.close();
> >>> -accepted = null;
> >>>  } catch(Exception ex) {
> >>>  msg = sm.getString("endpoint.err.nonfatal",
> >>> accepted, ex);
> >>>  log.warn(msg, ex);
> >>>  }
> >>> +accepted = null;
> >>>  }
> >>>
> >>>  if( ! running ) return null;
> >>
> >>wouldn't it be better to put the "accepted = null" into a finally
> >>block so you clean up even in the (unlikely but possible) case where
> >>close throws an Error (or Throwable) instead of an Exception?
> >
> > Wouldn't do anything.  The 'accepted' variable is local to the
stack-frame,
> > so it goes away if I throw clear of the method.  In this case you just
get a
> > DoS condition where no threads are listening on the ServerSocket.  I
briefly
> > thought about changing the catch to 'Throwable', but is it really
possible
> > for Socket.close to throw anything other than an Exception?
>
> I don't know. From traces I saw, there are conditions where there could
> be no thread listening on the socket (at that point, the connector was
> dead, of course), while everything else in the TP was looking ok
> (including no deadlock). There didn't seem to be anything in the logs
> related to an error during accept.

If you max out the threads, then the thread that is waiting in ThreadPool is
the one that will do the next accept.  It's supposed to be a temporary
condition (since a thread should get returned to to Pool soon).  Porting the
connectionTimeout throttling back to 4.1 should make it more responsive in
this case (since Tomcat will stop doing keep-alives).  Of course, what it's
really telling you is that your maxProcessors is set too low :).

>
> I'd catch throwable just to be safe, personally :)

I'll catch throwable then.

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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java

[remm]

remm2003/09/12 10:04:12

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
  Log:
  - Remove overriding the mapped servlet path with the jsp-file. I cannot find
anything in the specification which says that it must be done, and it contradicts
all the other mapping rules. This code was introduced in Tomcat 4.0 b5 (yes,
I had to go back for a *while*).
  - This fixes tester failures with the latest changes to JSP servlet.
  
  Revision  ChangesPath
  1.26  +4 -13 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
  
  Index: ApplicationDispatcher.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- ApplicationDispatcher.java2 Sep 2003 21:22:04 -   1.25
  +++ ApplicationDispatcher.java12 Sep 2003 17:04:12 -  1.26
  @@ -196,15 +196,6 @@
   this.pathInfo + ", queryString=" + queryString +
   ", name=" + this.name);
   
  -// If this is a wrapper for a JSP page (), tweak
  -// the request parameters appropriately
  -String jspFile = wrapper.getJspFile();
  -if (jspFile != null) {
  -if ( log.isDebugEnabled() )
  -log.debug("-->servletPath=" + jspFile);
  -this.servletPath = jspFile;
  -}
  -
   }
   
   
  
  
  

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

mod_jk2 on aix - Urgent

[Ajay Arora]

Greetings,
  I was installing mod_jk2 to interact between apache 2 and tomcat 1.4. I 
was not able to build the module. It says jni_md.h is missing. I am having 
java1.3.1 and I do not have include directory with it.

Can somebody will help mw with it. Can anybody has compiled mod_jk2 for aix 
5.1 or can any body provide me the include directory.

Ajay

_
Attention NRIs! Banking worries? 
http://server1.msn.co.in/msnspecials/nriservices/index.asp Get smart tips.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

[remm]

remm2003/09/12 07:07:30

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Oops, the context classloader binding is wrong, which does not allow a
reload (bug 23131).
  
  Revision  ChangesPath
  1.91  +11 -2 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.90
  retrieving revision 1.91
  diff -u -r1.90 -r1.91
  --- StandardContext.java  9 Sep 2003 15:27:00 -   1.90
  +++ StandardContext.java  12 Sep 2003 14:07:30 -  1.91
  @@ -4380,7 +4380,16 @@
   
   if (getLoader() != null) {
   if (reloadable && (getLoader().modified())) {
  -reload();
  +try {
  +Thread.currentThread().setContextClassLoader
  +(StandardContext.class.getClassLoader());
  +reload();
  +} finally {
  +if (getLoader() != null) {
  +Thread.currentThread().setContextClassLoader
  +(getLoader().getClassLoader());
  +}
  +}
   }
   if (getLoader() instanceof WebappLoader) {
   ((WebappLoader) getLoader()).closeJARs(false);
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[remm]

remm2003/09/12 07:06:21

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - ThreadDeath is a more appropriate error in this situation.
  
  Revision  ChangesPath
  1.26  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.25
  retrieving revision 1.26
  diff -u -r1.25 -r1.26
  --- WebappClassLoader.java6 Sep 2003 17:49:31 -   1.25
  +++ WebappClassLoader.java12 Sep 2003 14:06:21 -  1.26
  @@ -1249,7 +1249,7 @@
   // Don't load classes if class loader is stopped
   if (!started) {
   log.info(sm.getString("webappClassLoader.stopped"));
  -throw new IncompatibleClassChangeError(name);
  +throw new ThreadDeath();
   }
   
   // (0) Check our previously loaded local class cache
  
  
  

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

DO NOT REPLY [Bug 23105] - JkMount overrides Alias

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105

JkMount overrides Alias





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 13:35 ---
Works has been conducted in jk 1.2.4 around DirectoryIndex which should help 
you.

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

DO NOT REPLY [Bug 23105] - JkMount overrides Alias

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105

JkMount overrides Alias





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 13:32 ---
The mod_jk I tested it with is mod_jk-1.2.3
is this problem addressed in the 1.2.5 version?

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

[Fwd: Need Tomcat 4.0.6 LE (jdk1.4) Binaries]

[Pier Fumagalli]

Getting a lot of those... You might want to update the links in the 
website to point to the mirrors?

	Pier

--- Begin Message ---

We are using Tomcat 4.0.6 and I need
to download binaries, both the Windows install version and for Linux. Recently
4.0.6 downloads have disappeared from your website. The page http://jakarta.apache.org/site/other-releases.html
has a link for 4.0.6 binaries, but I get a 403 Forbidden error when I follow
the link (http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.6/).

Can you help me?

--Marc Riehm, Maptuit Corporation.--- End Message ---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java

[remm]

remm2003/09/12 06:17:06

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
  Log:
  - Remove useless flush.
  
  Revision  ChangesPath
  1.11  +4 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
  
  Index: ErrorReportValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ErrorReportValve.java 2 Sep 2003 21:22:03 -   1.10
  +++ ErrorReportValve.java 12 Sep 2003 13:17:06 -  1.11
  @@ -370,7 +370,6 @@
   // If writer is null, it's an indication that the response has
   // been hard committed already, which should never happen
   writer.write(sb.toString());
  -writer.flush();
   
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java

[remm]

remm2003/09/12 06:16:41

  Modified:catalina/src/share/org/apache/coyote/tomcat5
OutputBuffer.java
  Log:
  - When flush is called, call the appropriate action to do a lower level flush.
  - Don't flush at the end of request processing.
  
  Revision  ChangesPath
  1.6   +18 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java
  
  Index: OutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- OutputBuffer.java 2 Sep 2003 21:21:59 -   1.5
  +++ OutputBuffer.java 12 Sep 2003 13:16:41 -  1.6
  @@ -68,6 +68,7 @@
   import java.util.HashMap;
   
   import org.apache.catalina.connector.ClientAbortException;
  +import org.apache.coyote.ActionCode;
   import org.apache.coyote.Response;
   import org.apache.tomcat.util.buf.ByteChunk;
   import org.apache.tomcat.util.buf.C2BConverter;
  @@ -321,7 +322,7 @@
   }
   }
   
  -flush();
  +doFlush(false);
   closed = true;
   
   coyoteResponse.finish();
  @@ -336,6 +337,17 @@
*/
   public void flush()
   throws IOException {
  +doFlush(true);
  +}
  +
  +
  +/**
  + * Flush bytes or chars contained in the buffer.
  + * 
  + * @throws IOException An underlying IOException occurred
  + */
  +protected void doFlush(boolean realFlush)
  +throws IOException {
   
   if (suspended)
   return;
  @@ -352,6 +364,11 @@
   coyoteResponse.sendHeaders();
   }
   doFlush = false;
  +
  +if (realFlush) {
  +coyoteResponse.action(ActionCode.ACTION_CLIENT_FLUSH, 
  +  coyoteResponse);
  +}
   
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java Http11Processor.java Http11Protocol.java InternalOutputBuffer.java

[remm]

remm2003/09/12 06:15:36

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java Http11Protocol.java
InternalOutputBuffer.java
  Log:
  - Add a buffer at the socket layer, configured using the socketBuffer
attribute. Add handling for explicit client flushes.
  
  Revision  ChangesPath
  1.17  +1 -1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- Constants.java2 Sep 2003 21:34:39 -   1.16
  +++ Constants.java12 Sep 2003 13:15:36 -  1.17
  @@ -239,7 +239,7 @@
   /**
* Ack string when pipelining HTTP requests.
*/
  -public static final byte[] ACK =
  +public static final byte[] ACK_BYTES =
   "HTTP/1.1 100 Continue\r\n\r\n".getBytes();
   
   
  
  
  
  1.78  +30 -0 
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.77
  retrieving revision 1.78
  diff -u -r1.77 -r1.78
  --- Http11Processor.java  7 Sep 2003 18:04:58 -   1.77
  +++ Http11Processor.java  12 Sep 2003 13:15:36 -  1.78
  @@ -274,6 +274,12 @@
   
   
   /**
  + * Socket buffering.
  + */
  +protected int socketBuffer = -1;
  +
  +
  +/**
* List of user agents to not use gzip with
*/
   protected String[] noCompressionUserAgents = null;
  @@ -534,6 +540,21 @@
   }
   
   /**
  + * Set the socket buffer flag.
  + */
  +public void setSocketBuffer(int socketBuffer) {
  +this.socketBuffer = socketBuffer;
  +outputBuffer.setSocketBuffer(socketBuffer);
  +}
  +
  +/**
  + * Get the socket buffer flag.
  + */
  +public int getSocketBuffer() {
  +return socketBuffer;
  +}
  +
  +/**
* Set the upload timeout.
*/
   public void setTimeout( int timeouts ) {
  @@ -767,6 +788,15 @@
   // Set error flag
   error = true;
   }
  +}
  +
  +} else if (actionCode == ActionCode.ACTION_CLIENT_FLUSH) {
  +
  +try {
  +outputBuffer.flush();
  +} catch (IOException e) {
  +// Set error flag
  +error = true;
   }
   
   } else if (actionCode == ActionCode.ACTION_CLOSE) {
  
  
  
  1.36  +6 -0  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java
  
  Index: Http11Protocol.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
  retrieving revision 1.35
  retrieving revision 1.36
  diff -u -r1.35 -r1.36
  --- Http11Protocol.java   2 Sep 2003 21:34:39 -   1.35
  +++ Http11Protocol.java   12 Sep 2003 13:15:36 -  1.36
  @@ -246,6 +246,7 @@
   private String reportedname;
   private int socketCloseDelay=-1;
   private boolean disableUploadTimeout = true;
  +private int socketBuffer = 1500;
   private Adapter adapter;
   private Http11ConnectionHandler cHandler;
   
  @@ -318,6 +319,10 @@
   disableUploadTimeout = isDisabled;
   }
   
  +public void setSocketBuffer(int valueI) {
  +socketBuffer = valueI;
  +}
  +
   public void setCompression(String valueS) {
   compression = valueS;
   }
  @@ -463,6 +468,7 @@
   processor.setTimeout( proto.timeout );
   processor.setDisableUploadTimeout( proto.disableUploadTimeout );
   processor.setCompression( proto.compression );
  +processor.setSocketBuffer( proto.socketBuffer );
   
   thData[Http11Protocol.THREAD_DATA_PROCESSOR]=processor;
   
  
  
  
  1.19  +87 -6 
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
  
  Index: InternalOutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- InternalOutputBuffer.java 11 Sep 2003 07:03:58 -  1.18
  +++ InternalOutputBuffer.java 12 Sep 2003 13:15:36 -  1.19
  @@ -77,7 +77,8 @@
   

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf ByteChunk.java

[remm]

remm2003/09/12 05:58:53

  Modified:util/java/org/apache/tomcat/util/buf ByteChunk.java
  Log:
  - Refactor byte chunk buffering so that the written data fits inside the limit.
The number of byte copies is similar to what it was before.
  
  Revision  ChangesPath
  1.15  +19 -28
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java
  
  Index: ByteChunk.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ByteChunk.java2 Sep 2003 21:34:38 -   1.14
  +++ ByteChunk.java12 Sep 2003 12:58:53 -  1.15
  @@ -338,34 +338,25 @@
   
// the buffer is already at ( or bigger than ) limit
   
  - // Optimization:
  - // If len-avail < length ( i.e. after we fill the buffer with
  - // what we can, the remaining will fit in the buffer ) we'll just
  - // copy the first part, flush, then copy the second part - 1 write
  - // and still have some space for more. We'll still have 2 writes, but
  - // we write more on the first.
  -
  - if( len + end < 2 * limit ) {
  - /* If the request length exceeds the size of the output buffer,
  -flush the output buffer and then write the data directly.
  -We can't avoid 2 writes, but we can write more on the second
  - */
  - int avail=limit-end;
  - System.arraycopy(src, off, buff, end, avail);
  - end += avail;
  -
  - flushBuffer();
  -
  - System.arraycopy(src, off+avail, buff, end, len - avail);
  - end+= len - avail;
  -
  - } else {// len > buf.length + avail
  - // long write - flush the buffer and write the rest
  - // directly from source
  - flushBuffer();
  - 
  - out.realWriteBytes( src, off, len );
  - }
  +// We chunk the data into slices fitting in the buffer limit, although
  +// if the data is written directly if it doesn't fit
  +
  +int avail=limit-end;
  +System.arraycopy(src, off, buff, end, avail);
  +end += avail;
  +
  +flushBuffer();
  +
  +int remain = len - avail;
  +
  +while (remain > (limit - end)) {
  +out.realWriteBytes( src, (off + len) - remain, limit - end );
  +remain = remain - (limit - end);
  +}
  +
  +System.arraycopy(src, (off + len) - remain, buff, end, remain);
  +end += remain;
  +
   }
   
   
  
  
  

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

[5.0.12] Delay

[Remy Maucherat]

I won't tag 5.0.12 until early next week, because:

- we're currently examining and testing fixes for bug 21763; two people 
have volunteered to test the recent changes, and confirm the problem is 
fixed

- I'm working on adding additional buffering features in Coyote HTTP; 
the change is not very extensive, so I hope there will not be any regression

A 4.1.28 release should also be made soon, incorporating the latest fixes.

Remy



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

DO NOT REPLY [Bug 19245] - pageEncoding in static included file don't affect properly file from which is included

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245

pageEncoding in static included file don't affect properly file from which is included





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 10:33 ---
Hi 
I don't want to fight "reopens against won't fix" ;) but - what about my
proposed patch from bug 19617? It makes Tomcat4 MORE specs compliant. Kim-Man
Chung said  that he has no objections to my patch. 

Please understand that now it's impossible to use encoding other than iso-8859-1
in included files - it's major flaw for all non-ascii programmers.

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 InternalOutputBuffer.java

[remm]

remm2003/09/12 03:28:38

  Modified:http11/src/java/org/apache/coyote/http11 Tag: coyote_10
InternalOutputBuffer.java
  Log:
  - Port patch: add filering for control chars in the HTTP header.
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.16.2.1  +9 -1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java
  
  Index: InternalOutputBuffer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/InternalOutputBuffer.java,v
  retrieving revision 1.16
  retrieving revision 1.16.2.1
  diff -u -r1.16 -r1.16.2.1
  --- InternalOutputBuffer.java 22 Nov 2002 15:55:32 -  1.16
  +++ InternalOutputBuffer.java 12 Sep 2003 10:28:38 -  1.16.2.1
  @@ -490,7 +490,7 @@
*/
   public void endHeaders() {
   
  -write(Constants.CRLF);
  +write(Constants.CRLF_BYTES);
   
   }
   
  @@ -627,6 +627,14 @@
   // High order byte must be zero
   //log("Header character is not iso8859_1, " +
   //"not supported yet: " + c, Log.ERROR ) ;
  +}
  +if (c != 9) {
  +if ((c >= 0) && (c <= 31)) {
  +c = ' ';
  +}
  +if (c == 127) {
  +c = ' ';
  +}
   }
   buf[pos++] = (byte) c;
   }
  
  
  

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

DO NOT REPLY [Bug 23131] - catalina crash.. it's still runing in process list but port not binded..

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131

catalina crash..  it's still runing in process list but port not binded..

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 10:28 ---
Please provide a test case.

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

DO NOT REPLY [Bug 23131] New: - catalina crash.. it's still runing in process list but port not binded..

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23131

catalina crash..  it's still runing in process list but port not binded..

   Summary: catalina crash..  it's still runing in process list but
port not binded..
   Product: Tomcat 5
   Version: 5.0.11
  Platform: PC
   URL: http://195.131.71.173
OS/Version: Windows XP
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


12.09.2003 12:54:49 org.apache.catalina.loader.WebappClassLoader modified
SEVERE: Resource '/WEB-INF/classes/gpnic/GetTovar.class' is missing
12.09.2003 12:54:49 org.apache.catalina.core.StandardContext reload
INFO: Reloading this Context has started
12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader 
findResourceInternal
INFO: Illegal access: this web application instance has been stopped already (the 
eventual following stack trace is caused by an error thrown for debugging purposes 
as well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact)
12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader 
findResourceInternal
INFO: Illegal access: this web application instance has been stopped already (the 
eventual following stack trace is caused by an error thrown for debugging purposes 
as well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact)
12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already (the 
eventual following stack trace is caused by an error thrown for debugging purposes 
as well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact)
12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already (the 
eventual following stack trace is caused by an error thrown for debugging purposes 
as well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact)
12.09.2003 12:54:54 org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already (the 
eventual following stack trace is caused by an error thrown for debugging purposes 
as well as to attempt to terminate the thread which caused the illegal access, and 
has no functional impact)
12.09.2003 12:54:54 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor 
processChildren
SEVERE: Exception invoking periodic operation: 
org.apache.commons.logging.LogConfigurationException: 
org.apache.commons.logging.LogConfigurationException: 
java.lang.IncompatibleClassChangeError: 
org.apache.commons.logging.impl.SimpleLog
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:532)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:272)
at org.apache.commons.logging.LogFactory.getLog
(LogFactory.java:414)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:3856)
at org.apache.catalina.core.StandardContext.reload
(StandardContext.java:2864)
at org.apache.catalina.core.StandardContext.backgroundProcess
(StandardContext.java:4411)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC
hildren(ContainerBase.java:1658)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC
hildren(ContainerBase.java:1667)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processC
hildren(ContainerBase.java:1667)
at 
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run
(ContainerBase.java:1647)
at java.lang.Thread.run(Thread.java:534)
Caused by: org.apache.commons.logging.LogConfigurationException: 
java.lang.IncompatibleClassChangeError: 
org.apache.commons.logging.impl.SimpleLog
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor
(LogFactoryImpl.java:416)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:525)
... 10 more
Caused by: java.lang.IncompatibleClassChangeError: 
org.apache.commons.logging.impl.SimpleLog
at org.apache.catalina.loader.WebappClassLoader.loadClass
(WebappClassLoader.java:1252)
at org.apache.catalina.loader.WebappClassLoader.loadClass
(WebappClassLoader.java:1212)
at org.apache.commons.logging.impl.LogFactory

DO NOT REPLY [Bug 23128] - ServletRequest.setLocale() sets encoding even when already set

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128

ServletRequest.setLocale() sets encoding even when already set





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 09:31 ---
I think that the second implementation mentioned in bug 6569 was the correct
one according to the spec, so you can just return back to it:

public void setLocale(Locale locale) {
[...]
this.locale = locale;
if ((this.encoding == null) && (this.context != null)) {
CharsetMapper mapper = context.getCharsetMapper();
this.encoding = mapper.getCharset(locale);
if ((contentType != null) && (contentType.indexOf(';') < 0)) {
contentType = contentType + ";charset=" + encoding;
}
}
}

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

DO NOT REPLY [Bug 23128] New: - ServletRequest.setLocale() sets encoding even when already set

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23128

ServletRequest.setLocale() sets encoding even when already set

   Summary: ServletRequest.setLocale() sets encoding even when
already set
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Calling ServletRequest.setLocale(locale) sets "charset" attribute
even if it was already specified. Following code shows it:

public void doGet (...) {
 PrintWriter out;
 response.setContentType("text/plain; charset=utf-8");
 out = response.getWriter();
 out.println( "getCharacterEncoding() = " + response.getCharacterEncoding() );
 response.setLocale(request.getLocale());
 out.println( "getCharacterEncoding() = " + response.getCharacterEncoding() );
}

It will produce output

getCharacterEncoding() = utf-8
getCharacterEncoding() = ISO-8859-2

for my browser with "cs" locale. This bug was probably introduced
by patch mentioned in bug 6569. To be precise, the Servlet 2.3 javadoc says
for ServletResponse.setLocale():

http://java.sun.com/webservices/docs/1.0/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)

 Sets the locale of the response, setting the headers (including the
 Content-Type's charset) as appropriate.

but the javadoc for Servlet 2.4 is more precise:

http://java.sun.com/webservices/docs/1.2/api/javax/servlet/ServletResponse.html#setLocale(java.util.Locale)

 Sets the locale of the response, setting the Content-Language header,
 if the response has not been committed yet. It also sets the response's
 character encoding appropriately for the locale, if the character
 encoding has not been explicitly set using
 setContentType(java.lang.String) or
 setCharacterEncoding(java.lang.String), getWriter hasn't been called
 yet, and the response hasn't been committed yet.

So Servlet 2.3 was vague in this, but Servlet 2.4 says it clearly, that
setLocale() should not change charset, if it is already set.
The last draft of Servlet 2.4 specification say in part 5.4 on page 52,
that "explicit specifications take precedence over implicit specifications".

This is a major problem when using JSTL fmt: tags for displaying internationalized
messages, because each fmt: tag calls the setLocale() to set Content-Language
header, and accidentaly changes also the charset. This makes impossible
to display internationalized pages with multilingual content using utf-8,
as the utf-8 charset is always replaced by setLocale() call of the last fmt:
tag.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Stefan Bodewig]

On Fri, 12 Sep 2003, Bill Barker <[EMAIL PROTECTED]> wrote:
> From: "Stefan Bodewig" <[EMAIL PROTECTED]>
>>
>> wouldn't it be better to put the "accepted = null" into a finally
>> block
> 
> Wouldn't do anything.  The 'accepted' variable is local to the
> stack-frame, so it goes away if I throw clear of the method.

OK, thanks.  I just looked at the commit mail as I suspect that one of
our customer production systems gets bitten by the bug - I didn't look
at the complete code.  Makes sense, then.

> I briefly thought about changing the catch to 'Throwable', but is it
> really possible for Socket.close to throw anything other than an
> Exception?

Everything is possible ;-)

I have no idea what the Socket implementation does if shutdown(2) sets
errno to ENOTCONN for example (I'd guess, throw a plain
SocketException).

I don't think that non-Exceptions are too likely to happen and if they
do it probably happens in a situation where you can't recover anyway
(OutOfMemory, StackOverflow, ThreadDeath ...).  Catching Throwable may
be the savest thing to do.

Stefan

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Remy Maucherat]

Bill Barker wrote:
On 12 Sep 2003, <[EMAIL PROTECTED]> wrote:


+++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
@@ -389,12 +389,12 @@
 if (accepted != null) {
 try {
 accepted.close();
-accepted = null;
 } catch(Exception ex) {
 msg = sm.getString("endpoint.err.nonfatal",
accepted, ex);
 log.warn(msg, ex);
 }
+accepted = null;
 }
 if( ! running ) return null;
wouldn't it be better to put the "accepted = null" into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?
Wouldn't do anything.  The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method.  In this case you just get a
DoS condition where no threads are listening on the ServerSocket.  I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?
I don't know. From traces I saw, there are conditions where there could 
be no thread listening on the socket (at that point, the connector was 
dead, of course), while everything else in the TP was looking ok 
(including no deadlock). There didn't seem to be anything in the logs 
related to an error during accept.

I'd catch throwable just to be safe, personally :)

Remy



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

DO NOT REPLY [Bug 21763] - Tomcat 4.1.24 hangs under heavy load using http connector.

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763

Tomcat 4.1.24 hangs under heavy load using http connector.





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 08:35 ---
Created an attachment (id=8182)
Binary including the fix

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Bill Barker]

- Original Message - 
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 12, 2003 12:58 AM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
PoolTcpEndpoint.java


> On 12 Sep 2003, <[EMAIL PROTECTED]> wrote:
>
> >  +++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 - 1.16
> >  @@ -389,12 +389,12 @@
> >   if (accepted != null) {
> >   try {
> >   accepted.close();
> >  -accepted = null;
> >   } catch(Exception ex) {
> >   msg = sm.getString("endpoint.err.nonfatal",
> >  accepted, ex);
> >   log.warn(msg, ex);
> >   }
> >  +accepted = null;
> >   }
> >
> >   if( ! running ) return null;
>
> wouldn't it be better to put the "accepted = null" into a finally
> block so you clean up even in the (unlikely but possible) case where
> close throws an Error (or Throwable) instead of an Exception?
>

Wouldn't do anything.  The 'accepted' variable is local to the stack-frame,
so it goes away if I throw clear of the method.  In this case you just get a
DoS condition where no threads are listening on the ServerSocket.  I briefly
thought about changing the catch to 'Throwable', but is it really possible
for Socket.close to throw anything other than an Exception?


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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[Stefan Bodewig]

On 12 Sep 2003, <[EMAIL PROTECTED]> wrote:

>  +++ PoolTcpEndpoint.java 12 Sep 2003 03:51:36 -  1.16
>  @@ -389,12 +389,12 @@
>   if (accepted != null) {
>   try {
>   accepted.close();
>  -accepted = null;
>   } catch(Exception ex) {
>   msg = sm.getString("endpoint.err.nonfatal",
>  accepted, ex);
>   log.warn(msg, ex);
>   }
>  +accepted = null;
>   }
>   
>   if( ! running ) return null;

wouldn't it be better to put the "accepted = null" into a finally
block so you clean up even in the (unlikely but possible) case where
close throws an Error (or Throwable) instead of an Exception?

Stefan

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

REMOVE MY EMAIL !!!

[webmaster]

Calvin
CoiThienThai.Com's Webmaster
*
  Coi Thien Thai Entertainment Network
 http://www.coithienthai.com
   E-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
 [EMAIL PROTECTED]
*
- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 12, 2003 1:57 AM
Subject: DO NOT REPLY [Bug 23105] - JkMount overrides Alias


> 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105
>
> JkMount overrides Alias
>
>
>
>
>
> --- Additional Comments From [EMAIL PROTECTED]  2003-09-12
07:57 ---
> Did you tried with latest JK release (HEAD or to be released 1.2.5) ?
>
> -
> 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 23105] - JkMount overrides Alias

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23105

JkMount overrides Alias





--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 07:57 ---
Did you tried with latest JK release (HEAD or to be released 1.2.5) ?

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

DO NOT REPLY [Bug 19245] - pageEncoding in static included file don't affect properly file from which is included

[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://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245

pageEncoding in static included file don't affect properly file from which is included

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-09-12 07:11 ---
You are 100% wrong. The pageEncoding is specified to default to the content-
type encoding, which defaults to iso-latin-1.

Please do me the courtesy of actually reading the JSP spec before wasting my 
time expounding your wild theories.

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