Re: Any synchronization issues with SMP?
Hi, we know one application running on 9 systems with 4 US II CPUs each under Solaris 9. Peak request rates at 20 requests/second per system. Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! You should send a signal QUIT to the jvm process during the unresponsiveness time. This is a general JVM mechanism (at least for sun JVMs). The signal writes a stack trace for each thread on STDOUT (so you should also start tomcat with redirection of STDOUT the output to some file). Beware: older JVM in rare cases stopped working after getting this signal (not expected with 1.3.1_09). In this stack dump you should be able to figure out, in which methods most of your threads stay and what the status is. Is there native code included (via JNI)? Any synchronization done in the application itself? Are you using Tomcat clustering? Which JVM? Sincerely Rainer Jung Martin Schulz wrote: Can someone confirm that Tomcat works well on busy SMP systems (e.g. Sun V1280), or whether there are problems in Tomcat. Here's what we have at our end: We are currently performance testing our application (Tomcat 4.1.30) on Solaris 9, on a V1280 system w. 8 CPUs. (SDK 1.4.2_04). Transaction rates are moderate, around 30/s. The application, after about 30-40 minutes, gets unresponsive for a little while (1-10 minutes), gets back to work (for a varying period of time, but definitely under 30 min), and then the cycle repeats. At half the transaction rate, the smptoms are no longer easily observed,. The above symptoms disappear when we use a single CPU, or a single board of 4 CPUs. That scenario seems to imply synchronization problems soemwhere in the Java code. The problem could not be observed in development configurations either (Wintel, 1-CPU Sun boxes.) The behavior is such that connections get accepted, but no response is sent (established connections remain at a fixed level). The number of connections in this state varies (20-70). From the timers we keep we learn that the service gets stuck when reading the input. Once unblocked the responses get sent out rapidly again. We have tuned the system for efficient, high-volume TCP-IP traffic. We tried the coyote connector and the HttpConnector, both with the same effect. Please respond if you can confirm or dismiss threading issues in Tomcat. We would also be ineterested in testing approaches for such a scenario. .I have kept system statistics for both scenarios and can provide these on request. Thanks! Martin Schulz - 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]
cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java
remm2004/06/23 01:25:04 Modified:catalina/src/share/org/apache/catalina/valves RequestDumperValve.java RequestFilterValve.java JDBCAccessLogValve.java ErrorReportValve.java AccessLogValve.java PersistentValve.java ValveBase.java ExtendedAccessLogValve.java RemoteAddrValve.java RemoteHostValve.java catalina/src/share/org/apache/catalina/connector RequestFacade.java Constants.java ResponseFacade.java catalina/src/share/org/apache/catalina Container.java Pipeline.java Realm.java Service.java Valve.java catalina/src/share/org/apache/catalina/core DummyRequest.java StandardWrapperValve.java StandardPipeline.java StandardServer.java DummyResponse.java ApplicationDispatcher.java StandardHostValve.java ApplicationFilterFactory.java ContainerBase.java StandardEngineValve.java StandardService.java StandardContextValve.java catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java NonLoginAuthenticator.java FormAuthenticator.java DigestAuthenticator.java SSLAuthenticator.java BasicAuthenticator.java AuthenticatorBase.java catalina/src/share/org/apache/catalina/startup Embedded.java Catalina.java catalina/src/share/org/apache/catalina/realm RealmBase.java JAASMemoryLoginModule.java catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java MBeanFactory.java ConnectorMBean.java MBeanUtils.java .build.xml modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java Added: catalina/src/share/org/apache/catalina/connector CoyoteOutputStream.java Connector.java Response.java CoyoteInputStream.java CoyoteAdapter.java MapperListener.java LocalStrings.properties LocalStrings_es.properties OutputBuffer.java LocalStrings_ja.properties LocalStrings_fr.properties CoyoteReader.java InputBuffer.java mbeans-descriptors.xml CoyoteWriter.java CoyotePrincipal.java Request.java Removed: catalina/src/share/org/apache/catalina/connector HttpResponseFacade.java HttpRequestFacade.java catalina/src/share/org/apache/catalina HttpRequest.java ValveContext.java HttpResponse.java Connector.java Request.java Response.java catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java CoyoteResponseFacade.java CoyoteRequestFacade.java MapperListener.java CoyoteServerSocketFactory.java LocalStrings_ja.properties CoyoteAdapter.java LocalStrings_fr.properties LocalStrings.properties CoyoteConnector.java CoyoteReader.java Constants.java CoyotePrincipal.java LocalStrings_es.properties CoyoteOutputStream.java CoyoteInputStream.java CoyoteWriter.java CoyoteResponse.java CoyoteRequest.java mbeans-descriptors.xml InputBuffer.java catalina/src/share/org/apache/catalina/core StandardValveContext.java catalina/src/share/org/apache/catalina/net DefaultServerSocketFactory.java ServerSocketFactory.java Log: - Move Coyote adapter to o.a.catalina.connector. - Remove interfaces for Request/Response and move to concrete classes. - Remove a lot of RTTI and casts on Request/Response. I likely missed some, so this is a WIP. - I'm using version number 5.5 for this refactoring, as an indication that this is no longer 5.0.x. - Move back to the valve pattern of Tomcat 4.0 beta 1 (I feel old now :( ), but without the double chaining. The extra robustness of the valve context is nice, but it added complexity (and was slower) and overall wasn't needed. - In the end, I didn't remove Logger yet (it'll be my next commit :) ). Revision ChangesPath 1.5 +39 -58 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java
[EMAIL PROTECTED] wrote: remm2004/06/23 01:25:04 Modified:catalina/src/share/org/apache/catalina/valves RequestDumperValve.java RequestFilterValve.java JDBCAccessLogValve.java ErrorReportValve.java AccessLogValve.java PersistentValve.java ValveBase.java ExtendedAccessLogValve.java RemoteAddrValve.java RemoteHostValve.java catalina/src/share/org/apache/catalina/connector RequestFacade.java Constants.java ResponseFacade.java catalina/src/share/org/apache/catalina Container.java Pipeline.java Realm.java Service.java Valve.java catalina/src/share/org/apache/catalina/core DummyRequest.java StandardWrapperValve.java StandardPipeline.java StandardServer.java DummyResponse.java ApplicationDispatcher.java StandardHostValve.java ApplicationFilterFactory.java ContainerBase.java StandardEngineValve.java StandardService.java StandardContextValve.java catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java NonLoginAuthenticator.java FormAuthenticator.java DigestAuthenticator.java SSLAuthenticator.java BasicAuthenticator.java AuthenticatorBase.java catalina/src/share/org/apache/catalina/startup Embedded.java Catalina.java catalina/src/share/org/apache/catalina/realm RealmBase.java JAASMemoryLoginModule.java catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java MBeanFactory.java ConnectorMBean.java MBeanUtils.java .build.xml modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java Added: catalina/src/share/org/apache/catalina/connector CoyoteOutputStream.java Connector.java Response.java CoyoteInputStream.java CoyoteAdapter.java MapperListener.java LocalStrings.properties LocalStrings_es.properties OutputBuffer.java LocalStrings_ja.properties LocalStrings_fr.properties CoyoteReader.java InputBuffer.java mbeans-descriptors.xml CoyoteWriter.java CoyotePrincipal.java Request.java Removed: catalina/src/share/org/apache/catalina/connector HttpResponseFacade.java HttpRequestFacade.java catalina/src/share/org/apache/catalina HttpRequest.java ValveContext.java HttpResponse.java Connector.java Request.java Response.java catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java CoyoteResponseFacade.java CoyoteRequestFacade.java MapperListener.java CoyoteServerSocketFactory.java LocalStrings_ja.properties CoyoteAdapter.java LocalStrings_fr.properties LocalStrings.properties CoyoteConnector.java CoyoteReader.java Constants.java CoyotePrincipal.java LocalStrings_es.properties CoyoteOutputStream.java CoyoteInputStream.java CoyoteWriter.java CoyoteResponse.java CoyoteRequest.java mbeans-descriptors.xml InputBuffer.java catalina/src/share/org/apache/catalina/core StandardValveContext.java catalina/src/share/org/apache/catalina/net DefaultServerSocketFactory.java ServerSocketFactory.java Log: - Move Coyote adapter to o.a.catalina.connector. - Remove interfaces for Request/Response and move to concrete classes. - Remove a lot of RTTI and casts on Request/Response. I likely missed some, so this is a WIP. - I'm using version number 5.5 for this refactoring, as an indication that this is no longer 5.0.x. - Move back to the valve pattern of Tomcat 4.0 beta 1 (I feel old now :( ), but without the double chaining. The extra robustness of the valve context is nice, but it added complexity (and was slower) and overall wasn't needed. - In the end, I didn't remove Logger yet (it'll be my next commit :) ). This commit was sponsored by Eclipse 3 RC 1 and its refatoring features :) Somehow, they spell that refactoring in the menus, but it's evidently a mistake, as the features are
DO NOT REPLY [Bug 29688] - HostConfig NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29688. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29688 HostConfig NullPointerException --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 08:57 --- After taking a deeper look into source code, there are several more points where the files list is not checked against null values. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 changes
Andy Armstrong wrote: (posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting stuck. Is there an incompatibility between a mod_jk2 built from the current CVS and the 5.0.27 binary build at jakarta.apache.org? It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. I get encouraging looking debug from it but requests that should be mapped using [uri:] in workers2.properties don't seem to get outside of Apache (which 404s). Requests using LocationMatch in httpd.conf result in a 503 Service Temporarily Unavailable and the following in the Apache error log: [error] lb_worker.service() all workers in error or disabled state [error] mod_jk2.handler() Error connecting to tomcat 12, status 503 My httpd.conf looks like this LoadModule jk2_module modules/mod_jk2.so JkSet config.file conf/workers2.properties LocationMatch /*.jsp JkUriSet group lb:lb /LocationMatch and workers2.properties is like this [logger] level=DEBUG [lb:lb] debug=10 [channel.socket:localhost:8009] debug=10 tomcatId=localhost:8009 [uri:/servlets-examples/*] debug=10 [uri:/jsp-examples/*] debug=10 Other info: Apache/2.0.49 (Unix) mod_jk2/2.0.5-dev Linux 2.4.22-1.2188.nptlsmp #1 SMP (Fedora Core #1) Tomcat 5.0.27 binary from jakarta.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] NullPointerException in org.apache.catalina.startup.HostConfig.java
Hi,
I reported this as bug 29688.
Problem is that possible null arrays might be passed to methods. The patch
simply checks for null arrays and returns from method in this case.
changed methods:
protected void deployDescriptors(File configBase, String[] files)
changed:
if (!deployXML || files==null)
return;
protected void deployDirectories(File appBase, String[] files)
added:
if (files==null)
return;
protected void deployWARs(File appBase, String[] files)
added:
if (files==null)
return;
The result from cvs diff -u HostConfig.java :
-- cut here --
Index: HostConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catali
na/startup/HostConfig.java,v
retrieving revision 1.31
diff -u -r1.31 HostConfig.java
--- HostConfig.java 27 May 2004 23:01:01 - 1.31
+++ HostConfig.java 23 Jun 2004 11:18:11 -
@@ -1,12 +1,12 @@
/*
* Copyright 1999,2004 The Apache Software Foundation.
- *
+ *
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -60,7 +60,7 @@
public class HostConfig
implements LifecycleListener {
-
+
private static org.apache.commons.logging.Log log=
org.apache.commons.logging.LogFactory.getLog( HostConfig.class );
@@ -273,8 +273,8 @@
this.unpackWARs = unpackWARs;
}
-
-
+
+
/**
* Set the validation feature of the XML parser used when
* parsing xml instances.
@@ -310,7 +310,7 @@
*/
public void setXmlNamespaceAware(boolean xmlNamespaceAware){
this.xmlNamespaceAware=xmlNamespaceAware;
-}
+}
// - Public
Methods
@@ -439,7 +439,7 @@
*/
protected void deployDescriptors(File configBase, String[] files) {
-if (!deployXML)
+if (!deployXML || files==null)
return;
for (int i = 0; i files.length; i++) {
@@ -468,8 +468,8 @@
if (host.findChild(contextPath) != null) {
if ((deployed.contains(file))
|| (deployed.contains(file + .war))) {
-// If this is a newly added context file and
-// it overrides a context with a simple path,
+// If this is a newly added context file and
+// it overrides a context with a simple path,
// that was previously deployed by the auto
// deployer, undeploy the context
((Deployer) host).remove(contextPath);
@@ -496,7 +496,8 @@
* Deploy WAR files.
*/
protected void deployWARs(File appBase, String[] files) {
-
+if (files==null)
+ return;
for (int i = 0; i files.length; i++) {
if (files[i].equalsIgnoreCase(META-INF))
@@ -534,7 +535,7 @@
entry = jar.getJarEntry(META-INF/context.xml);
if (entry != null) {
istream = jar.getInputStream(entry);
-
+
// Added for Bugzilla 29038
xml.mkdirs();
@@ -648,6 +649,8 @@
* Deploy directories.
*/
protected void deployDirectories(File appBase, String[] files) {
+if (files==null)
+ return;
for (int i = 0; i files.length; i++) {
@@ -679,7 +682,7 @@
continue;
// Deploy the application in this directory
-if( log.isDebugEnabled() )
+if( log.isDebugEnabled() )
log.debug(sm.getString(hostConfig.deployDir,
files[i]));
long t1=System.currentTimeMillis();
try {
@@ -726,11 +729,11 @@
// the context
continue;
}
-ResourceAttributes webXmlAttributes =
-(ResourceAttributes)
+ResourceAttributes webXmlAttributes =
+(ResourceAttributes)
resources.getAttributes(/WEB-INF/web.xml);
-ResourceAttributes webInfAttributes =
-(ResourceAttributes)
+ResourceAttributes webInfAttributes =
+(ResourceAttributes)
resources.getAttributes(/WEB-INF);
long
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java
This commit was sponsored by Eclipse 3 RC 1 and its refatoring features :) Somehow, they spell that refactoring in the menus, but it's evidently a mistake, as the features are powerful enough to warrant the Genuine Refatoring (R) label. Great use of Eclipse. Eclipse 3 RC3 is available and the final 3.0 release is scheduled in 2 weeks :) I think it should still build, but I didn't do a fresh checkout to verify. Let me know. It seems. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 changes
jean-frederic clere wrote: Andy Armstrong wrote: (posted to the right list now - oops) I'm just making sure the Lotus Domino connector works with the latest jk2 version. As a preamble to that I usually make sure I can get mod_jk2 working with Apache 2 as a kind of baseline. This time I'm getting stuck. Is there an incompatibility between a mod_jk2 built from the current CVS and the 5.0.27 binary build at jakarta.apache.org? Well I couldn't help much these time, but I strongly recommand to make a jk 1.2.6 and jK2 2.0.5 release as soon as possible since fixes and features has been added and users could be stuck since TC 5.0.x and jk/jk2 release cycle are very differents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp ReplicationValve.java
Henri Gomez wrote: This commit was sponsored by Eclipse 3 RC 1 and its refatoring features :) Somehow, they spell that refactoring in the menus, but it's evidently a mistake, as the features are powerful enough to warrant the Genuine Refatoring (R) label. Great use of Eclipse. Eclipse 3 RC3 is available and the final 3.0 release is scheduled in 2 weeks :) I think I have RC 2 right now; definitely not RC 3. I don't care, that version already does what I want. I think it should still build, but I didn't do a fresh checkout to verify. Let me know. It seems. Cool. Eclipse is great :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java MBeanFactory.java MBeanUtils.java
remm2004/06/23 06:51:38 Modified:catalina/src/share/org/apache/catalina/valves RequestDumperValve.java JDBCAccessLogValve.java ErrorReportValve.java PersistentValve.java ValveBase.java catalina/src/share/org/apache/catalina/connector Connector.java Request.java catalina/src/share/org/apache/catalina/core StandardHostDeployer.java StandardContext.java StandardWrapperValve.java NamingContextListener.java StandardPipeline.java ApplicationContext.java StandardServer.java ApplicationDispatcher.java StandardHostValve.java ContainerBase.java StandardContextValve.java catalina/src/share/org/apache/catalina/session FileStore.java StoreBase.java JDBCStore.java catalina/src/share/org/apache/catalina/loader WebappLoader.java catalina/src/share/org/apache/catalina Container.java catalina/src/share/org/apache/catalina/authenticator SingleSignOn.java NonLoginAuthenticator.java FormAuthenticator.java SSLAuthenticator.java AuthenticatorBase.java modules/cluster/src/share/org/apache/catalina/cluster/tcp SimpleTcpCluster.java modules/cluster/src/share/org/apache/catalina/cluster CatalinaCluster.java catalina/src/share/org/apache/catalina/startup Embedded.java HostConfig.java UserConfig.java ExpandWar.java EngineConfig.java ContextConfig.java HostRuleSet.java ContextRuleSet.java catalina/src/share/org/apache/catalina/realm UserDatabaseRealm.java RealmBase.java JAASMemoryLoginModule.java JDBCRealm.java JNDIRealm.java DataSourceRealm.java JAASCallbackHandler.java catalina/src/conf server.xml server-minimal.xml catalina/src/share/org/apache/catalina/mbeans ServerLifecycleListener.java MBeanFactory.java MBeanUtils.java Removed: catalina/src/share/org/apache/catalina Logger.java catalina/src/share/org/apache/catalina/logger LocalStrings.properties LocalStrings_es.properties LocalStrings_ja.properties FileLogger.java LoggerBase.java SystemErrLogger.java mbeans-descriptors.xml Constants.java LocalStrings_fr.properties SystemOutLogger.java Log: - Remove Logger and all related elements I could find. Some stale stuff is still likely there. - Remove as many debug fields as I could find. Obviously, this is replaced by Log.isDebugEnabled so that it is possible to enable debug from one location. - Remove useless log methods a little bit everywhere. - One big TODO: come up with a nice default log configuration for either JDK 1.4 logging or log4j. - I put in some categories names for containers which seemed relatively reasonable for a start, but I think these will be changed. Revision ChangesPath 1.6 +38 -74 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/RequestDumperValve.java.diff?r1=1.5r2=1.6 1.8 +2 -49 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/JDBCAccessLogValve.java.diff?r1=1.7r2=1.8 1.19 +3 -45 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java.diff?r1=1.18r2=1.19 1.7 +15 -26 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/PersistentValve.java.diff?r1=1.6r2=1.7 1.14 +1 -29 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java http://cvs.apache.org/viewcvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ValveBase.java.diff?r1=1.13r2=1.14 1.2 +1 -42 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
Re: jk2 changes
jean-frederic clere wrote: It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. Nope :( My investigations continue... -- Andy Armstrong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina Cluster.java
remm2004/06/23 07:00:04 Modified:catalina/src/share/org/apache/catalina Cluster.java Log: - Remove another debug flag. Revision ChangesPath 1.8 +1 -15 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Cluster.java Index: Cluster.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/Cluster.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Cluster.java 26 May 2004 15:24:59 - 1.7 +++ Cluster.java 23 Jun 2004 14:00:04 - 1.8 @@ -75,20 +75,6 @@ public Container getContainer(); /** - * The debug detail level for this Cluster - * - * @param debug The debug level - */ -public void setDebug(int debug); - -/** - * Returns the debug level for this Cluster - * - * @return The debug level - */ -public int getDebug(); - -/** * Set the protocol parameters. * * @param protocol The protocol used by the cluster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29763] New: - The encoding of jsp document
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29763. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29763 The encoding of jsp document Summary: The encoding of jsp document Product: Tomcat 5 Version: 5.0.25 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, there are three places where the encoding for a jsp document can be set. In the xml prolog according to XML 1.0 specification, deployment descriptor in the jsp-property-group and as value of pageEncoding attribute of jsp:directive.page /. When there are defined at least two of them, then they have to be the same. If there are a jsp document without xml prolog - for example: jsp:root version=1.2 xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:jsp=http://java.sun.com/JSP/Page; jsp:directive.page contentType=text/html/ !-- Shift_JIS -- jsp:directive.page pageEncoding=EUC-JP/ . /jsp:root the tomcat says that the encoding is UTF-8, not EUC-JP. Even when there is set the encoding EUC-JP in the deployment descriptor. If tomcat thinks that the encoding is UTF-8 it should report an error according to the JSP specification, because there is different encoding defined in value of pageEncoding. Regards Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 changes
jean-frederic clere wrote: It works on my machine (Apache/2.1.0-dev (Unix) DAV/2 mod_jk2/2.0.5-dev) May be that is a problem with IPV6: Use 127.0.0.1 instead of localhost. Problem fixed. That was odd. Rebooted the machine and it started working. I'm investigating further but it seems unlikely that it was a jk2 issue. Thanks for the input. -- Andy Armstrong - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
I see your back from vacation. I hope it was restful. I've started working on porting CLIPS 6.2 from C to Java. Once that is done, I will donate it back to CLIPS community (since it's public domain software), donate it as a project to apache and use it in RuleML development. JBoss should be able to use it too :) peter On Wed, 23 Jun 2004 20:02:04 +0200, Remy Maucherat [EMAIL PROTECTED] wrote: Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - 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: [5.next] Summary
TC 3.3 has o.a.t.u.xml.* which is uses instead of Digester. If it helps with re-inventing wheels, you could take a look at it. In any case, I may change TC 3.3 to start using o.a.t.u.digester, so +1. - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, June 23, 2004 11:02 AM Subject: Re: [5.next] Summary Remy Maucherat wrote: Remy Maucherat wrote: - Move to concrete classes for request/response, and remove all of the RTTI done in Catalina's pipeline Ok, I'm almost done with the first part of the refatoring (thanks to Eclipse 3) :) I think I'll commit when I'm done with the next two items, so that all the big core changes are done (for now ;) ). - Use Tomcat 4.0 beta valve pattern - Redo logging using commons-logging, and remove Logger I'll do on with the next item: - Fork commons-digester, to remove what we don't need (many fancy features provided by beanutils, and in the process remove dependencies on beanutils and collections) I'll use the o.a.t.util.digester package for this, and hopefully not too much refactoring will be needed. Since modeler needs digester, I'll do special prebuilding of the JAR to rename the imports (a bit like the prebuilding which is done for the servlet JSP JARs). I forgot about one nasty dependency chain, BTW: DPCB - pool - collections, which resides right now in the commons loader :( I'll save this for later ;) Rémy - 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]
DO NOT REPLY [Bug 29685] - jk2 worker does not work with multiple wildcards in the expression if one is trailing
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29685. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29685 jk2 worker does not work with multiple wildcards in the expression if one is trailing [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:Coyote JK 2 |Connector:AJP Product|Tomcat 4|Tomcat 5 Version|4.1.7 |5.0.25 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Peter Lin wrote: I see your back from vacation. I hope it was restful. No, no, I was doing a training in Vienna ;) I've started working on porting CLIPS 6.2 from C to Java. Once that is done, I will donate it back to CLIPS community (since it's public domain software), donate it as a project to apache and use it in RuleML development. I guess we could do crazy request mappings with that :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.next] Summary
Bill Barker wrote: TC 3.3 has o.a.t.u.xml.* which is uses instead of Digester. If it helps with re-inventing wheels, you could take a look at it. Yes, it's also in TC 4. I think it has limitations when compared to the digester. Overall, the biggest problem of the digester might be the huge amount instanceof DynaBean conditionals ;) In any case, I may change TC 3.3 to start using o.a.t.u.digester, so +1. Ok. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24774] - session timeout working only once
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=24774. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=24774 session timeout working only once --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 21:38 --- PersistentManagerBase has already been patched (see Bug 23468). As for the reasoning, I am afraid I can't shed any light on the reasoning. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29770] New: - rewriteURL() method depends on the call to getSession() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29770 rewriteURL() method depends on the call to getSession() method Summary: rewriteURL() method depends on the call to getSession() method Product: Tomcat 5 Version: 5.0.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Servlet JSP API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Despite the fact that all the criteria for the URL rewriting are met, the method HttpServletResponse#rewriteURL(...) actually appends the jsessionid parameter to the submitted URL only if a call to HttpServletRequest#getSession() was previously made. Otherwise the URL gets unchanged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29770] - rewriteURL() method depends on the call to getSession() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29770 rewriteURL() method depends on the call to getSession() method [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 22:40 --- This seems to be a huge problem to you, for a problem which is extremely unlikely to occur. Hopefully you have a patch to submit then ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Any synchronization issues with SMP?
Rainer, Thanks for the tips. I am about to take timing stats internally in the ThreadPool and the Tcp workers. Also, the described symptoms do not disappear, but seem to be of much shorter duration when only 4 CPUs are used for the application. I'll summarize what I find. Martin Rainer Jung wrote: Hi, we know one application running on 9 systems with 4 US II CPUs each under Solaris 9. Peak request rates at 20 requests/second per system. Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! You should send a signal QUIT to the jvm process during the unresponsiveness time. This is a general JVM mechanism (at least for sun JVMs). The signal writes a stack trace for each thread on STDOUT (so you should also start tomcat with redirection of STDOUT the output to some file). Beware: older JVM in rare cases stopped working after getting this signal (not expected with 1.3.1_09). In this stack dump you should be able to figure out, in which methods most of your threads stay and what the status is. Is there native code included (via JNI)? Any synchronization done in the application itself? Are you using Tomcat clustering? Which JVM? Sincerely Rainer Jung Martin Schulz wrote: Can someone confirm that Tomcat works well on busy SMP systems (e.g. Sun V1280), or whether there are problems in Tomcat. Here's what we have at our end: We are currently performance testing our application (Tomcat 4.1.30) on Solaris 9, on a V1280 system w. 8 CPUs. (SDK 1.4.2_04). Transaction rates are moderate, around 30/s. The application, after about 30-40 minutes, gets unresponsive for a little while (1-10 minutes), gets back to work (for a varying period of time, but definitely under 30 min), and then the cycle repeats. At half the transaction rate, the smptoms are no longer easily observed,. The above symptoms disappear when we use a single CPU, or a single board of 4 CPUs. That scenario seems to imply synchronization problems soemwhere in the Java code. The problem could not be observed in development configurations either (Wintel, 1-CPU Sun boxes.) The behavior is such that connections get accepted, but no response is sent (established connections remain at a fixed level). The number of connections in this state varies (20-70). From the timers we keep we learn that the service gets stuck when reading the input. Once unblocked the responses get sent out rapidly again. We have tuned the system for efficient, high-volume TCP-IP traffic. We tried the coyote connector and the HttpConnector, both with the same effect. Please respond if you can confirm or dismiss threading issues in Tomcat. We would also be ineterested in testing approaches for such a scenario. .I have kept system statistics for both scenarios and can provide these on request. Thanks! Martin Schulz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29770] - rewriteURL() method depends on the call to getSession() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29770 rewriteURL() method depends on the call to getSession() method --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 22:53 --- It is a huge problem because it prevents a spec-compliant web application from running properly on Tomcat. Why call it a refernce implementation then? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP@brutus]: jakarta-tomcat-5/jakarta-tomcat-5 failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact folk at [EMAIL PROTECTED] Project jakarta-tomcat-5 has an issue affecting its community integration, and has been outstanding for 10 runs. Project State : 'Failed', Reason 'Build Failed' Full details are available at: http://brutus.apache.org:8080/gump/jakarta-tomcat-5/jakarta-tomcat-5/index.html That said, some snippets follow: The following annotations were provided: -DEBUG- Jar [naming-resources.jar] identifier set to jar basename: [naming-resources] -DEBUG- Jar [servlets-default.jar] identifier set to jar basename: [servlets-default] -DEBUG- Jar [naming-common.jar] identifier set to jar basename: [naming-common] -DEBUG- Jar [catalina.jar] identifier set to jar basename: [catalina] -DEBUG- Jar [bootstrap.jar] identifier set to jar basename: [bootstrap] -DEBUG- Jar [servlets-common.jar] identifier set to jar basename: [servlets-common] -DEBUG- Jar [servlets-invoker.jar] identifier set to jar basename: [servlets-invoker] -INFO- Dependency on javamail exists, no need to add for property mail.jar. -INFO- Dependency on jaf exists, no need to add for property activation.jar. -INFO- Dependency on jakarta-servletapi-5-servlet exists, no need to add for property servlet-api.jar. -INFO- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property jsp-api.jar. -INFO- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar. -INFO- Dependency on xml-xerces exists, no need to add for property xml-apis.jar. -INFO- Dependency on jakarta-tomcat-util exists, no need to add for property tomcat-util.jar. -INFO- Dependency on commons-el exists, no need to add for property commons-el.jar. -INFO- Dependency on commons-logging exists, no need to add for property commons-logging-api.jar. -INFO- Dependency on commons-modeler exists, no need to add for property commons-modeler.jar. -INFO- Dependency on ant exists, no need to add for property ant.home. -INFO- Dependency on jsse exists, no need to add for property jsse.home. -INFO- Dependency on jmx exists, no need to add for property jmx.home. -INFO- Dependency on jmx exists, no need to add for property jmx.jar. -INFO- Dependency on jmx exists, no need to add for property jmx-tools.jar. -INFO- Dependency on jndi exists, no need to add for property jndi.home. -INFO- Dependency on jakarta-regexp exists, no need to add for property regexp.home. -INFO- Dependency on jakarta-regexp exists, no need to add for property regexp.jar. -INFO- Dependency on javamail exists, no need to add for property mail.home. -INFO- Dependency on jakarta-tomcat-coyote exists, no need to add for property tomcat-coyote.home. -INFO- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property jasper.home. -INFO- Dependency on jaf exists, no need to add for property activation.home. -INFO- Dependency on commons-modeler exists, no need to add for property commons-modeler.home. -INFO- Dependency on commons-daemon exists, no need to add for property commons-daemon.jsvc.tar.gz. -INFO- Dependency on jakarta-struts exists, no need to add for property struts.home. -INFO- Enable debug output, due to a sequence of 9 previous errors. -INFO- Failed with reason build failed The following work was performed: http://brutus.apache.org:8080/gump/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build) State: Failed Elapsed: 0 hours, 0 minutes, 27 seconds Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar org.apache.tools.ant.Main -debug -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtomcat33.home=*Unset* -Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri -Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar -Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-20040623.jar -Dmail.home=/usr/local/gump/packages/javamail-1.3 -Dant.home=/usr/local/gump/public/workspace/ant/dist -Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-20040623.jar -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar -DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build
DO NOT REPLY [Bug 29770] - rewriteURL() method depends on the call to getSession() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29770 rewriteURL() method depends on the call to getSession() method --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 23:02 --- So the obvious needs to be mentioned once again: if you want to whine, go somewhere else than the bug database. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Any synchronization issues with SMP?
Hi, I'm not sure whether this could be of any help, we had a similar problem and created a javacore and found a real basic locking in java output stream. The reason were concurrent System.out.println() in different threads for different requests which blocked the real stdout (some jsp's with some console output for checks). It was not a Tomcat application, but a wep app in bea (aix, 2 Processors), but it was really a problem in java, so could be the same. After removal of all System.out/err calls the error disappeared - obvious because reason was identified in core file. Sascha -Ursprüngliche Nachricht- Von: Martin Schulz [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 24. Juni 2004 00:37 An: Tomcat Developers List Betreff: Re: Any synchronization issues with SMP? Rainer, Thanks for the tips. I am about to take timing stats internally in the ThreadPool and the Tcp workers. Also, the described symptoms do not disappear, but seem to be of much shorter duration when only 4 CPUs are used for the application. I'll summarize what I find. Martin Rainer Jung wrote: Hi, we know one application running on 9 systems with 4 US II CPUs each under Solaris 9. Peak request rates at 20 requests/second per system. Tomcat is 4.1.29, Java is 1.3.1_09. No symptoms like yours! You should send a signal QUIT to the jvm process during the unresponsiveness time. This is a general JVM mechanism (at least for sun JVMs). The signal writes a stack trace for each thread on STDOUT (so you should also start tomcat with redirection of STDOUT the output to some file). Beware: older JVM in rare cases stopped working after getting this signal (not expected with 1.3.1_09). In this stack dump you should be able to figure out, in which methods most of your threads stay and what the status is. Is there native code included (via JNI)? Any synchronization done in the application itself? Are you using Tomcat clustering? Which JVM? Sincerely Rainer Jung Martin Schulz wrote: Can someone confirm that Tomcat works well on busy SMP systems (e.g. Sun V1280), or whether there are problems in Tomcat. Here's what we have at our end: We are currently performance testing our application (Tomcat 4.1.30) on Solaris 9, on a V1280 system w. 8 CPUs. (SDK 1.4.2_04). Transaction rates are moderate, around 30/s. The application, after about 30-40 minutes, gets unresponsive for a little while (1-10 minutes), gets back to work (for a varying period of time, but definitely under 30 min), and then the cycle repeats. At half the transaction rate, the smptoms are no longer easily observed,. The above symptoms disappear when we use a single CPU, or a single board of 4 CPUs. That scenario seems to imply synchronization problems soemwhere in the Java code. The problem could not be observed in development configurations either (Wintel, 1-CPU Sun boxes.) The behavior is such that connections get accepted, but no response is sent (established connections remain at a fixed level). The number of connections in this state varies (20-70). From the timers we keep we learn that the service gets stuck when reading the input. Once unblocked the responses get sent out rapidly again. We have tuned the system for efficient, high-volume TCP-IP traffic. We tried the coyote connector and the HttpConnector, both with the same effect. Please respond if you can confirm or dismiss threading issues in Tomcat. We would also be ineterested in testing approaches for such a scenario. .I have kept system statistics for both scenarios and can provide these on request. Thanks! Martin Schulz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29770] - rewriteURL() method depends on the call to getSession() method
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29770. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29770 rewriteURL() method depends on the call to getSession() method [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-06-23 23:20 --- Looking at the code (before submitting issues, please check with the latest release), getSession is correctly called during the processing of HttpServletResponse.encodeURL (it's not rewriteURL, FYI) - in isEncodeable to be precise -, so I can't see any reason why the application code would need to call it. If you still believe the issue is valid, please attach a WAR test case to the report. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29775] New: - tomcat 4.1 is not starting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29775 tomcat 4.1 is not starting Summary: tomcat 4.1 is not starting Product: Tomcat 4 Version: 4.1.24 Platform: Other OS/Version: Windows NT/2K Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when i start tomact 4.1 it is not getting started Bootstrap: Create Catalina server java.lang.NoSuchMethodError: java.util.logging.Logger.logp (Ljava/util/logging/Level;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String; )V at org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:126) at org.apache.commons.logging.impl.Jdk14Logger.info (Jdk14Logger.java:192) at org.apache.commons.modeler.Registry.loadRegistry(Registry.java:264) at org.apache.catalina.mbeans.MBeanUtils.createRegistry (MBeanUtils.java:1702) at org.apache.catalina.mbeans.MBeanUtils.clinit(MBeanUtils.java:163) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.clinit (GlobalResourcesLifecycleListener.java:117) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.InflatableConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance0(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.apache.commons.digester.ObjectCreateRule.begin (ObjectCreateRule.java:253) at org.apache.commons.digester.Rule.begin(Rule.java:200) at org.apache.commons.digester.Digester.startElement(Digester.java:1268) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement (Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument (Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1527) at org.apache.catalina.startup.CatalinaService.load (CatalinaService.java:187) at org.apache.catalina.startup.CatalinaService.load (CatalinaService.java:258) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.InflatableMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.BootstrapService.init (BootstrapService.java:231) at org.apache.catalina.startup.BootstrapService.main (BootstrapService.java:297) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Introduction
Hi, My name is Felipe and I just joined the devs list recently, as I would like to more involved with Tomcat's development. Until now I just collaborated doing a few bug reports/patches (using the address nagoya AT felipeal DOT net) but now that I'm part of JSR-245 I'd like to help more (I'm also a committer for the Jakarta Taglibs project - my login at ASF is felipeal). Anyway, I'm just sending this email to offer my help if you need something specific (like fixing a bug or doing some tests, including the TCKs). Right now I'm just reading 'How Tomcat Works' and preparing myself to JavaOne - but once I get back from the conference, I could do more. Regards, Felipe PS: hopefully I can meet some of you guys/gals at JavaOne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29777] New: - getParameterNames problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29777.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29777
getParameterNames problem
Summary: getParameterNames problem
Product: Tomcat 4
Version: 4.1.30
Platform: All
OS/Version: Solaris
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Version : tomcat 4.1.30
Tomcat component : org.apache.catalina.util.RequestUtil
Platform : Sparc
OS : Solaris 8
JVM - JDK 1.4.2_04
Web Server : Apache 2.0.49
request(GET) http[s]://hostname/context/servlet?test%
[Exception]
java.lang.ArrayIndexOutOfBoundsException: 8
at org.apache.catalina.util.RequestUtil.parseParameters(RequestUtil.
java:539)
at org.apache.catalina.util.RequestUtil.parseParameters(RequestUtil.
java:348)
at org.apache.catalina.connector.HttpRequestBase.
parseParameters(HttpRequestBase.java:632)
at org.apache.catalina.connector.HttpRequestBase.
getParameterNames(HttpRequestBase.java:748)
at org.apache.catalina.connector.RequestFacade.
getParameterNames(RequestFacade.java:176)
at javax.servlet.ServletRequestWrapper.
getParameterNames(ServletRequestWrapper.java:223)
at jp.co.test.testServlet.doGet(testServlet.java:38)
[patch]
# diff -u RequestUtil.java.orig RequestUtil.java
--- RequestUtil.java.orig 2004-06-24 13:11:11.36318 +0900
+++ RequestUtil.java2004-06-24 13:11:10.653172000 +0900
@@ -432,8 +432,17 @@
if (b == '+') {
b = (byte)' ';
} else if (b == '%') {
-b = (byte) ((convertHexDigit(bytes[ix++]) 4)
-+ convertHexDigit(bytes[ix++]));
+switch(len - ix) {
+case 0:
+b = (byte) 0;
+break;
+case 1:
+b = (byte) convertHexDigit(bytes[ix++]);
+break;
+default:
+b = (byte) ((convertHexDigit(bytes[ix++]) 4)
++ convertHexDigit(bytes[ix++]));
+};
}
bytes[ox++] = b;
}
@@ -536,8 +545,17 @@
data[ox++] = (byte)' ';
break;
case '%':
-data[ox++] = (byte)((convertHexDigit(data[ix++]) 4)
-+ convertHexDigit(data[ix++]));
+switch(data.length - ix) {
+case 0:
+data[ox++] = (byte)0;
+break;
+case 1:
+data[ox++] = (byte)convertHexDigit(data[ix++]);
+break;
+default:
+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 29778] New: - Embedded does not function as documented (works in v4 fine)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29778. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29778 Embedded does not function as documented (works in v4 fine) Summary: Embedded does not function as documented (works in v4 fine) Product: Tomcat 5 Version: 5.0.25 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Had Embedded running in v4 fine, but in v5 it is having serious issues. Firstly... the modeler.Registry called from WebappLoader is using the default classpath, and cannot find Xerces in our implementation. In v4 this was not an issue. Specifying Registry.setUseContextClassLoader(true), causes Xerces to be found, but then causes StandardEngine.init(363)-Registry.registerComponent(859) to throw an NPE b/c it references the 'registry' variable which will never be initialized when UseContextClassLoader is used. This is probably a bug in commons-modeler - but perhaps there is a more appropriate way to configure Embedded that avoids this?... The javadocs for Embedded look the same as in v4 -- but since they don't appear to work, perhaps they are out of date or unknown/untested. Also noted in toying /w the code... that even though you can set Embedded.setCatalinaBase -- several classes still read directly from System.getProperty(catalina.base) and will fail without it... this is undocumented in the Embedded javadocs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
