TC as web server

2003-09-10 Thread Jerald Powel
Hello, I am trying to differentiate Apache and Apache Tomcat in terms of the serving mechanism, and subsequent log files. Of course, Apache is a web server, and Tomcat a servlet container, but Tomcat also is a/has a web server? If Tomcat contains a web server as a seperate entity, where can (if at all) the Apache httpd.conf file be found to configure such things as the log files produced?  This post relates to efforts to run Analog on multiple Tomcat log files (which it cannot currently recognize). Thanks for all input Jerald.Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger---BeginMessage---
Hello,
I am trying to differentiate Apache and Apache Tomcat in terms of the serving 
mechanism, and subsequent log files. Of course, Apache is a web server, and Tomcat a 
servlet container, but Tomcat also is a/has a web server? If Tomcat contains a web 
server as a seperate entity, where can (if at all) the Apache httpd.conf file be found 
to configure such things as the log files produced? 
   This post relates to efforts to run Analog on multiple Tomcat log files 
(which it cannot currently recognize).
 
Thanks for all input
 
Jerald.




-
Want to chat instantly with your online friends? Get the FREE Yahoo!Messenger---End Message---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

No such list! -Unsubscribe:

2003-09-10 Thread -Unsubscribe:
Valid Lists


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



No such list! -Post:

2003-09-10 Thread -Post:
Valid Lists


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



No such list! -Id:

2003-09-10 Thread -Id:
Valid Lists


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



AW: AW: AW: [5.0] JSP performance ...

2003-09-10 Thread Torsten Fohrer
next try


-Ursprüngliche Nachricht-
Von: Torsten Fohrer [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 9. September 2003 13:55
An: 'Tomcat Developers List'
Betreff: AW: AW: AW: [5.0] JSP performance ...



patched a snapshot to merge template text nodes.

I implement following using a additional visitor in Generator.java
 - char[] arrays for templatetexts
 - same templatetexts - only 1 char array for text, better without merging

good/bad gimmicks: 
  - removing empty templatetexts, example: only \r\n, , null and so
  - removing \r\n after scripting elements

One effect, i see is a lower memory usage from jasper pages 

cu Torsten Fohrer

-Ursprüngliche Nachricht-
Von: Remy Maucherat [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 9. September 2003 11:31
An: Tomcat Developers List
Betreff: Re: AW: AW: [5.0] JSP performance ...


Torsten Fohrer wrote:

 what's about char[] array/string reusing?
 Create only a char array for each unique templatetext node. 
 
 - 
   10 x char[] jspx_text_1 = something\n;
   1  x char[] jspx_text_1 = something\n;

Won't the VM do that internally ?
Since apparently you have examined that issue in detail already, maybe 
you can give more details :)

- What exactly did you implement ?
- What's the code it generates ? Does it also merge the TemplateText nodes ?
- Did it improve performance ? For example, if you try to run the test I 
gave, what kind of performance increase do you see ?

Remy



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




package org.apache.jsp;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import java.util.*;

public final class h2000_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {

  private char[] _jspx_textLine_1 = htmlheadtitle.toCharArray();
  private char[] _jspx_textLine_2 = /title.toCharArray();
  private char[] _jspx_textLine_3 = /title/headbody\r\n.toCharArray();
  private char[] _jspx_textLine_4 = table\r\n .toCharArray();
  private char[] _jspx_textLine_5 = tr bgcolor=\.toCharArray();
  private char[] _jspx_textLine_6 = \\r\n   .toCharArray();
  private char[] _jspx_textLine_7 = td align=\center\font 
size=\+1\.toCharArray();
  private char[] _jspx_textLine_8 = /font.toCharArray();
  private char[] _jspx_textLine_9 = /font/td\r\n   .toCharArray();
  private char[] _jspx_textLine_10 = /tr\r\n .toCharArray();
  private char[] _jspx_textLine_11 = /table\r\n.toCharArray();
  private char[] _jspx_textLine_12 =  Hello World Hello World Hello World Hello World 
Hello World Hello World Hello World Hello World Hello World Hello World 
.toCharArray();
  private char[] _jspx_textLine_13 =  Hello World Hello World Hello World Hello World 
Hello World Hello World Hello World Hello World Hello World Hello World br/\r\n  
.toCharArray();
  private char[] _jspx_textLine_14 = /body/html\r\n.toCharArray();

  private static java.util.List _jspx_dependants;

  public java.util.List getDependants() {
return _jspx_dependants;
  }

  public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {

JspFactory _jspxFactory = null;
PageContext pageContext = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter out = null;
Object page = this;
JspWriter _jspx_out = null;


try {
  _jspxFactory = JspFactory.getDefaultFactory();
  response.setContentType(text/html);
  pageContext = _jspxFactory.getPageContext(this, request, response,
null, false, 8192, true);
  application = pageContext.getServletContext();
  config = pageContext.getServletConfig();
  out = pageContext.getOut();
  _jspx_out = out;

  out.write( _jspx_textLine_1 );
  out.write(String.valueOf( request.getParameter(title) ));
  out.write( _jspx_textLine_3 );
 
// build tight loop table with array data, multidimensional 5x6
String array[] = { Hello, World, 2000, Hello, World, 2000 };
Arrays.sort(array);
String multi[][] = { array, array, array, array, array };

  out.write( _jspx_textLine_4 );
 for(int row=0; row  multi.length; row++) { 
  out.write( _jspx_textLine_5 );
  out.write(String.valueOf( (row % 2) == 1 ? gray : white ));
  out.write( _jspx_textLine_6 );
 for(int col=0; col  array.length; col++) { 
  out.write( _jspx_textLine_7 );
  out.write(String.valueOf( multi[row][col] ));
  out.write( _jspx_textLine_9 );
 } 
  out.write( _jspx_textLine_10 );
 } 
  out.write( _jspx_textLine_11 );
 
String dummy = request.getParameter(integer);
int param = 2000; //Integer.parseInt(dummy);
for (int i=1; i=10; i++) {
  int var = i+param;
  
  out.write(String.valueOf(var));
  out.write( _jspx_textLine_13 );
  out.write(String.valueOf(var));
  

o.a.c.authenticator.NonLoginAuthenticator.java

2003-09-10 Thread Tim Funk
Has anyone used NonLoginAuthenticator? Or know if it is still ok?
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/NonLoginAuthenticator.java?rev=1.3content-type=text/vnd.viewcvs-markup
From a quick code walkthrough it looks like an authenticator for use when 
apache propogates the REMOTE_USER. So the only job of the realm is to map 
Users to roles? (With no authentication)

So the only deviation from the spec is that all login configuration such as 
FORM, BASIC, ... is ignored. But all role authorization as defined in web.xml 
and configured in one's Realm is still used.

Does this sound correct?

-Tim



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


Re: Classloader when Tomcat is embedded + save

2003-09-10 Thread Florent BENOIT
   Hi again,

Remy Maucherat wrote:
 Well, I think in the complex cases, you should probably use 
StandardContext.setCompilerClasspath. I'm willing to remove that check, 
though.
 Of course, it's good to remember that this code exists only because 
of the lack of a good in memory compiler. This could change.

Yes, I could use setCompilerClasspath() method, but, in order to 
retrieve the classpath (to give to setCompilerClasspath()), I have to 
use a similar method than setClassPath() of the class WebappLoader. So 
the code is duplicated only for changing the number of layer. So it 
would be great if the 3 is going to be removed.

If this value (3) is not removed, it could become a parameter like for 
setCompilerClasspath() on StandardContext.
StandardContext.setCompilerClassPathLayers(int layers). If it's null, it 
uses 3, else it uses the number which is set.
So, this value can be adjusted by the application server in different cases.
In ear case, this number will be greater than in a standalone war file 
as the number of classloader is increased.

But, it will result in the same case that if this 3 parameter is 
definitively removed because it will stop at the last URLClassloader found.

For the saving feature :
 That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
 Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for your 
patch :)

There is no problem for doing a contribution. But maybe I have to use 
the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe 
a removeSkippable(String)) and by adding the isSkippable() mechanism in 
the storeContext like for storeListener()
I think that addSkippable(String classname) is better than 
setSkippables(string skippables) as we don't have to know the existing 
skippables.
These methods will not be called in standalone mode but can be useful in 
the embedded mode.
If you agree with this, I can propose a patch for the current catalina 
5.x cvs.

Regards,

Florent

Remy Maucherat wrote:

Florent BENOIT wrote:

   Hello,

When we embed Tomcat in an application server, we have the following 
problem that we must patch.
It would be good if in the Tomcat 5.x branch, this will be fixed.

The problem :

It's about the setClassPath() method of the class WebappLoader of the 
package org.apache.catalina.loader.

This is the following code :

   int layers = 0;
   int n = 0;
   while ((layers  3)  (loader != null)) {
So, the classpath is set to 3 level.
When JOnAS is embedded, several URL Classloader can be parent 
classloader and not set to 3 levels.
So, for example if we have an application server classloader, ear 
classloader, ejb classloader, web classloader, etc.
The final classpath has some missing jars which can be found on a 
layer  = 3.
So, please, if you can :
- remove this test on this value (only testing (loader != null) and 
we stop when it's not anymore an URLClassLoader
- or that we can configure this value by a system property or 
anything else.
It will make a better integration of the Tomcat product, without 
having to set the right classpath with the same method but without 
the number 3.


Well, I think in the complex cases, you should probably use 
StandardContext.setCompilerClasspath. I'm willing to remove that 
check, though.
Of course, it's good to remember that this code exists only because of 
the lack of a good in memory compiler. This could change.

Another request is if the save action to the server.xml file could 
not saved some configurable parameters.
For example, in a j2ee application server, some contexts are created 
at the runtime, but we don't want that these contexts will be stored 
on the server.xml as their path are sometimes dynamic, temporary, etc.
So if we could add/remove/configure the actions of the save() method, 
it would be great for a better integration.


That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for 
your patch :)

Remy



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


Problem with pageEncoding directive on dynamic include

2003-09-10 Thread Nair, Anand
Hello All,

With Tomcat 4 server on my dynamic includes pageEncoding directive does not seem to be 
working.

a.jsp  has jsp:include page=/include/b.jsp flush=true /

b.jsp contains:

[EMAIL PROTECTED] pageEncoding=UTF-8%
Other CONTENTS


pageEncoding does work on any static includes though. Any body know what I am doing 
wrong here?

Thanks
Anand


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

2003-09-10 Thread remm
remm2003/09/10 08:40:27

  Modified:catalina/src/share/org/apache/catalina/loader
WebappLoader.java
  Log:
  - Remove the artificial limit of 3 for classpath creation. It seems like a bad idea
to do this (if the parent CLs are not correctly setup, Tomcat won't work anyway).
  
  Revision  ChangesPath
  1.21  +2 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java
  
  Index: WebappLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappLoader.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- WebappLoader.java 2 Sep 2003 21:22:03 -   1.20
  +++ WebappLoader.java 10 Sep 2003 15:40:27 -  1.21
  @@ -1154,7 +1154,7 @@
   ClassLoader loader = getClassLoader();
   int layers = 0;
   int n = 0;
  -while ((layers  3)  (loader != null)) {
  +while (loader != null) {
   if (!(loader instanceof URLClassLoader)) {
   String cp=getClasspath( loader );
   if( cp==null ) {
  
  
  

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



Re: Classloader when Tomcat is embedded + save

2003-09-10 Thread Remy Maucherat
Florent BENOIT wrote:

For the saving feature :
  That feature is thought out for standalone mode. It's hard to predict 
what are the components which should be saved, and which should not.
  Now if you want to refactor the save-to-xml code to a separate class 
(and allow configuring that class, of course), then I'm waiting for your 
patch :)

There is no problem for doing a contribution. But maybe I have to use 
the skippable mechanism already defined in StandardServer.
So, by adding a public method addSkippable(String classname) (and maybe 
a removeSkippable(String)) and by adding the isSkippable() mechanism in 
the storeContext like for storeListener()
I think that addSkippable(String classname) is better than 
setSkippables(string skippables) as we don't have to know the existing 
skippables.
These methods will not be called in standalone mode but can be useful in 
the embedded mode.
If you agree with this, I can propose a patch for the current catalina 
5.x cvs.
The implementation of the feature had little to do with the 
StandardServer class itself. It should really be a separate helper class 
(no more hacks, sorry ;-) ).

Remy



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


DO NOT REPLY [Bug 23071] New: - Documentation error handling re use of JRE

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23071.
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=23071

Documentation  error handling re use of JRE

   Summary: Documentation  error handling re use of JRE
   Product: Tomcat 4
   Version: 4.1.27
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Although the documentation does state that Tomcat needs a full JDK, rather than 
just a JRE, on no less than two occasions, a year apart, I have fallen in to 
the trap of thinking that all I need to install is the JRE. (No Java 
development would be carried out on the machines to which I was installing 
Tomcat.)

When the startup.bat file is executed in such cases, the error handling is 
misleading; an error message states that JAVA_HOME has not been set correctly. 
In fact, JAVA_HOME is quite correct - the problem is that JRE's do not contain 
tools such as javac.exe.

I strongly suggest that semi-conscious ;-) users are protected from this 
pitfall by the addition to the documentation of a prominent but brief 
explanation of why a JRE is insufficient to run Tomcat.

An additional suggestion, in the perhaps unlikely event that you have time to 
hand, would be to correct the error handling.

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



Re: AW: AW: AW: [5.0] JSP performance ...

2003-09-10 Thread Remy Maucherat
Torsten Fohrer wrote:

next try
Yes, the code is better (IMO) and performs a little better also.
However, looking more at my profiler, I think the problem with that 
benchmark is all the not optimized int - String conversions. Since 
that's not too useful in the real world (but in that benchmark, it seems 
extremely important), it is not worth optimizing it right now.

BTW, for these, Resin generated out.print((var)), assuming the type of 
the expression would be correct. I think we went through that and 
decided not to do that, right ?

I think we would need to define a decent servletJSP bench suite :) (and 
avoid to rig it)

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/security SecurityUtil.java

2003-09-10 Thread jfarcand
jfarcand2003/09/10 09:56:45

  Modified:catalina/src/share/org/apache/catalina/security
SecurityUtil.java
  Log:
  Always associate a Subject. If not created, then create a default one.
  
  Revision  ChangesPath
  1.7   +5 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java
  
  Index: SecurityUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- SecurityUtil.java 2 Sep 2003 21:22:06 -   1.6
  +++ SecurityUtil.java 10 Sep 2003 16:56:45 -  1.7
  @@ -292,6 +292,11 @@
   (HttpServletRequest)targetArguments[0];
   subject = (Subject)request.getSession()
   .getAttribute(Globals.SUBJECT_ATTR);
  +
  +if (subject == null){
  +subject = new Subject();
  +request.getSession().setAttribute(Globals.SUBJECT_ATTR, 
subject);
  +}
   }
   
   Subject.doAsPrivileged(subject, pea, null);   
  
  
  

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



DO NOT REPLY [Bug 23074] New: - all ControlRunnables are waiting at the same instance of ThreadPool

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23074.
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=23074

all ControlRunnables are waiting at the same instance of ThreadPool

   Summary: all ControlRunnables are waiting at the same instance of
ThreadPool
   Product: Tomcat 4
   Version: 4.1.18
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Sep 9, 2003 9:57:15 PM org.apache.tomcat.util.log.CommonLogHandler log
INFO: All threads are busy, waiting. Please increase maxThreads or check the 
servlet status75 75


Full thread dump Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode):

Thread-77 daemon prio=1 tid=0x081ebe68 nid=0x5805 in Object.wait() 
[50118000..501188b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-76 daemon prio=1 tid=0x081eb1a0 nid=0x5804 in Object.wait() 
[50097000..500978b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-75 daemon prio=1 tid=0x081eae18 nid=0x5803 in Object.wait() 
[50016000..500168b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-74 daemon prio=1 tid=0x4cf4a280 nid=0x5802 in Object.wait() 
[4ff95000..4ff958b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-73 daemon prio=1 tid=0x4cf49780 nid=0x5801 in Object.wait() 
[4ff14000..4ff148b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-72 daemon prio=1 tid=0x4cf48c80 nid=0x5800 in Object.wait() 
[4fe93000..4fe938b8]
at java.lang.Object.wait(Native Method)
- waiting on 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at java.lang.Object.wait(Object.java:429)
at org.apache.tomcat.util.threads.ThreadPool.runIt(ThreadPool.java:232)
- locked 0x44dd4f28 (a org.apache.tomcat.util.threads.ThreadPool)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt
(PoolTcpEndpoint.java:503)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:534)

Thread-71 daemon prio=1 tid=0x4cf48998 nid=0x57ff in 

Previous vote on Tomcat 5.0.11

2003-09-10 Thread Richard Norman
Previously in a mention of a vote for Tomcat 5.0.11 as being Beta or Alpha 
status, I vote beta.

I have not done major extensive testing, but in everything I hav run so far 
nothing has had a major hickup. The major issue I saw immediately, was the 
config of the appBase and docBase attributes in server.xml on windows.  I am 
still do ing more tests and checking, but it looks good so far.

Besides if 5.09 was beta, I think the fixes make this along the same lines.

Thanks,

Richard Norman
Web/Application Developer
_
Use custom emotions -- try MSN Messenger 6.0! 
http://www.msnmessenger-download.com/tracking/reach_emoticon

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


Re: AW: AW: AW: [5.0] JSP performance ...

2003-09-10 Thread Kin-Man Chung

 Date: Wed, 10 Sep 2003 18:34:40 +0200
 From: Remy Maucherat [EMAIL PROTECTED]
 Subject: Re: AW: AW: AW: [5.0] JSP performance ...
 To: Tomcat Developers List [EMAIL PROTECTED]
 
 Torsten Fohrer wrote:
 
  next try
 
 Yes, the code is better (IMO) and performs a little better also.
 However, looking more at my profiler, I think the problem with that 
 benchmark is all the not optimized int - String conversions. Since 
 that's not too useful in the real world (but in that benchmark, it seems 
 extremely important), it is not worth optimizing it right now.
 
 BTW, for these, Resin generated out.print((var)), assuming the type of 
 the expression would be correct. I think we went through that and 
 decided not to do that, right ?
 

We did?

I think we should also use out.print(var) instead of
out.write(String.valueOf(var)).  The print methods cover all the types
covered by String.valueOf, so there is really no advantage in using
out.write's.  Using print lets javac resolves the object types at
compile time instead of runtime, and should be faster.

If there is no objections, I'll go ahead and make the change.

- Kin-man

 I think we would need to define a decent servletJSP bench suite :) (and 
 avoid to rig it)
 
 Remy
 
 
 
 -
 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 23074] - all ControlRunnables are waiting at the same instance of ThreadPool

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23074.
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=23074

all ControlRunnables are waiting at the same instance of ThreadPool

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 17:54 ---


*** This bug has been marked as a duplicate of 21763 ***

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 17:54 ---
*** Bug 23074 has been marked as a duplicate of this bug. ***

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



Re: Previous vote on Tomcat 5.0.11

2003-09-10 Thread Remy Maucherat
Richard Norman wrote:
Previously in a mention of a vote for Tomcat 5.0.11 as being Beta or 
Alpha status, I vote beta.

I have not done major extensive testing, but in everything I hav run so 
far nothing has had a major hickup. The major issue I saw immediately, 
was the config of the appBase and docBase attributes in server.xml on 
windows.  I am still do ing more tests and checking, but it looks good 
so far.

Besides if 5.09 was beta, I think the fixes make this along the same lines.
Apparently, there was a regression when the security manager is used, 
because of the move of the commons-logging binary. I'll have to investigate.
If I can reproduce it, I'll release a 5.0.12 with a few more fixes.

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.

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 18:01 ---
Once the pool gets busy, it's normal for the threads to wait here. However, I
have the impression that there's a bug which may happen as soon as the pool gets
full.
Can you reproduce this with 5.0.11 ?

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



Re: [VOTE] 5.0.11 stability rating

2003-09-10 Thread Jean-Francois Arcand
Seems my apache/sun email are blocked when I reply. :-(


Remy Maucherat wrote:

 ballot
 [X] Alpha
 [ ] Beta
 /ballot 


When turning the security manager on:

 java.security.AccessControlException: access denied (java.io.FilePermission 
 /home/ja120114/src/jakarta-tomcat-5/build/server/webapps/manager/WEB-INF/classes/org/apache/log4j/Logger.class
  read)
 at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
 at java.security.AccessController.checkPermission(AccessController.java:401)

Always do catalina run -security

-- Jeanfrancois






 pleaAs usual, please vote :)/plea

 Add comments if needed.

 5.0.11 is similar to 5.0.10 (with the exception of the commons-logging integration). 
 Please check it for regressions.

 Remy


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





__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

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



DO NOT REPLY [Bug 23077] New: - Error During Startup

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23077.
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=23077

Error During Startup

   Summary: Error During Startup
   Product: Tomcat 5
   Version: 5.0.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I cannot start TC 5.0.9 as a service.

I recieve the message:

Cannot start Apache tomcat service in local machine.

Error 1053: Tehe service has not responded to the petition or started the 
control in adecuate time.

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



DO NOT REPLY [Bug 23077] - Error During Startup

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23077.
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=23077

Error During Startup

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 18:35 ---
This works for me. You likely have an incorrect JDK setup. Please do not reopen
the report.

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



DO NOT REPLY [Bug 23077] - Error During Startup

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23077.
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=23077

Error During Startup





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 19:03 ---
If I have an incorrect JDK setup. Why does it work when I run the startup.bat?

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



Re: [VOTE] 5.0.11 stability rating

2003-09-10 Thread Remy Maucherat
Jean-Francois Arcand wrote:
ballot
[X] Alpha
[ ] Beta
/ballot 
When turning the security manager on:

java.security.AccessControlException: access denied (java.io.FilePermission 
/home/ja120114/src/jakarta-tomcat-5/build/server/webapps/manager/WEB-INF/classes/org/apache/log4j/Logger.class
 read)
   at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
   at java.security.AccessController.checkPermission(AccessController.java:401)
Always do catalina run -security
Given the trivial fix (and the fact that only advanced users would use 
the security manager), I think it should be ok to upload the updated 
policy file next to the downloads, and consider this good enough.

Remy



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


DO NOT REPLY [Bug 23077] - Error During Startup

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23077.
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=23077

Error During Startup





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 19:07 ---
You probably didn't specify the right JDK directory when you ran the installer.

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 19:21 ---
This is due to a defect of design of thread pool in Tomcat 4.1.x. (I have yet 
read sources of 5.x)

An instance of ControlRunnable could wait at two locations. One is in its run() 
method, the another is in ThreadPool's runIt() method via TcpWorkerThread.runIt
(). This causes deadlock.

When a ControlRunnable is waiting at ThreadPool.runIt() via other classes such 
as TcpWorkerThread.runIt() - endpoint.tp.runIt(this). The only chance it gets 
notified is another ControlRunnable to end and to call 
ThreadPool.returnController().

At a moment the server is under a very heavy traffic, all ControlRunnable will 
be hung at ThreadPool.runIt() - this.wait().


I have a solution for this is to use a queue of ThreadPoolRunnable to hold all 
requests. This way, a ControlRunnable no longer need to wait outside.

Thanks,
Rex

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 20:10 ---
Can you suggest a patch ?

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 20:14 ---
Close, but not quite correct.  If it is waiting in ControlRunnable.run, then 
it is available for requests, so no deadlock is possible.  

The actual problem is with the way it waits for a free ControlRunnable.  At 
the moment, it doesn't notice that it has a free slot if one of the threads 
dies after the pool becomes empty.  It's an easy enough fix however.

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 20:21 ---
Isn't the problem that returnController sync on this (like the code which waits
in findControlRunnable) ?

I'm also investigating a case in parallel where no thread is waiting on accept
on the server socket, for some unknown reason (it could be that the server
socket died - which is likely a non recoverable error -, but the reporter was
unable to find that in his logs, so it could be a TP bug).

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 20:44 ---
The accept bug should be the same as this one I'm guessing.  That's what you'd 
see soon after you got into the state in 23074.

The sync in findControlRunnable can't really interfer with returnController, 
since it doesn't really spend any time there unless it decides to wait (at 
which point, it no longer owns the Monitor).

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



Re: cvs commit: jakarta-tomcat-5 build.properties.default

2003-09-10 Thread NormW
Good morning... looks like another beautiful day here!
Unfortunately it isn't off to a good start somehow your most recent
e-mail got picked up in the lot to be deleted... sigh... could you send a
copy of your last one, with a subject of 'rainy Wednesday...' please? I quit
the tomcat-user list ages ago, and after only one day, there were still more
than 80 and so many SPAM, I guess in my 'excitement' I must have pressed
delete once too many times, since of them all, yours was the only one from a
person actually addressed to me, that I did want to read...;-(

Yesterday's outing was tiring but didn't find much of interest... did buy a
film and might finish off the roll with a 'view' from my window, just so
that we are even...

Hope all goes well,
For the minute,
Norm

- Original Message - 
From: Bill Barker [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 3:59 PM
Subject: Re: cvs commit: jakarta-tomcat-5 build.properties.default



 [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]
  remm2003/09/08 02:31:38
 
Modified:.build.properties.default
Log:
- New PureTLS version.
- I'll be including PureTLS support in 5.0.11+.
 

 While I'm +1, this may cause problems since at the moment Tomcat will
select
 PureTLS by default if it is found (on the grounds that you've had to
 download and install it, so you must want it :).  If PureTLS ships with,
 then there needs to be a big bold instruction in the ssl_howto to select
 JSSE.




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



Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Steve Appling
Chunked encoding with the coyote http1.1 connector seems to be very
inefficient.  I have 3 major comments about it which I will summarize, then
explain in more detail for those interested.



1) There are some performance problems with the current implementation of
chunked encoding.



2) I would like to be able to turn off chunked encoding completely, but this
does not appear to be an option.



3) Chunked encoding should probably only be used when returning content of
indeterminate length.  Static files served up by the default servlet should
perhaps not be chunked.



--

1 - Performance problems

I did some informal testing over a fast LAN.  My server is configured with
compression enabled, so I am getting responses with Transfer-Encoding:
chunked, and Content-Encoding: gzip from Tomcat.  I was using IE 6 as a
client.



A request to retrieve a static html page from Tomcat with the 4.1.27 coyote
connector results in the following:



- (From Server to Client)

- HTTP/1.1 200 OK (No Data)

- HTTP Continuation (3 Bytes of data - chunk header size=0xa)

- TCP Acknowledgement

- HTTP Continuation (10 bytes of data - GZIP Header)

- Empty packet with no HTTP header or data (just \r\n)

- TCP Acknowledgement



Repeat the following 7 times (TCP ack every two packets)

- HTTP Continuation (5 Bytes of data - chunk header size=0x200)

- HTTP Continuation (512 Bytes of data *see below)

- TCP Acknowledgement

- Empty packet with no HTTP header or data (just \r\n)



...



- HTTP Continuation (5 Bytes of data - chunk header size=0x18d)

- TCP Acknowledgement

- HTTP Continuation (397 Bytes of data)

- Empty packet with no HTTP header or data (just \r\n)

- TCP Acknowledgement

- HTTP Continuation (5 Bytes of data - chunk header size=0)



This took a total of 43 packets and 9.2 mSec to complete.



* The 512 byte limit for the largest packets seems to be because the Gzip
filter uses the default constructor for the GZIPOutputStream (with a default
output buffer size of 512 bytes).





I tried the same test with Apache 2.0.44 using mod-gzip.  Apache does not
chunk the static HTML files.  I got:

- HTTP/1.1 200 OK (972 bytes of data)

- HTTP Continuation (1331 Bytes of data)

- TCP Acknowledgement

- HTTP Continuation (1332 Bytes of data)

- HTTP Continuation (666 Bytes of data)



This took a total of 5 packets and 7 mSec to complete.



These informal tests were conducted over a fast LAN connection.  I'm
particularly concerned about the total number of packets used. Over





--

2 - Turning off Chunking

The older HTTP1.1 connector had an allowChunking attribute that allowed you
to turn chunking off completely.  I can't find a way to do this with the
coyote connector.  My investigation into all of this started because I am
investigating an IE bug that causes it to use many connections without
closing them with gzipped chunked responses.  I think I need to be able to
just disable chunking and felt that this should be a feature of the coyote
connector.



---

3 - When to chunk

I thought that chunking was invented to handle serving up dynamically
created content that did not have a size known in advance.  I believe that
on both IIS and Apache static content is not chunked.  Is there any way for
tomcat to behave similarly - could the default servlet do something to
prevent the connector from chunking the data it serves up?





If you made it this far, thanks for taking the time to read this and
consider my questions.












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



cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityUtil.java

2003-09-10 Thread jfarcand
jfarcand2003/09/10 14:28:37

  Modified:catalina/src/share/org/apache/catalina/security
SecurityUtil.java
  Log:
  Do not create session when no one is available.
  
  Revision  ChangesPath
  1.8   +9 -5  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java
  
  Index: SecurityUtil.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityUtil.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- SecurityUtil.java 10 Sep 2003 16:56:45 -  1.7
  +++ SecurityUtil.java 10 Sep 2003 21:28:37 -  1.8
  @@ -73,6 +73,7 @@
   import javax.servlet.ServletException;
   import javax.servlet.UnavailableException;
   import javax.servlet.http.HttpServletRequest;
  +import javax.servlet.http.HttpSession;
   
   import org.apache.catalina.Globals;
   import org.apache.catalina.util.StringManager;
  @@ -290,12 +291,15 @@
targetArguments[0] instanceof HttpServletRequest){
   HttpServletRequest request = 
   (HttpServletRequest)targetArguments[0];
  -subject = (Subject)request.getSession()
  -.getAttribute(Globals.SUBJECT_ATTR);
   
  -if (subject == null){
  -subject = new Subject();
  -request.getSession().setAttribute(Globals.SUBJECT_ATTR, 
subject);
  +HttpSession session = request.getSession(false);
  +if (session != null){
  +subject = (Subject)session.getAttribute(Globals.SUBJECT_ATTR);
  +
  +if (subject == null){
  +subject = new Subject();
  +session.setAttribute(Globals.SUBJECT_ATTR, subject);
  +}
   }
   }
   
  
  
  

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



DO NOT REPLY [Bug 23088] New: - Manager App when used to remove or reload a webapp do not stop the threads running inside the web app.

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23088.
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=23088

Manager App when used to remove or reload a webapp do not stop the threads running 
inside the web app.

   Summary: Manager App when used to remove or reload a webapp do
not stop the threads running inside the web app.
   Product: Tomcat 4
   Version: 4.0 Beta 1
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I dont know if this is a bug or not but just thought of mentioning this to you 
guys.

The following is the approach to replicate this.

1. Create a new Web Application whose Context Listener class calls a class that 
extends Thread and call that object.start().

2. Now from manager if you stop the web application the web app is stopped from 
running apps but the Thread that is started will be running continuously when 
there is an infinite loop in the run method of the Thread class.

3. I think from ClassLoader we an get hold of the ThreadGroup and then we can 
stop all the threads associated with the ThreadGroup when stopping the web app.

I may be wrong but if you think this is an Issue you can enter else just leave 
it.

Please let me know if you need anything.

Thanks and Regards,

Vijaya K Mantha.

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



Re: Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Remy Maucherat
Steve Appling wrote:
Chunked encoding with the coyote http1.1 connector seems to be very
inefficient.  I have 3 major comments about it which I will summarize, then
explain in more detail for those interested.
1) There are some performance problems with the current implementation of
chunked encoding.
2) I would like to be able to turn off chunked encoding completely, but this
does not appear to be an option.
3) Chunked encoding should probably only be used when returning content of
indeterminate length.  Static files served up by the default servlet should
perhaps not be chunked.
Look, there's no reason to start whining. Adding a lower level buffering 
(using a ByteChunk maybe) is nearly trivial, and since you seem to know 
what you're doing, you could have done in less than the amount it took 
you to write your email.
I'm not convinced it's the best solution all the time (Coyote leverages 
the buffering mandated by the higher level - the servlet API - to avoid 
useless copying from buffer to buffer).

-1 for option 2 (I consider keepalive is more important than anything else).

Remy



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


DO NOT REPLY [Bug 15672] - DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15672.
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=15672

DBCP doesn't work on Tomcat 4.1.18 with Oracle JDBC driver





--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 22:21 ---
I too am having problems with setting up a JNDI connection for Oracle9i.  When 
I try connecting to a DataSource, I get the following error. 

Cannot create resource instance

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-10 22:43 ---
I was considering that patch:

Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.13
diff -u -r1.13 ThreadPool.java
--- ThreadPool.java 7 Sep 2003 13:25:26 -   1.13
+++ ThreadPool.java 10 Sep 2003 22:38:53 -
@@ -282,7 +282,17 @@
 }
 
 public void run(Runnable r) {
-ControlRunnable c = findControlRunnable();
+ControlRunnable c = null;
+while (c == null) {
+c = findControlRunnable();
+if (c == null) {
+try {
+Thread.sleep(20);
+} catch (InterruptedException e) {
+// Ignore
+}
+}
+}
 c.runIt(r);
 }
 
@@ -301,7 +311,17 @@
 throw new NullPointerException();
 }
 
-ControlRunnable c = findControlRunnable();
+ControlRunnable c = null;
+while (c == null) {
+c = findControlRunnable();
+if (c == null) {
+try {
+Thread.sleep(20);
+} catch (InterruptedException e) {
+// Ignore
+}
+}
+}
 c.runIt(r);
 }
 
@@ -324,25 +344,7 @@
 openThreads(toOpen);
 } else {
logFull(log, currentThreadCount, maxThreads);
-// Wait for a thread to become idel.
-while(currentThreadsBusy == currentThreadCount) {
-try {
-this.wait();
-}
-   // was just catch Throwable -- but no other
-   // exceptions can be thrown by wait, right?
-   // So we catch and ignore this one, since
-   // it'll never actually happen, since nowhere
-   // do we say pool.interrupt().
-   catch(InterruptedException e) {
-   log.error(Unexpected exception, e);
-}
-
-// Pool was stopped. Get away of the pool.
-if(0 == currentThreadCount || stopThePool) {
-throw new IllegalStateException();
-}
-}
+return null;
 }
 }
 
@@ -678,9 +680,9 @@
 } finally {
 if(shouldRun) {
 shouldRun = false;
-/*
-   * Notify the pool that the thread is now idle.
-*/
+/**
+ * Notify the pool that the thread is now idle.
+ */
 p.returnController(this);
 }
 }

Of course, I don't know to much about the pooling code, and I can't reproduce
the issue to test if that fixes anything.
Please go ahead and fix it if you have a working solution :)

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



DO NOT REPLY [Bug 22645] - %@ include file =included.jsp % encoding problem

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22645.
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=22645

%@ include file =included.jsp % encoding problem

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 23:03 ---
I am afraid you can come up against a bug in the spec. See the duplicate bug 
for more info.

*** This bug has been marked as a duplicate of 19245 ***

-
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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19245.
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

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 23:03 ---
*** Bug 22645 has been marked as a duplicate of this bug. ***

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



DO NOT REPLY [Bug 19617] - [PATCH] pageEncoding attribute is reset when @page used in @include-d file

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19617.
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=19617

[PATCH] pageEncoding attribute is reset when @page used in @include-d file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-10 23:05 ---
It has been previously decided (see duplicate bug) that this spec bug will not 
be fixed.

*** This bug has been marked as a duplicate of 19245 ***

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



cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2003-09-10 Thread kinman
kinman  2003/09/10 16:11:56

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  - Use out.print(expr) instead of out.write(String.valueOf(expr)) for outputting
expressions in template texts.
  
  Revision  ChangesPath
  1.206 +4 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.205
  retrieving revision 1.206
  diff -u -r1.205 -r1.206
  --- Generator.java9 Sep 2003 21:46:22 -   1.205
  +++ Generator.java10 Sep 2003 23:11:56 -  1.206
  @@ -869,8 +869,7 @@
   
   public void visit(Node.Expression n) throws JasperException {
   n.setBeginJavaLine(out.getJavaLine());
  -out.printil(
  -out.write(String.valueOf( + new String(n.getText()) + )););
  +out.printil(out.print( + n.getText() + ););
   n.setEndJavaLine(out.getJavaLine());
   }
   
  
  
  

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



Re: Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Filip Hanik
you have to love this reply!!! ;)

filip
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 10, 2003 3:05 PM
Subject: Re: Coyote Performance Problems with HTTP1.1


Steve Appling wrote:
 Chunked encoding with the coyote http1.1 connector seems to be very
 inefficient.  I have 3 major comments about it which I will summarize,
then
 explain in more detail for those interested.

 1) There are some performance problems with the current implementation of
 chunked encoding.

 2) I would like to be able to turn off chunked encoding completely, but
this
 does not appear to be an option.

 3) Chunked encoding should probably only be used when returning content of
 indeterminate length.  Static files served up by the default servlet
should
 perhaps not be chunked.

Look, there's no reason to start whining. Adding a lower level buffering
(using a ByteChunk maybe) is nearly trivial, and since you seem to know
what you're doing, you could have done in less than the amount it took
you to write your email.
I'm not convinced it's the best solution all the time (Coyote leverages
the buffering mandated by the higher level - the servlet API - to avoid
useless copying from buffer to buffer).

-1 for option 2 (I consider keepalive is more important than anything else).

Remy



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



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



Re: [PATCH] Tomcat-4 Japanese resource fixes

2003-09-10 Thread Tetsuya Kitahata

Dear Jakarta-Tomcat Committers,

Hello,

I've verified and reviewed this patch (Japanese Resources).
This seems very good. Could you please apply this patch
because it helps us a lot ?

Thanks!

-- Tetsuya ([EMAIL PROTECTED])

P.S. I am willing to announce new beta release of the
TC 5.0.X @ jakarta-site2 (top page of jakarta website) :)  Remy

P.S.2 Personally, I prefer not to translate invoker (INBO-KA)
into Japanese. Transcriptions (into Katakana from English) would
not always be welcomed, in my humble opinion.  Kazama-san

On Wed, 10 Sep 2003 13:21:24 +0900 (JST)
(Subject: [PATCH] Tomcat-4 Japanese resource fixes)
Kazuhiro Kazama [EMAIL PROTECTED] wrote:

 This is a patch which refines Japanese messages in the Tomcat
 manager. Would you apply it to CVS?
 
 P.S.
 Now all Japanese messages are well-displayed in the Tomcat
 manager. Thank you, Remy!
 
 Kazuhiro Kazama ([EMAIL PROTECTED])   NTT Network Innovation Laboratories
 

---
Tetsuya Kitahata --  Terra-International, Inc.
E-mail: [EMAIL PROTECTED]  http://www.terra-intl.com/


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



DO NOT REPLY [Bug 22867] - Tag handlers can't be inner/nested classes

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22867.
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=22867

Tag handlers can't be inner/nested classes





--- Additional Comments From [EMAIL PROTECTED]  2003-09-11 00:04 ---
Yeah, I also prefer binary names (outter$inner) instead of canonical names
(outter.inner).  However, the J2EE folks still have not made a offical
decision yet.

There is simple algirithm that can let one compute the canonical name from a
Class object, without the restriction that the top-level class name not
continaing '$'.  The following is based on an algorithm by Mark Roth, the JSP
spec lead:

String getCanonicalName(Class c) {

Class outer = c.getDeclaringClass(c);
if (outer == null) {
return c.getName();
} else {
String innerName = c.getName().substring(outer.getName().length()+1);
return getCanonicalName(outer) + . + innerName; 
}
}

This is slightly more compilicated than replacing '$' with '.', but it covers
all cases.

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



Re: Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Peter Lin
 
I don't know about others, but my feeling is chunking is useful for large files and 
not necessarily where the size of the content is unknown at the beginning of the 
response. I seriously doubt a 2-5K static file would see a real benefit. We all know 
the internet has a ton of packet collision. therefore, sending non-chunked response 
over a slow connection would have a higher rate of failure. I haven't been on a modem 
in a long time, but if memory serves me correctly, downloading a 200K zip file on a 
modem tends to be faster with chunked encoding than non-chunked. Even with smart 
download, I remember chunked encoding being faster for large files. I could be wrong.
 
peter
 
 

---

3 - When to chunk

I thought that chunking was invented to handle serving up dynamically
created content that did not have a size known in advance. I believe that
on both IIS and Apache static content is not chunked. Is there any way for
tomcat to behave similarly - could the default servlet do something to
prevent the connector from chunking the data it serves up?





If you made it this far, thanks for taking the time to read this and
consider my questions.












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



-
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

Re: Coyote Performance Problems with HTTP1.1

2003-09-10 Thread Steve Appling
Remy Maucherat wrote:
 Look, there's no reason to start whining. Adding a lower level buffering
 (using a ByteChunk maybe) is nearly trivial, and since you seem to know
 what you're doing, you could have done in less than the amount it took
 you to write your email.
 I'm not convinced it's the best solution all the time (Coyote leverages
 the buffering mandated by the higher level - the servlet API - to avoid
 useless copying from buffer to buffer).

 -1 for option 2 (I consider keepalive is more important than anything
else).

I am perfectly willing to work on this, but it did not seem trivial to
someone not familiar with the coyote connector. I need to be able to point
out issues (and find out if they really are problems) without being accused
of whining.

You seem to imply that keepalive is tied to chunking - I believe these are
independent and chunking could be disabled without sacrificing keepalive.


-
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

2003-09-10 Thread luehe
luehe   2003/09/10 18:59:51

  Modified:catalina/src/share/org/apache/catalina/util RequestUtil.java
  Log:
  Fix for 4918152 (using % in the value of jsp:param corrupts the query string)
  
  Patch provided by [EMAIL PROTECTED]
  
  Revision  ChangesPath
  1.5   +11 -6 
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.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- RequestUtil.java  2 Sep 2003 21:22:06 -   1.4
  +++ RequestUtil.java  11 Sep 2003 01:59:51 -  1.5
  @@ -536,8 +536,13 @@
   data[ox++] = (byte)' ';
   break;
   case '%':
  -data[ox++] = (byte)((convertHexDigit(data[ix++])  4)
  -+ convertHexDigit(data[ix++]));
  +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;
  +}
   break;
   default:
   data[ox++] = c;
  
  
  

-
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 CoyoteRequest.java

2003-09-10 Thread jfarcand
jfarcand2003/09/10 20:56:48

  Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
  Log:
  Oups forgot that one (See previous commit)
  
  Revision  ChangesPath
  1.16  +10 -7 
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
  
  Index: CoyoteRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- CoyoteRequest.java31 Aug 2003 21:08:56 -  1.15
  +++ CoyoteRequest.java11 Sep 2003 03:56:48 -  1.16
  @@ -1767,15 +1767,18 @@
   public void setUserPrincipal(Principal principal) {
   
   if (System.getSecurityManager() != null){
  +HttpSession session = getSession(false);
   if ( (subject != null)  
(!subject.getPrincipals().contains(principal)) ){
   subject.getPrincipals().add(principal); 
  -} else if (getSession()
  -.getAttribute(Globals.SUBJECT_ATTR) == null) {
  +} else if (session != null 
  +session.getAttribute(Globals.SUBJECT_ATTR) == null) {
   subject = new Subject();
   subject.getPrincipals().add(principal); 
   }
  -getSession().setAttribute(Globals.SUBJECT_ATTR, subject);
  +if (session != null){
  +session.setAttribute(Globals.SUBJECT_ATTR, subject);
  +}
   } 
   
   this.userPrincipal = principal;
  
  
  

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



cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

2003-09-10 Thread billbarker
billbarker2003/09/10 21:05:02

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
  Log:
  Fix potential problem with dying threads when the pool is empty.
  
  Functionally, this isn't that much different from what Remy posted on Bug #21763.  
However (at least on high-end machines) it should be able to respond faster to a 
released CM.  Since the case that all threads are dead may be able to be handled, be 
less aggressive on checking this case.
  
  Also adding debug statements, since I'm not convinced that this is the fix for 21763 
(so I'm going to do some more testing before I close the bug).
  
  Revision  ChangesPath
  1.14  +31 -23
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- ThreadPool.java   7 Sep 2003 13:25:26 -   1.13
  +++ ThreadPool.java   11 Sep 2003 04:05:02 -  1.14
  @@ -308,14 +308,14 @@
   private ControlRunnable findControlRunnable() {
   ControlRunnable c=null;
   
  -if (0 == currentThreadCount || stopThePool) {
  +if ( stopThePool ) {
   throw new IllegalStateException();
   }
   
   // Obtain a free thread from the pool.
   synchronized(this) {
   
  -if (currentThreadsBusy == currentThreadCount) {
  +while (currentThreadsBusy == currentThreadCount) {
// All threads are busy
   if (currentThreadCount  maxThreads) {
   // Not all threads were open,
  @@ -323,29 +323,34 @@
   int toOpen = currentThreadCount + minSpareThreads;
   openThreads(toOpen);
   } else {
  - logFull(log, currentThreadCount, maxThreads);
  +logFull(log, currentThreadCount, maxThreads);
   // Wait for a thread to become idel.
  -while(currentThreadsBusy == currentThreadCount) {
  -try {
  -this.wait();
  -}
  - // was just catch Throwable -- but no other
  - // exceptions can be thrown by wait, right?
  - // So we catch and ignore this one, since
  - // it'll never actually happen, since nowhere
  - // do we say pool.interrupt().
  - catch(InterruptedException e) {
  - log.error(Unexpected exception, e);
  -}
  -
  -// Pool was stopped. Get away of the pool.
  -if(0 == currentThreadCount || stopThePool) {
  -throw new IllegalStateException();
  -}
  +try {
  +this.wait();
  +}
  +// was just catch Throwable -- but no other
  +// exceptions can be thrown by wait, right?
  +// So we catch and ignore this one, since
  +// it'll never actually happen, since nowhere
  +// do we say pool.interrupt().
  +catch(InterruptedException e) {
  +log.error(Unexpected exception, e);
  +}
  + if( log.isDebugEnabled() ) {
  + log.debug(Finished waiting: CTC=+currentThreadCount +
  +   , CTB= + currentThreadsBusy);
  +}
  +// Pool was stopped. Get away of the pool.
  +if( stopThePool) {
  +break;
   }
   }
   }
  -
  +// Pool was stopped. Get away of the pool.
  +if(0 == currentThreadCount || stopThePool) {
  +throw new IllegalStateException();
  +}
  +
   // If we are here it means that there is a free thread. Take it.
   int pos = currentThreadCount - currentThreadsBusy - 1;
   c = pool[pos];
  @@ -363,8 +368,11 @@
   increase maxThreads or check the servlet +
status + currentThreadCount +   +
   maxThreads  );
  - logfull=false;
  - } 
  +logfull=false;
  +} else if( log.isDebugEnabled() ) {
  +log.debug(All threads are busy  + currentThreadCount +   +
  +  maxThreads );
  +}
   }
   
   /**
  
  
  

-
To 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

2003-09-10 Thread billbarker
billbarker2003/09/10 21:15:42

  Modified:util/java/org/apache/tomcat/util/threads Tag: coyote_10
ThreadPool.java
  Log:
  port patch
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.9.2.2   +34 -24
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.9.2.1
  retrieving revision 1.9.2.2
  diff -u -r1.9.2.1 -r1.9.2.2
  --- ThreadPool.java   25 Jan 2003 04:49:24 -  1.9.2.1
  +++ ThreadPool.java   11 Sep 2003 04:15:42 -  1.9.2.2
  @@ -276,7 +276,7 @@
   throw new NullPointerException();
   }
   
  -if(0 == currentThreadCount || stopThePool) {
  +if( stopThePool ) {
   throw new IllegalStateException();
   }
   
  @@ -284,39 +284,46 @@
   
   // Obtain a free thread from the pool.
   synchronized(this) {
  -if(currentThreadsBusy == currentThreadCount) {
  +while (currentThreadsBusy == currentThreadCount) {
// All threads are busy
  -if(currentThreadCount  maxThreads) {
  +if (currentThreadCount  maxThreads) {
   // Not all threads were open,
   // Open new threads up to the max number of idel threads
   int toOpen = currentThreadCount + minSpareThreads;
   openThreads(toOpen);
   } else {
  - logFull(log, currentThreadCount, maxThreads);
  +logFull(log, currentThreadCount, maxThreads);
   // Wait for a thread to become idel.
  -while(currentThreadsBusy == currentThreadCount) {
  -try {
  -this.wait();
  -}
  - // was just catch Throwable -- but no other
  - // exceptions can be thrown by wait, right?
  - // So we catch and ignore this one, since
  - // it'll never actually happen, since nowhere
  - // do we say pool.interrupt().
  - catch(InterruptedException e) {
  - log.error(Unexpected exception, e);
  -}
  -
  -// Pool was stopped. Get away of the pool.
  -if(0 == currentThreadCount || stopThePool) {
  -throw new IllegalStateException();
  -}
  +try {
  +this.wait();
  +}
  +// was just catch Throwable -- but no other
  +// exceptions can be thrown by wait, right?
  +// So we catch and ignore this one, since
  +// it'll never actually happen, since nowhere
  +// do we say pool.interrupt().
  +catch(InterruptedException e) {
  +log.error(Unexpected exception, e);
  +}
  + if( log.isDebugEnabled() ) {
  + log.debug(Finished waiting: CTC=+currentThreadCount +
  +   , CTB= + currentThreadsBusy);
  +}
  +// Pool was stopped. Get away of the pool.
  +if( stopThePool) {
  +break;
   }
   }
   }
  -
  +// Pool was stopped. Get away of the pool.
  +if(0 == currentThreadCount || stopThePool) {
  +throw new IllegalStateException();
  +}
  +
   // If we are here it means that there is a free thread. Take it.
  -c = pool[currentThreadCount - currentThreadsBusy - 1];
  +int pos = currentThreadCount - currentThreadsBusy - 1;
  +c = pool[pos];
  +pool[pos] = null;
   currentThreadsBusy++;
   }
   c.runIt(r);
  @@ -330,7 +337,10 @@
status + currentThreadCount +   +
   maxThreads  );
logfull=false;
  - } 
  + }  else if( log.isDebugEnabled() ) {
  +log.debug(All threads are busy  + currentThreadCount +   +
  +  maxThreads );
  +}
   }
   
   /**
  
  
  

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

2003-09-10 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21763.
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-11 05:38 ---
After some initial test, I'm not sure that ThreadPool is really the problem.  
However if Remy's patch works, then this is fixed in the CVS (with a different, 
but fuctionally similar patch).  However, I'm inclined to think that this fixes 
a largely theoretical bug.

If someone that can reliably reproduce this can produce an automated test case, 
or at the least attach the full log file for it, it would be very helpful.

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