RE: [GSOC] Feedback on my project proposal "Improve the JMX support within Apache Tomcat"
I have posted comments and suggestions to update my proposal. Please feedback Anas _ Rediscover Hotmail®: Get quick friend updates right in your inbox. http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Updates1_042009
Re: svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
Filip Hanik - Dev Lists wrote:
Is the idea here to communicate the Tomcat server state to httpd using
multicast?
Yes.
For that, you could simply build the feature set into
org.apache.catalina.ha where you can send multicast packets, where you
already have heart beat information etc.
Well the feature doesn't require a clustered tomcat.
So going that route, why not use code, or at least copy/paste the code
where we fixed the bugs :)
However, if I was to voice my opinion, I think you can easily transfer
all the information you need as HTTP headers, and hence you could do so
with minimal coding effort.
Multicast seems funky, since the httpd server already talks TCP/HTTP/AJP
to tomcat. Why another transport protocol. Multicast is usually
disallowed through firewalls, which means the very common scenario of
having httpd in the DMZ and tomcat on the other side of the firewall
will not work.
The idea is to use this code with the already existing code in
httpd-trunk and the httpd module uses multicast.
But yes I agree that the idea to use TCP/HTTP is a good option too but
that requires more code on the httpd side.
Cheers
Jean-Frederic
Filip
jean-frederic clere wrote:
Rainer Jung wrote:
A few comments inline.
On 06.04.2009 17:09, jfcl...@apache.org wrote:
Author: jfclere
Date: Mon Apr 6 15:09:19 2009
New Revision: 762374
URL: http://svn.apache.org/viewvc?rev=762374&view=rev
Log:
First support for httpd-trunk heartbeat logic.
Added:
tomcat/trunk/java/org/apache/catalina/cluster/
tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=762374&r1=762373&r2=762374&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Mon Apr 6 15:09:19 2009
@@ -204,7 +204,6 @@
-
See below concerning the package name.
Added: tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java?rev=762374&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
(added)
+++ tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
Mon Apr 6 15:09:19 2009
...
+package org.apache.catalina.cluster;
Should we really reuse this package name? Until TC 5.5 that was the old
cluster, and the package name is still in use for the same classes in
the oacc sandbox.
Ok... What about backend?
+
+/* for MBean to read ready and busy */
+
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.ObjectInstance;
+import java.util.Enumeration;
+import java.util.Iterator;
+import java.util.Set;
+
+import org.apache.tomcat.util.modeler.Registry;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+
+/*
+ * Listener to provider informations to mod_heartbeat.c
+ * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
+ * send the muticast merssage using the format...
+ * what about the bind(IP. port) only IP makes sense (for the moment).
+ * BTW:v = version :-)
+ */
+public class CollectedInfo {
+
+/* Collect info via JMX */
+protected MBeanServer mBeanServer = null;
+protected ObjectName objName = null;
+
+int ready;
+int busy;
+
+public CollectedInfo(String host, int port) throws Exception {
+init(host, port);
+}
+public void init(String host, int port) throws Exception {
+String sport = Integer.toString(port);
+mBeanServer = Registry.getRegistry(null,
null).getMBeanServer();
+String onStr = "*:type=ThreadPool,*";
Use a constant for this string?
+ObjectName objectName = new ObjectName(onStr);
+Set set = mBeanServer.queryMBeans(objectName, null);
+Iterator iterator = set.iterator();
+while (iterator.hasNext()) {
+ObjectInstance oi = iterator.next();
+objName = oi.getObjectName();
+String name = objName.getKeyProperty("name");
+/* Name are:
+ * http-8080
+ * jk-10.33.144.3-8009
+ * jk-jfcpc%2F10.33.144.3-8009
+ */
+if (port==0 && host==null)
+ break; /* Take the first one */
+String [] elenames = name.split("-");
+if (elenames[elenames.length-1].compareTo(sport) != 0)
+continue; /* port doesn't match */
+if (host==null)
+break; /* Only port done */
+String [] shosts = elenames[1].split("%2F");
+if (shosts[0].compareTo(host) == 0)
+break; /*
[VOTE] Release build 6.0.19
The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.19/ According to the release process, the 6.0.19 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Note: The i18n issue for the French language could be addressed by providing a replacement JAR from a bugzilla, since I suppose the affected user base is not that large. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "FAQ/Logging" by plinius
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The following page has been changed by plinius: http://wiki.apache.org/tomcat/FAQ/Logging -- 1. [#Q6 Where does System.out go? How do I rotate catalina.out?] 1. [#Q7 Where are the logs when running Tomcat as a Windows service?] 1. [#Q8 How do I customize the location of the tomcat logging.properties file?] + 1. [#Q9 Since java.logging is the default commons-logging implementation in Tomcat, why is it not working in my Linux distribution?] == Answers == @@ -57, +58 @@ [[Anchor(Q4)]]'''How do I configure commons-logging for use with Tomcat?''' + You need to specify a commons-logging configuration file and, if you wish, a logging implementation that supports commons-logging. JDK 1.4 (and later) java.util.Logging and Log4j are the two most commonly used logging toolkits for Tomcat. + Tomcat 5.5 and Tomcat 6.0 use java.logging as default implementation for commons-logging. So this ''should'' work by default, but sometimes it doesn't (see [#Q9]). - You need to specify a commons-logging configuration file and, if you wish, a logging implementation that supports commons-logging. JDK 1.4 (and later) java.util.Logging and Log4j are the two most commonly used logging toolkits for Tomcat. If you supply an external logging toolkit such as Log4J, it needs to be located in the $CATALINA_HOME/common/lib directory (for Tomcat 5.0 and earlier). Tomcat 5.5 and later uses commons-logging while bootstrapping so some people suggest adding Log4j to the bootstrap classpath by using the scripts in $CATALINA_HOME/bin (see [http://markmail.org/message/3sgxfol3njcfutsm Need for it to be in bootstrap classpath?]). A better approch apparently working is: + If you supply an external logging toolkit such as Log4J, it needs to be located in the $CATALINA_HOME/common/lib directory (for Tomcat 5.0 and earlier). Tomcat 5.5 and later uses commons-logging while bootstrapping so some people suggest adding Log4j to the bootstrap classpath by using the scripts in $CATALINA_HOME/bin (see [http://markmail.org/message/3sgxfol3njcfutsm Need for it to be in bootstrap classpath?]). A better approch apparently working is: 1. Put jog4j.jar in the $CATALINA_HOME/common/lib directory 2. Put the ''full'' commons-logging.jar in the $CATALINA_HOME/common/lib directory, even if you see the ''reduced'' API version there, named commons-logging-api.jar @@ -111, +114 @@ startup script. On Fedora the startup script in typically located in /etc/rc.d/init.d/ and on - Gentoo linux it is located in /etc/init.d/. + Gentoo linux it is located in /etc/init.d/. On RedHat the startup script for Tomcat 5.5 is /etc/init.d/tomcat5 but eventually the real startup script is /usr/bin/dtomcat5. + [[Anchor(Q9)]]'''Since java.logging is the default commons-logging implementation in Tomcat, why is it not working in my Linux distribution?''' + + Yes, if you read Tomcat logging documentation, it says java.util.logging should work by default. But many Linux distribution repackage Tomcat and sometimes it does NOT work by default. + + Here are some things you can check: + 1. tomcat-juli.jar should be in your $CATALINA_HOME/bin directory + 1. tomcat startup script should run java with -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager + 1. tomcat startup script should run java with -Djava.util.logging.config.file=/logging.properties + 1. obviously, the logging.properties file must exist in the directory specified in the tomcat script at point #3 + + If you don't know where to look for your Tomcat startup script, see the previous [#Q8 How do I customize the location of the tomcat logging.properties file?] + + In RHEL5 (RedHat Enterprise Server 5) the Tomcat 5.5 rpm installation does not include the tomcat-juli.jar file. This is what I made: + * look for what Tomcat version you got installed with: yum list installed tomcat5 + Since I had the 5.5.23, I downloaded the Tomcat Binaries 5.5.23 from http://archive.apache.org/dist/tomcat/, then: + * tar xf apache-tomcat-5.5.23.tar.gz + * cd apache-tomcat-5.5.23/bin + * cp tomcat-juli.jar /usr/share/tomcat5/bin/ + Restart Tomcat... and it's working! + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PATCH]: configurable session cookie domain (subdomain session support)
On 07.04.2009 00:46, Brane F. Gračnar wrote: > On Monday 06 April 2009 18:19:26 Mark Thomas wrote: >> It would also be a good idea to >> include an update to the documentation in your patch. > > I know that this is a stupid question, but i don't have any idea which files > to update :) http://marc.info/?l=tomcat-user&m=123729925416509&w=2 Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PATCH]: configurable session cookie domain (subdomain session support)
On Monday 06 April 2009 18:19:26 Mark Thomas wrote: > Please create a bugzilla entry for this and attach the patch there so it > doesn't get lost. Done. > To keep this consistent with httpOnly, this should be configured at the > Context level rather than the manager. Ok, this makes sense. I'll try to push this somewhere in context and i'll try to create another patch. > It would also be a good idea to > include an update to the documentation in your patch. I know that this is a stupid question, but i don't have any idea which files to update :) If all mentioned criterias will be met, are there any chances to push this into future releases of 6.0.x? Best regards, Brane - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
On Mon, Apr 6, 2009 at 3:06 PM, Filip Hanik - Dev Lists wrote: > Mladen Turk wrote: > >> Costin Manolache wrote: >> >>> So in essence you have a new protocol but the sole difference is how you describe it. >>> >>> The API can be something like: >>> - legacyRequest(RequestMessage) - whatever we have in the current AJP >>> protocol >>> - getServerLoad() and whatever new we wanted to add >>> >>> Instead of defining AJP extensions, we just pick one of the marshalling >>> libs >>> and use them >>> for encoding the new methods. >>> >>> >> Again, you are presuming a new protocol and IMO everyone >> here are just getting nasty red spots on their faces when >> you do such a thing ;) >> > I was gonna reply earlier, but my red spot reaction got kind of severe :) > I have a hard time seeing why we would need yet another protocol. > I think history has shown that to be a tough challenge. I am saying the exact same thing - we shouldn't add another protocol, it was a mistake to even have AJP proto in the first place, and we shouldn't attempt to extend it. However we do need some form of communication between tomcat and jk - what AJP provides won't allow much. And what I was suggesting is to not do another protocol - but find an existing one and use/adapt it. Costin > >> IMHO the solution would be to gather separate >> community and move all development outside the >> Tomcat, because it simply doesn't fit here. >> The current code base for mod_jk and java side >> connector is huge, and imagine how large it would >> be with all the bells and whistles added. >> >> Tomcat could serve as an incubator for such a >> project, but I see no reason not to use >> Apache Incubator directly. Maybe we will >> attract larger community this way. >> >> >> Regards >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
DO NOT REPLY [Bug 45026] Custom HTTP-Error codes get remapped to 500er codes
https://issues.apache.org/bugzilla/show_bug.cgi?id=45026 --- Comment #9 from Rainer Jung 2009-04-06 15:14:57 PST --- A fix has also been applied to TC 6.0 (r762499 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=762499 ) and TC 5.5 (r762510 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=762510 ) to become part of 6.0.20 and 5.5.28. So updating either one of mod_jk or Tomcat does already solve the problem. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
Is the idea here to communicate the Tomcat server state to httpd using
multicast?
For that, you could simply build the feature set into
org.apache.catalina.ha where you can send multicast packets, where you
already have heart beat information etc.
So going that route, why not use code, or at least copy/paste the code
where we fixed the bugs :)
However, if I was to voice my opinion, I think you can easily transfer
all the information you need as HTTP headers, and hence you could do so
with minimal coding effort.
Multicast seems funky, since the httpd server already talks TCP/HTTP/AJP
to tomcat. Why another transport protocol. Multicast is usually
disallowed through firewalls, which means the very common scenario of
having httpd in the DMZ and tomcat on the other side of the firewall
will not work.
Filip
jean-frederic clere wrote:
Rainer Jung wrote:
A few comments inline.
On 06.04.2009 17:09, jfcl...@apache.org wrote:
Author: jfclere
Date: Mon Apr 6 15:09:19 2009
New Revision: 762374
URL: http://svn.apache.org/viewvc?rev=762374&view=rev
Log:
First support for httpd-trunk heartbeat logic.
Added:
tomcat/trunk/java/org/apache/catalina/cluster/
tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=762374&r1=762373&r2=762374&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Mon Apr 6 15:09:19 2009
@@ -204,7 +204,6 @@
-
See below concerning the package name.
Added: tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java?rev=762374&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
(added)
+++ tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
Mon Apr 6 15:09:19 2009
...
+package org.apache.catalina.cluster;
Should we really reuse this package name? Until TC 5.5 that was the old
cluster, and the package name is still in use for the same classes in
the oacc sandbox.
Ok... What about backend?
+
+/* for MBean to read ready and busy */
+
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.ObjectInstance;
+import java.util.Enumeration;
+import java.util.Iterator;
+import java.util.Set;
+
+import org.apache.tomcat.util.modeler.Registry;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+
+/*
+ * Listener to provider informations to mod_heartbeat.c
+ * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
+ * send the muticast merssage using the format...
+ * what about the bind(IP. port) only IP makes sense (for the moment).
+ * BTW:v = version :-)
+ */
+public class CollectedInfo {
+
+/* Collect info via JMX */
+protected MBeanServer mBeanServer = null;
+protected ObjectName objName = null;
+
+int ready;
+int busy;
+
+public CollectedInfo(String host, int port) throws Exception {
+init(host, port);
+}
+public void init(String host, int port) throws Exception {
+String sport = Integer.toString(port);
+mBeanServer = Registry.getRegistry(null,
null).getMBeanServer();
+String onStr = "*:type=ThreadPool,*";
Use a constant for this string?
+ObjectName objectName = new ObjectName(onStr);
+Set set = mBeanServer.queryMBeans(objectName, null);
+Iterator iterator = set.iterator();
+while (iterator.hasNext()) {
+ObjectInstance oi = iterator.next();
+objName = oi.getObjectName();
+String name = objName.getKeyProperty("name");
+/* Name are:
+ * http-8080
+ * jk-10.33.144.3-8009
+ * jk-jfcpc%2F10.33.144.3-8009
+ */
+if (port==0 && host==null)
+ break; /* Take the first one */
+String [] elenames = name.split("-");
+if (elenames[elenames.length-1].compareTo(sport) != 0)
+continue; /* port doesn't match */
+if (host==null)
+break; /* Only port done */
+String [] shosts = elenames[1].split("%2F");
+if (shosts[0].compareTo(host) == 0)
+break; /* Done port and host are the expected ones */
+}
+if (objName == null)
+throw(new Exception("Can't find connector for " + host
+ ":" + sport));
++}
+
+public void refresh() throws Exception {
+if (mBeanServer == null || objName == null) {
+throw(new Exception("Not initialized!!!"));
+
Re: [Proposal] Remove older of the two BIO AJP connectors
Mladen Turk wrote: Costin Manolache wrote: So in essence you have a new protocol but the sole difference is how you describe it. The API can be something like: - legacyRequest(RequestMessage) - whatever we have in the current AJP protocol - getServerLoad() and whatever new we wanted to add Instead of defining AJP extensions, we just pick one of the marshalling libs and use them for encoding the new methods. Again, you are presuming a new protocol and IMO everyone here are just getting nasty red spots on their faces when you do such a thing ;) I was gonna reply earlier, but my red spot reaction got kind of severe :) I have a hard time seeing why we would need yet another protocol. I think history has shown that to be a tough challenge. IMHO the solution would be to gather separate community and move all development outside the Tomcat, because it simply doesn't fit here. The current code base for mod_jk and java side connector is huge, and imagine how large it would be with all the bells and whistles added. Tomcat could serve as an incubator for such a project, but I see no reason not to use Apache Incubator directly. Maybe we will attract larger community this way. Regards - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762524 - in /tomcat: connectors/trunk/jk/java/org/apache/coyote/ajp/ connectors/trunk/jk/java/org/apache/jk/common/ container/tc5.5.x/webapps/docs/ current/tc5.5.x/
Author: rjung
Date: Mon Apr 6 21:55:11 2009
New Revision: 762524
URL: http://svn.apache.org/viewvc?rev=762524&view=rev
Log:
Allow AJP connectors to provide correct getRemotePort().
The remote port is not part of the AJP13 protocol.
Since the protocol is not extensible enough for standard
attributes, we use generic attributes mechanism to forward
the remote port as AJP_REMOTE_PORT.
Backport of r756926 and r757223.
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java
tomcat/connectors/trunk/jk/java/org/apache/jk/common/AjpConstants.java
tomcat/connectors/trunk/jk/java/org/apache/jk/common/HandlerRequest.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
tomcat/current/tc5.5.x/STATUS.txt
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=762524&r1=762523&r2=762524&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
Mon Apr 6 21:55:11 2009
@@ -731,7 +731,21 @@
String n = tmpMB.toString();
requestHeaderMessage.getBytes(tmpMB);
String v = tmpMB.toString();
-request.setAttribute(n, v);
+/*
+ * AJP13 misses to forward the remotePort.
+ * Allow the AJP connector to add this info via
+ * a private request attribute.
+ * We will accept the forwarded data as the remote port,
+ * and remove it from the public list of request attributes.
+ */
+if(n.equals(Constants.SC_A_REQ_REMOTE_PORT)) {
+try {
+request.setRemotePort(Integer.parseInt(v));
+} catch (NumberFormatException nfe) {
+}
+} else {
+request.setAttribute(n, v);
+}
break;
case Constants.SC_A_CONTEXT :
Modified: tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java?rev=762524&r1=762523&r2=762524&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java Mon
Apr 6 21:55:11 2009
@@ -85,6 +85,11 @@
// Used for attributes which are not in the list above
public static final byte SC_A_REQ_ATTRIBUTE = 10;
+/**
+ * AJP private request attributes
+ */
+public static final String SC_A_REQ_REMOTE_PORT = "AJP_REMOTE_PORT";
+
// Terminates list of attributes
public static final byte SC_A_ARE_DONE = (byte)0xFF;
Modified: tomcat/connectors/trunk/jk/java/org/apache/jk/common/AjpConstants.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/jk/common/AjpConstants.java?rev=762524&r1=762523&r2=762524&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/jk/common/AjpConstants.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/jk/common/AjpConstants.java Mon
Apr 6 21:55:11 2009
@@ -97,6 +97,11 @@
public static final byte SC_A_REQ_ATTRIBUTE = 10;
/**
+ * AJP private request attributes
+ */
+public static final String SC_A_REQ_REMOTE_PORT = "AJP_REMOTE_PORT";
+
+/**
* Terminates list of attributes
*/
public static final byte SC_A_ARE_DONE = (byte)0xFF;
Modified:
tomcat/connectors/trunk/jk/java/org/apache/jk/common/HandlerRequest.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/jk/common/HandlerRequest.java?rev=762524&r1=762523&r2=762524&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/jk/common/HandlerRequest.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/jk/common/HandlerRequest.java
Mon Apr 6 21:55:11 2009
@@ -447,9 +447,23 @@
String n=tmpMB.toString();
msg.getBytes( tmpMB );
String v=tmpMB.toString();
-req.setAttribute(n, v );
-if(log.isTraceEnabled())
-log.trace("jk Attribute set " + n + "=" + v);
+/*
+ * AJP13 misses to forward the remotePort.
+ * Allow the AJP connector to add this info via
+ * a private request
svn commit: r762510 - in /tomcat: connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java container/tc5.5.x/webapps/docs/ch
Author: rjung
Date: Mon Apr 6 21:25:09 2009
New Revision: 762510
URL: http://svn.apache.org/viewvc?rev=762510&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
Never use empty reason phrase.
Backport of r697183 and r757721.
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
tomcat/current/tc5.5.x/STATUS.txt
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=762510&r1=762509&r2=762510&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
Mon Apr 6 21:25:09 2009
@@ -951,6 +951,10 @@
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
+if (message == null) {
+// mod_jk + httpd 2.x fails with a null status message - bug 45026
+message = Integer.toString(response.getStatus());
+}
tmpMB.setString(message);
responseHeaderMessage.appendBytes(tmpMB);
Modified:
tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java?rev=762510&r1=762509&r2=762510&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/jk/common/JkInputStream.java Mon
Apr 6 21:25:09 2009
@@ -288,6 +288,10 @@
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
+if (message == null) {
+// mod_jk + httpd 2.x fails with a null status message - bug 45026
+message = Integer.toString(res.getStatus());
+}
tempMB.setString( message );
c2b.convert( tempMB );
outputMsg.appendBytes(tempMB);
Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=762510&r1=762509&r2=762510&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Mon Apr 6 21:25:09 2009
@@ -84,6 +84,14 @@
+
+
+
+45026: Never return an empty HTTP status reason phrase.
+mod_jk and httpd 2.x do not like that. (rjung)
+
+
+
Modified: tomcat/current/tc5.5.x/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/current/tc5.5.x/STATUS.txt?rev=762510&r1=762509&r2=762510&view=diff
==
--- tomcat/current/tc5.5.x/STATUS.txt (original)
+++ tomcat/current/tc5.5.x/STATUS.txt Mon Apr 6 21:25:09 2009
@@ -37,14 +37,6 @@
+1: pero, markt, mturk
-1:
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
- Never use empty reason phrase.
- http://svn.apache.org/viewvc?rev=697183&view=rev
- +1: rjung, markt, mturk
- -1:
- markt: also required for other AJP connectors
- rjung: see below, I added a backport proposal for the other ones.
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45880
More careful use of File /r and and NOTICE file
http://people.apache.org/~markt/patches/2008-09-24-bug45880.patch
@@ -175,14 +167,6 @@
+1: rjung, markt, pero
-1:
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
- Never use empty reason phrase.
- Part 2 of the backport proposed and approved above
- (r697183), now also for the other AJP connectors.
- http://svn.apache.org/viewvc?rev=757721&view=rev
- +1: rjung, markt, pero
- -1:
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41606
Prevent double init() of JSP
Patch provided by Chris Halstead
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: How to produce a Comet READ Event (EventType.READ) from the client side?
Comet READ events are generating when there is a POST method with a body
John Dous wrote:
Hello,
Recently I started to develop a web application
that is based on the Comet Architecture. After a lot of research, I realize
that there is a lack of documentation and tutorials about how to build simple
Comet
applications on Tomcat. The tomcat Advanced IO documentation previews the way
that the server handles the incoming different type events, but doesn’t explain
how to produce these events from the client side (ex. IE, Firefox). The
javascript snippet
below produces such an event.
function newConnection(){
xhr = new XMLHttpRequest();
xhr.open('GET','/comet' ,true);
xhr.send(null);
}
When I execute this function, a new event (EventType.Begin)
arrives on the CometServlet.
I am wondering if there is way to produce an (EventType.READ)
event from the client side.
Any suggestions?
Thanks in advance!
_
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762507 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/coyote/ajp/ java/org/apache/jk/common/ webapps/docs/
Author: rjung
Date: Mon Apr 6 21:10:05 2009
New Revision: 762507
URL: http://svn.apache.org/viewvc?rev=762507&view=rev
Log:
Allow huge request body packets for AJP13.
Backport of r697192 and r757708.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=762507&r1=762506&r2=762507&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Apr 6 21:10:05 2009
@@ -38,14 +38,6 @@
0: remm (looks risky, very minor problem), fhanik - minor problem
-1:
-* Allow huge request body packets for AJP13.
- This was already applied to connectors, but never
- carried forward to trunk and tc6.0.x.
- http://svn.apache.org/viewvc?rev=697192&view=rev
- Original change: http://svn.apache.org/viewvc?rev=486217&view=rev
- +1: rjung, mturk, markt, pero, jim
- 0: remm (also affects to the two other AJP connectors)
-
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45403
See commit message for details of negligable performance impact
http://svn.apache.org/viewvc?rev=701358&view=rev
@@ -80,13 +72,6 @@
+1: markt, rjung
-1:
-* Allow huge request body packets for AJP13.
- Part 2 of the backport proposed and approved above
- (r697192), now also for the other AJP connectors.
- http://svn.apache.org/viewvc?rev=757708&view=rev
- +1: rjung, markt, remm
- -1:
-
* Backport cleanup of semantics of thisAccessedTime and
lastAccessedTime for sessions:
- preparational whitespace changes
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=762507&r1=762506&r2=762507&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Mon
Apr 6 21:10:05 2009
@@ -86,10 +86,23 @@
response.setOutputBuffer(new SocketOutputBuffer());
request.setResponse(response);
+this.packetSize = packetSize;
requestHeaderMessage = new AjpMessage(packetSize);
responseHeaderMessage = new AjpMessage(packetSize);
bodyMessage = new AjpMessage(packetSize);
-
+
+// Set the get body message buffer
+AjpMessage getBodyMessage = new AjpMessage(16);
+getBodyMessage.reset();
+getBodyMessage.appendByte(Constants.JK_AJP13_GET_BODY_CHUNK);
+// Adjust allowed size if packetSize != default
(Constants.MAX_PACKET_SIZE)
+getBodyMessage.appendInt(Constants.MAX_READ_SIZE + packetSize -
Constants.MAX_PACKET_SIZE);
+getBodyMessage.end();
+getBodyMessageBuffer =
+ByteBuffer.allocateDirect(getBodyMessage.getLen());
+getBodyMessageBuffer.put(getBodyMessage.getBuffer(), 0,
+ getBodyMessage.getLen());
+
// Allocate input and output buffers
inputBuffer = ByteBuffer.allocateDirect(packetSize * 2);
inputBuffer.limit(0);
@@ -126,6 +139,12 @@
/**
+ * The socket timeout used when reading the first block of the request
+ * header.
+ */
+protected int packetSize;
+
+/**
* Header message. Note that this header is merely the one used during the
* processing of the first message of a "request", so it might not be a
request
* header. It will stay unchanged during the processing of the whole
request.
@@ -238,7 +257,7 @@
/**
* Direct buffer used for sending right away a get body message.
*/
-protected static final ByteBuffer getBodyMessageBuffer;
+protected final ByteBuffer getBodyMessageBuffer;
/**
@@ -263,17 +282,6 @@
static {
-// Set the get body message buffer
-AjpMessage getBodyMessage = new AjpMessage(16);
-getBodyMessage.reset();
-getBodyMessage.appendByte(Constants.JK_AJP13_GET_BODY_CHUNK);
-getBodyMessage.appendInt(Constants.MAX_READ_SIZE);
-getBodyMessage.end();
-getBodyMessageBuffer =
-ByteBuffer.allocateDirect(getBodyMessage.getLen());
-getBodyMessageBuffer.put(getBodyMessage.getBuffer(), 0,
-getBodyMessage.getLen());
-
// Set the read body message buffe
svn commit: r762504 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/jk/common/ChannelNioSocket.java java/org/apache/jk/common/ChannelSocket.java java/org/apache/jk/common/MsgAjp.java
Author: rjung
Date: Mon Apr 6 20:57:46 2009
New Revision: 762504
URL: http://svn.apache.org/viewvc?rev=762504&view=rev
Log:
Backport r757706: Use some already existing constants
instead of explicit numbers in the AJP connectors.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelSocket.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=762504&r1=762503&r2=762504&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Apr 6 20:57:46 2009
@@ -80,12 +80,6 @@
+1: markt, rjung
-1:
-* Use some already existing constants instead of explicit
- numbers in the AJP connectors. Backport of
- http://svn.apache.org/viewvc?rev=757706&view=rev
- +1: rjung, markt, billbarker
- -1:
-
* Allow huge request body packets for AJP13.
Part 2 of the backport proposed and approved above
(r697192), now also for the other AJP connectors.
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java?rev=762504&r1=762503&r2=762504&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelNioSocket.java Mon
Apr 6 20:57:46 2009
@@ -100,8 +100,8 @@
private int socketTimeout = 0;
private boolean nioIsBroken = false;
private Selector selector = null;
-private int bufferSize = 8*1024;
-private int packetSize = 8*1024;
+private int bufferSize = AjpConstants.MAX_PACKET_SIZE;
+private int packetSize = AjpConstants.MAX_PACKET_SIZE;
private long requestCount=0;
@@ -154,7 +154,7 @@
}
public void setBufferSize(int bs) {
-if(bs > 8*1024) {
+if(bs > AjpConstants.MAX_PACKET_SIZE) {
bufferSize = bs;
}
}
@@ -164,8 +164,8 @@
}
public void setPacketSize(int ps) {
-if(ps < 8*1024) {
-ps = 8*1024;
+if(ps < AjpConstants.MAX_PACKET_SIZE) {
+ps = AjpConstants.MAX_PACKET_SIZE;
}
packetSize = ps;
}
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelSocket.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelSocket.java?rev=762504&r1=762503&r2=762504&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelSocket.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/ChannelSocket.java Mon Apr
6 20:57:46 2009
@@ -89,7 +89,7 @@
private int linger=100;
private int socketTimeout;
private int bufferSize = -1;
-private int packetSize = 8*1024;
+private int packetSize = AjpConstants.MAX_PACKET_SIZE;
private long requestCount=0;
@@ -208,8 +208,8 @@
}
public void setPacketSize(int ps) {
-if(ps < 8*1024) {
-ps = 8*1024;
+if(ps < AjpConstants.MAX_PACKET_SIZE) {
+ps = AjpConstants.MAX_PACKET_SIZE;
}
packetSize = ps;
}
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java?rev=762504&r1=762503&r2=762504&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java Mon Apr 6
20:57:46 2009
@@ -63,8 +63,8 @@
* Constructor that takes a buffer size
*/
public MsgAjp(int bsize) {
-if(bsize < 8*1024) {
-bsize = 8*1024;
+if(bsize < AjpConstants.MAX_PACKET_SIZE) {
+bsize = AjpConstants.MAX_PACKET_SIZE;
}
bufsize = bsize;
buf = new byte[bsize];
@@ -76,7 +76,7 @@
* @deprecated Use the buffer size constructor.
*/
public MsgAjp() {
-this(8*1024);
+this(AjpConstants.MAX_PACKET_SIZE);
}
/**
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Proposition for a WebAppClassLoader enhancement : ExpendableClassLoader
[I'm re-sending this e-mail as I did not have any response. Maybe it
was because of html format ?]
Hello,
Among the many possible causes of classloader leaks, one is the
context class loader of threads spawned during the execution of web
applications.
For instance, if the following servlet is executed at least once and
it is the first time the Graphics2D part of the JRE is used for the
current JVM, then the web app's classloader will never be garbage-
collected.
public class MyTomcatServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse
response)
throws ServletException, IOException {
System.out.println("MyServlet.doGet : current CCL:"
+
Thread.currentThread().getContextClassLoader());
BufferedImage image = new BufferedImage(20, 20,
BufferedImage.TYPE_INT_RGB);
Graphics2D g = image.createGraphics();
response.setContentType("image/png");
OutputStream out = response.getOutputStream();
ImageIO.write(image, "png", out);
out.close();
out.flush();
g.dispose();
}
}
In order to work around such leaks, I created an
"ExpendableClassLoader", which will leak instead of the normal
WebAppClassLoader, But the former loads no class at all.
Here is the code :
/**
*
* A special ClassLoader to work around classloader (and thus
permgen) leaks
* caused by never-ending threads spawned during the execution of the
web app.
* If no care is taken, such threads have the webapp's classloader as
context
* classloader. So, if such a thread is still alive after the
application is
* undeployed, the application's classloader cannot be garbage-
collected.
*
*
* When the application is undeployed, the reference to the delegated
* classloader is nullified so that the latter can be garbage-collected
* (provided it is not held by other means).
*
*
* As of march 2009, there are several such "leaking" threads in
Sun's JRE
* library : Java2DDisposer {...@link see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540
}, LDAP connection pool manager... A very simple way
* of provoking such a leak is with the following servlet code :
*
*
* public class MyServlet extends HttpServlet {
*
* @Override
* protected void doGet(HttpServletRequest req, HttpServletResponse
response)
* throws ServletException, IOException {
* BufferedImage image = new BufferedImage(20, 20,
* BufferedImage.TYPE_INT_RGB);
* Graphics2D g = image.createGraphics();
* response.setContentType("image/png");
* OutputStream out = response.getOutputStream();
* ImageIO.write(image, "png", out);
* out.close();
* out.flush();
* g.dispose();
* }
* }
*
*
*
*
* By using this ExpendableClassLoader as the webapp's classloader
(and thus the
* context classloader), such dangling threads only keep a reference
to a very
* light classloader, drastically reducing the leak.
*
*
* NOTE: the class has to be in the same package as {...@link
WebappClassLoader} in
* order to override package-protected methods.
*
*
* @author Sylvain LAURENT
*
*/
public class ExpendableClassLoader extends WebappClassLoader {
private WebappClassLoader delegatedClassLoader;
public ExpendableClassLoader(ClassLoader parentClassLoader) {
delegatedClassLoader = new WebappClassLoader(parentClassLoader);
}
public void stop() throws LifecycleException {
ClassLoader savedParentClassLoader =
delegatedClassLoader.getParent();
delegatedClassLoader.stop();
// release reference to the delegated classloader, potentially
// sacrificing the current instance
delegatedClassLoader = null;
// recreate a delegated classloader, just in case a dangling
Thread
// (e.g. JDK threads like Java2Disposer) needs to load a class
// we use the same parent CL as the previous delegate
delegatedClassLoader = new
WebappClassLoader(savedParentClassLoader);
}
public String toString() {
return "ExpendableClassLoader@" + System.identityHashCode(this)
+ " delegates to " +
delegatedClassLoader.toString();
}
/* --- delegated methods - */
//skipped for brevity
}
I tested it with a small webapp and a custom context.xml to override
the default WebAppClassLoader and it does its job of avoiding this
type of mem
DO NOT REPLY [Bug 46976] New: tomcat 6 doesn't support configuration of domain parameter of generated session cookies
https://issues.apache.org/bugzilla/show_bug.cgi?id=46976 Summary: tomcat 6 doesn't support configuration of domain parameter of generated session cookies Product: Tomcat 6 Version: 6.0.18 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: b...@najdi.si Created an attachment (id=23449) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23449) This patch adds possibility to support for specifying domain parameter of generated session cookies. We needed subdomain session cookie support for our java webapp; currently there is no way to configure cookie domain attribute in tomcat <= 6.0.18. This patch adds this functionality. Cookie domain can be specified as Manager property (default null == turned off) in conf/context.xml or on per webapp context property (conf///appname.xml or META-INF/context.xml). --- snip --- --- snip --- Webapp will then issue session cookies in the following form: JSESSIONID=D29B85A0D5E3AADA7DAA2B8DE660B0B3; Domain=.example.org; Path=/ Browser will send this cookie to sites www.example.org, subsite.example.org, etc... This functionality is already implemented in Resin and Jetty. How to use/apply: svn co http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18 cd TOMCAT_6_0_18 patch -p0 < /path/to/tomcat-6.0.18-subdomain-session-cookie.patch ant download ant Best regards, Brane -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762500 - /tomcat/trunk/webapps/docs/changelog.xml
Author: rjung Date: Mon Apr 6 20:49:05 2009 New Revision: 762500 URL: http://svn.apache.org/viewvc?rev=762500&view=rev Log: Remove changlog entry backported from trunk to TC 6 in revision r762499. Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=762500&r1=762499&r2=762500&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Mon Apr 6 20:49:05 2009 @@ -102,10 +102,6 @@ - -45026: Never return an empty HTTP status response phrase. -mod_jk and httpd 2.x do not like that. (rjung) - Allow bigger AJP packets also for request bodies and responses using the packetSize attribute of the Connector. (rjung) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762499 - in /tomcat/tc6.0.x/trunk: STATUS.txt java/org/apache/coyote/ajp/AjpAprProcessor.java java/org/apache/coyote/ajp/AjpProcessor.java java/org/apache/jk/common/JkInputStream.java web
Author: rjung
Date: Mon Apr 6 20:47:04 2009
New Revision: 762499
URL: http://svn.apache.org/viewvc?rev=762499&view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
Never use empty reason phrase. Backport of
http://svn.apache.org/viewvc?rev=697183&view=rev
http://svn.apache.org/viewvc?rev=757721&view=rev
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=762499&r1=762498&r2=762499&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Apr 6 20:47:04 2009
@@ -38,12 +38,6 @@
0: remm (looks risky, very minor problem), fhanik - minor problem
-1:
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
- Never use empty reason phrase.
- http://svn.apache.org/viewvc?rev=697183&view=rev
- +1: rjung, mturk, markt, jim
- 0: remm (also affects to the two other AJP connectors)
-
* Allow huge request body packets for AJP13.
This was already applied to connectors, but never
carried forward to trunk and tc6.0.x.
@@ -99,14 +93,6 @@
+1: rjung, markt, remm
-1:
-* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45026
- Never use empty reason phrase.
- Part 2 of the backport proposed and approved above
- (r697183), now also for the other AJP connectors.
- http://svn.apache.org/viewvc?rev=757721&view=rev
- +1: rjung, markt, remm
- -1:
-
* Backport cleanup of semantics of thisAccessedTime and
lastAccessedTime for sessions:
- preparational whitespace changes
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=762499&r1=762498&r2=762499&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Mon
Apr 6 20:47:04 2009
@@ -944,6 +944,10 @@
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
+if (message == null) {
+// mod_jk + httpd 2.x fails with a null status message - bug 45026
+message = Integer.toString(response.getStatus());
+}
tmpMB.setString(message);
responseHeaderMessage.appendBytes(tmpMB);
Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?rev=762499&r1=762498&r2=762499&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Mon Apr
6 20:47:04 2009
@@ -950,6 +950,10 @@
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
+if (message == null) {
+// mod_jk + httpd 2.x fails with a null status message - bug 45026
+message = Integer.toString(response.getStatus());
+}
tmpMB.setString(message);
responseHeaderMessage.appendBytes(tmpMB);
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java?rev=762499&r1=762498&r2=762499&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/JkInputStream.java Mon Apr
6 20:47:04 2009
@@ -281,6 +281,10 @@
} else {
message = message.replace('\n', ' ').replace('\r', ' ');
}
+if (message == null) {
+// mod_jk + httpd 2.x fails with a null status message - bug 45026
+message = Integer.toString(res.getStatus());
+}
tempMB.setString( message );
c2b.convert( tempMB );
outputMsg.appendBytes(tempMB);
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=762499&r1=762498&r2=762499&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Mon Apr 6 20:47:04 2009
@@ -43,6 +43,10 @@
Re: svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
Hi Jean-Frederic, On 06.04.2009 18:40, jean-frederic clere wrote: > Rainer Jung wrote: >> On 06.04.2009 17:09, jfcl...@apache.org wrote: >>> Author: jfclere >>> +package org.apache.catalina.cluster; >> >> Should we really reuse this package name? Until TC 5.5 that was the old >> cluster, and the package name is still in use for the same classes in >> the oacc sandbox. > > Ok... What about backend? The thing might grow, so why don't we choose a sub package of org.apache.catalina.custer, like e.g. o.a.c.c.xxx with xxx e.g. - gauging - rating - measuring - measurement or depending on what the protocol will do in the future - heartbeat - detection The old cluster and oacc sandbox already use mcast and multicast as sub packages. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: New sandbox project -- Apache Commons (Portable) Runtime
On 06.04.2009 21:32, Niall Pemberton wrote: > Sounds good. Who currently works on the Tomcat code and are they happy > for it to come here as well. Very basic commit statistics on repos/asf/tomcat/connectors/trunk/jni, not including data about how big each of the commits was: Count id 391 mturk 77 jfclere 15 markt 11 rjung 6 pero 5 remm 4 jim 2 wrowe 1 costin I'm personally fine with moving the Java API for APR to commons and think it's a nice environment to grow the feature set. I'm cross-posting to d...@tomcat for the the other committers. > Also has there been any interest from > other project committers (you mention mina)? > > Niall > > On Sat, Apr 4, 2009 at 8:21 AM, Mladen Turk wrote: >> Hi all >> >> This is not official project manifest, just few things >> so I can gather info weather the project has any chance >> to settle in the commons at the first place. >> >> The project is completely different from other >> commons projects, because it contains platform native >> code beside java api. >> >> The idea is to evolve the Tomcat Native to a >> standalone component. It is used by Apache Tomcat >> and Apache Mina projects, so we have two TLP >> projects already using it. >> And my plan is to use this component inside >> daemons project for common platform tasks. >> >> The java part will also have a special native >> library dynamic runtime, allowing the native >> module(s) to exist in the same jar and gets >> extracted at runtime depending on the JVM platform >> with all internal native dependencies resolved, >> thus liberating the user from .dll hell. >> >> So, thumbs up or down to pursue this, or do I >> need to find a different settlement :) >> >> >> Regards >> -- >> ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r751136 - /tomcat/tc6.0.x/tags/TOMCAT_6_0_19/
Remy Maucherat wrote: > > The build is in the usual place in ~remm (built with a new computer, so > it's a good idea to test it) Looks good to me. TCKs and a couple of my local test cases all pass. Any plans to call a vote? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46967] ManagerBase.setRandomFile error handling fix
https://issues.apache.org/bugzilla/show_bug.cgi?id=46967 Tim changed: What|Removed |Added CC||tf...@sdsusa.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Help with a Tomcat bug.
Jason Smith wrote:
> Trying again. What's the trick to getting past the Apache spam filter
Generally, use plain text rather than html. Don't use attachments.
Mark
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 11:38 AM
> To: 'dev@tomcat.apache.org'
> Subject: RE: Help with a Tomcat bug.
>
> Trying again. Spam filter seems to hate me.
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 11:08 AM
> To: 'dev@tomcat.apache.org'
> Subject: RE: Help with a Tomcat bug.
>
> More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
> pull remaining bytes into the current buffer before switching.
>
> /**
> * End processing of current HTTP request.
> * Note: All bytes of the current request should have been already
> * consumed. This method only resets all the pointers so that we are ready
> * to parse the next HTTP request.
> */
> public void nextRequest()
> throws IOException {
>
> // Recycle Request object
> request.recycle();
>
> // Determine the header buffer used for next request
> byte[] newHeaderBuf = null;
> if (buf == headerBuffer1) {
> newHeaderBuf = headerBuffer2;
> } else {
> newHeaderBuf = headerBuffer1;
> }
>
> // Copy leftover bytes from buf to newHeaderBuf
> System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
> if(lastValid-pos > 0)
> {
>
> System.out.println("@");
> System.out.println("'" + new String(Arrays.copyOf(newHeaderBuf,
> lastValid - pos), "US-ASCII") + "'");
> }
>
> // Swap buffers
> buf = newHeaderBuf;
>
> // Recycle filters
> for (int i = 0; i <= lastActiveFilter; i++) {
> activeFilters[i].recycle();
> }
>
> // Reset pointers
> lastValid = lastValid - pos;
> pos = 0;
> lastActiveFilter = -1;
> parsingHeader = true;
> swallowInput = true;
>
> }
>
> I am seeing something like this at one point:
>
> @
> 'POST /dh/services/jmap/__exists__ HTTP/1.1
>
> But I am also seeing this where this problem is cropping up:
>
> @
> '0
>
> '
>
> Anyone got any ideas on how to fix this? Data from one POST is being carried
> over to the next POST!
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 10:16 AM
> To: 'dev@tomcat.apache.org'
> Subject: Help with a Tomcat bug.
>
> When using .setChunkedStreamingMode(...) from the client, I was getting back
> an invalid method name in my servlet. Specifically, in the overridden
> service() method, the request.getMethod() was returning '0\n\nPOST'.
>
> I've tracked this all the way into
> org.apache.coyote.http11.InternalInputBuffer.
>
> In .parseRequestLine, the first thing it does is consume leading CRs and LFs.
> Well, the first line I am getting is '0\n'. So it won't consume that line.
>
> The next step parses to the next SPACE character. So it picks up the 0, the
> CRs and LFs, all the way to the end of POST.
>
> The bottom line is that at this point, in this method, the HTTP method name
> is already messed up.
>
> Should this be fixed in this method, or is there a better place?
>
> One quick fix:
>
> byte chr = 0;
> do {
>
> // Read new bytes if needed
> if (pos >= lastValid) {
> if (!fill())
> throw new EOFException(sm.getString("iib.eof.error"));
> }
>
> chr = buf[pos++];
>
> } while ((chr == Constants.CR) || (chr == Constants.LF) || (chr ==
> '0'));
>
>
> I simply check for the '0' character as well. This is a bit of a hack, but I
> don't know the code well enough to know if the leading '0' (which I believe
> is the last line from a previous chunked POST) is supposed to be there or not.
>
> Any help would be appreciated.
>
> Tomcat 5.5.27, Java 6u13.
>
> Jason Smith
> Software Engineer
> InfoTrust Group, Inc.
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Help with a Tomcat bug.
Trying again. What's the trick to getting past the Apache spam filter
From: Jason Smith
Sent: Monday, April 06, 2009 11:38 AM
To: 'dev@tomcat.apache.org'
Subject: RE: Help with a Tomcat bug.
Trying again. Spam filter seems to hate me.
From: Jason Smith
Sent: Monday, April 06, 2009 11:08 AM
To: 'dev@tomcat.apache.org'
Subject: RE: Help with a Tomcat bug.
More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
pull remaining bytes into the current buffer before switching.
/**
* End processing of current HTTP request.
* Note: All bytes of the current request should have been already
* consumed. This method only resets all the pointers so that we are ready
* to parse the next HTTP request.
*/
public void nextRequest()
throws IOException {
// Recycle Request object
request.recycle();
// Determine the header buffer used for next request
byte[] newHeaderBuf = null;
if (buf == headerBuffer1) {
newHeaderBuf = headerBuffer2;
} else {
newHeaderBuf = headerBuffer1;
}
// Copy leftover bytes from buf to newHeaderBuf
System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
if(lastValid-pos > 0)
{
System.out.println("@");
System.out.println("'" + new String(Arrays.copyOf(newHeaderBuf,
lastValid - pos), "US-ASCII") + "'");
}
// Swap buffers
buf = newHeaderBuf;
// Recycle filters
for (int i = 0; i <= lastActiveFilter; i++) {
activeFilters[i].recycle();
}
// Reset pointers
lastValid = lastValid - pos;
pos = 0;
lastActiveFilter = -1;
parsingHeader = true;
swallowInput = true;
}
I am seeing something like this at one point:
@
'POST /dh/services/jmap/__exists__ HTTP/1.1
But I am also seeing this where this problem is cropping up:
@
'0
'
Anyone got any ideas on how to fix this? Data from one POST is being carried
over to the next POST!
From: Jason Smith
Sent: Monday, April 06, 2009 10:16 AM
To: 'dev@tomcat.apache.org'
Subject: Help with a Tomcat bug.
When using .setChunkedStreamingMode(...) from the client, I was getting back an
invalid method name in my servlet. Specifically, in the overridden service()
method, the request.getMethod() was returning '0\n\nPOST'.
I've tracked this all the way into
org.apache.coyote.http11.InternalInputBuffer.
In .parseRequestLine, the first thing it does is consume leading CRs and LFs.
Well, the first line I am getting is '0\n'. So it won't consume that line.
The next step parses to the next SPACE character. So it picks up the 0, the
CRs and LFs, all the way to the end of POST.
The bottom line is that at this point, in this method, the HTTP method name is
already messed up.
Should this be fixed in this method, or is there a better place?
One quick fix:
byte chr = 0;
do {
// Read new bytes if needed
if (pos >= lastValid) {
if (!fill())
throw new EOFException(sm.getString("iib.eof.error"));
}
chr = buf[pos++];
} while ((chr == Constants.CR) || (chr == Constants.LF) || (chr ==
'0'));
I simply check for the '0' character as well. This is a bit of a hack, but I
don't know the code well enough to know if the leading '0' (which I believe is
the last line from a previous chunked POST) is supposed to be there or not.
Any help would be appreciated.
Tomcat 5.5.27, Java 6u13.
Jason Smith
Software Engineer
InfoTrust Group, Inc.
RE: Help with a Tomcat bug.
Thanks, but I think I finally got it. 4th or 5th try.
Anyway, it looks like the InternalInputBuffer.nextRequest() is designed to pull
data forward to the next buffer. See code excerpt below. But it also looks
like it makes the assumption that all bytes have been consumed when this is
called. That isn't happening for me when I'm using chunking. The ending '0'
is hanging around and ends up on the method name ('POST') of the next request
that uses the buffer.
Can anyone help shed some light on this? I'm having a hard time figuring out
who is consuming the body, and if it is their responsibility to eat the last
'0' in the chunked data stream.
Thanks!
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Monday, April 06, 2009 11:42 AM
To: Tomcat Developers List
Subject: Re: Help with a Tomcat bug.
Jason Smith wrote:
> Trying again. What's the trick to getting past the Apache spam filter
Generally, use plain text rather than html. Don't use attachments.
Mark
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 11:38 AM
> To: 'dev@tomcat.apache.org'
> Subject: RE: Help with a Tomcat bug.
>
> Trying again. Spam filter seems to hate me.
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 11:08 AM
> To: 'dev@tomcat.apache.org'
> Subject: RE: Help with a Tomcat bug.
>
> More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
> pull remaining bytes into the current buffer before switching.
>
> /**
> * End processing of current HTTP request.
> * Note: All bytes of the current request should have been already
> * consumed. This method only resets all the pointers so that we are ready
> * to parse the next HTTP request.
> */
> public void nextRequest()
> throws IOException {
>
> // Recycle Request object
> request.recycle();
>
> // Determine the header buffer used for next request
> byte[] newHeaderBuf = null;
> if (buf == headerBuffer1) {
> newHeaderBuf = headerBuffer2;
> } else {
> newHeaderBuf = headerBuffer1;
> }
>
> // Copy leftover bytes from buf to newHeaderBuf
> System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
> if(lastValid-pos > 0)
> {
>
> System.out.println("@");
> System.out.println("'" + new String(Arrays.copyOf(newHeaderBuf,
> lastValid - pos), "US-ASCII") + "'");
> }
>
> // Swap buffers
> buf = newHeaderBuf;
>
> // Recycle filters
> for (int i = 0; i <= lastActiveFilter; i++) {
> activeFilters[i].recycle();
> }
>
> // Reset pointers
> lastValid = lastValid - pos;
> pos = 0;
> lastActiveFilter = -1;
> parsingHeader = true;
> swallowInput = true;
>
> }
>
> I am seeing something like this at one point:
>
> @
> 'POST /dh/services/jmap/__exists__ HTTP/1.1
>
> But I am also seeing this where this problem is cropping up:
>
> @
> '0
>
> '
>
> Anyone got any ideas on how to fix this? Data from one POST is being carried
> over to the next POST!
>
> From: Jason Smith
> Sent: Monday, April 06, 2009 10:16 AM
> To: 'dev@tomcat.apache.org'
> Subject: Help with a Tomcat bug.
>
> When using .setChunkedStreamingMode(...) from the client, I was getting back
> an invalid method name in my servlet. Specifically, in the overridden
> service() method, the request.getMethod() was returning '0\n\nPOST'.
>
> I've tracked this all the way into
> org.apache.coyote.http11.InternalInputBuffer.
>
> In .parseRequestLine, the first thing it does is consume leading CRs and LFs.
> Well, the first line I am getting is '0\n'. So it won't consume that line.
>
> The next step parses to the next SPACE character. So it picks up the 0, the
> CRs and LFs, all the way to the end of POST.
>
> The bottom line is that at this point, in this method, the HTTP method name
> is already messed up.
>
> Should this be fixed in this method, or is there a better place?
>
> One quick fix:
>
> byte chr = 0;
> do {
>
> // Read new bytes if needed
> if (pos >= lastValid) {
> if (!fill())
> throw new EOFException(sm.getString("iib.eof.error"));
> }
>
> chr = buf[pos++];
>
> } while ((chr == Constants.CR) || (chr == Constants.LF) || (chr ==
> '0'));
>
>
> I simply check for the '0' character as well. This is a bit of a hack, but I
> don't know the code well enough to know if the leading '0' (which I believe
> is the last line from a previous chunked POST) is supposed to be there or not.
>
> Any help would be appreciated.
>
> Tomcat 5.5.27, Java 6u13.
>
Re: Help with a Tomcat bug.
Jason Smith wrote:
> Thanks, but I think I finally got it. 4th or 5th try.
>
> Anyway, it looks like the InternalInputBuffer.nextRequest() is designed to
> pull data forward to the next buffer. See code excerpt below. But it also
> looks like it makes the assumption that all bytes have been consumed when
> this is called. That isn't happening for me when I'm using chunking. The
> ending '0' is hanging around and ends up on the method name ('POST') of the
> next request that uses the buffer.
>
> Can anyone help shed some light on this? I'm having a hard time figuring out
> who is consuming the body, and if it is their responsibility to eat the last
> '0' in the chunked data stream.
The users list is probably the best place to work this through. If you
reach the conclusion it is a Tomcat issue then create a bugzilla entry,
add a test case and someone will take a look.
Mark
>
> Thanks!
>
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Monday, April 06, 2009 11:42 AM
> To: Tomcat Developers List
> Subject: Re: Help with a Tomcat bug.
>
> Jason Smith wrote:
>> Trying again. What's the trick to getting past the Apache spam filter
>
> Generally, use plain text rather than html. Don't use attachments.
>
> Mark
>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 11:38 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: RE: Help with a Tomcat bug.
>>
>> Trying again. Spam filter seems to hate me.
>>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 11:08 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: RE: Help with a Tomcat bug.
>>
>> More info. In InternalInputBuffer.nextRequest(), I noticed there is code to
>> pull remaining bytes into the current buffer before switching.
>>
>> /**
>> * End processing of current HTTP request.
>> * Note: All bytes of the current request should have been already
>> * consumed. This method only resets all the pointers so that we are
>> ready
>> * to parse the next HTTP request.
>> */
>> public void nextRequest()
>> throws IOException {
>>
>> // Recycle Request object
>> request.recycle();
>>
>> // Determine the header buffer used for next request
>> byte[] newHeaderBuf = null;
>> if (buf == headerBuffer1) {
>> newHeaderBuf = headerBuffer2;
>> } else {
>> newHeaderBuf = headerBuffer1;
>> }
>>
>> // Copy leftover bytes from buf to newHeaderBuf
>> System.arraycopy(buf, pos, newHeaderBuf, 0, lastValid - pos);
>> if(lastValid-pos > 0)
>> {
>>
>> System.out.println("@");
>> System.out.println("'" + new String(Arrays.copyOf(newHeaderBuf,
>> lastValid - pos), "US-ASCII") + "'");
>> }
>>
>> // Swap buffers
>> buf = newHeaderBuf;
>>
>> // Recycle filters
>> for (int i = 0; i <= lastActiveFilter; i++) {
>> activeFilters[i].recycle();
>> }
>>
>> // Reset pointers
>> lastValid = lastValid - pos;
>> pos = 0;
>> lastActiveFilter = -1;
>> parsingHeader = true;
>> swallowInput = true;
>>
>> }
>>
>> I am seeing something like this at one point:
>>
>> @
>> 'POST /dh/services/jmap/__exists__ HTTP/1.1
>>
>> But I am also seeing this where this problem is cropping up:
>>
>> @
>> '0
>>
>> '
>>
>> Anyone got any ideas on how to fix this? Data from one POST is being
>> carried over to the next POST!
>>
>> From: Jason Smith
>> Sent: Monday, April 06, 2009 10:16 AM
>> To: 'dev@tomcat.apache.org'
>> Subject: Help with a Tomcat bug.
>>
>> When using .setChunkedStreamingMode(...) from the client, I was getting back
>> an invalid method name in my servlet. Specifically, in the overridden
>> service() method, the request.getMethod() was returning '0\n\nPOST'.
>>
>> I've tracked this all the way into
>> org.apache.coyote.http11.InternalInputBuffer.
>>
>> In .parseRequestLine, the first thing it does is consume leading CRs and
>> LFs. Well, the first line I am getting is '0\n'. So it won't consume that
>> line.
>>
>> The next step parses to the next SPACE character. So it picks up the 0, the
>> CRs and LFs, all the way to the end of POST.
>>
>> The bottom line is that at this point, in this method, the HTTP method name
>> is already messed up.
>>
>> Should this be fixed in this method, or is there a better place?
>>
>> One quick fix:
>>
>> byte chr = 0;
>> do {
>>
>> // Read new bytes if needed
>> if (pos >= lastValid) {
>> if (!fill())
>> throw new EOFException(sm.getString("iib.eof.error"));
>> }
>>
>> chr = buf[pos++];
>>
>> } while ((chr == Constants.CR) |
Re: svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
Rainer Jung wrote:
A few comments inline.
On 06.04.2009 17:09, jfcl...@apache.org wrote:
Author: jfclere
Date: Mon Apr 6 15:09:19 2009
New Revision: 762374
URL: http://svn.apache.org/viewvc?rev=762374&view=rev
Log:
First support for httpd-trunk heartbeat logic.
Added:
tomcat/trunk/java/org/apache/catalina/cluster/
tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=762374&r1=762373&r2=762374&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Mon Apr 6 15:09:19 2009
@@ -204,7 +204,6 @@
-
See below concerning the package name.
Added: tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java?rev=762374&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java (added)
+++ tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java Mon Apr 6
15:09:19 2009
...
+package org.apache.catalina.cluster;
Should we really reuse this package name? Until TC 5.5 that was the old
cluster, and the package name is still in use for the same classes in
the oacc sandbox.
Ok... What about backend?
+
+/* for MBean to read ready and busy */
+
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.ObjectInstance;
+import java.util.Enumeration;
+import java.util.Iterator;
+import java.util.Set;
+
+import org.apache.tomcat.util.modeler.Registry;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+
+/*
+ * Listener to provider informations to mod_heartbeat.c
+ * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
+ * send the muticast merssage using the format...
+ * what about the bind(IP. port) only IP makes sense (for the moment).
+ * BTW:v = version :-)
+ */
+public class CollectedInfo {
+
+/* Collect info via JMX */
+protected MBeanServer mBeanServer = null;
+protected ObjectName objName = null;
+
+int ready;
+int busy;
+
+public CollectedInfo(String host, int port) throws Exception {
+init(host, port);
+}
+public void init(String host, int port) throws Exception {
+String sport = Integer.toString(port);
+mBeanServer = Registry.getRegistry(null, null).getMBeanServer();
+String onStr = "*:type=ThreadPool,*";
Use a constant for this string?
+ObjectName objectName = new ObjectName(onStr);
+Set set = mBeanServer.queryMBeans(objectName, null);
+Iterator iterator = set.iterator();
+while (iterator.hasNext()) {
+ObjectInstance oi = iterator.next();
+objName = oi.getObjectName();
+String name = objName.getKeyProperty("name");
+/* Name are:
+ * http-8080
+ * jk-10.33.144.3-8009
+ * jk-jfcpc%2F10.33.144.3-8009
+ */
+if (port==0 && host==null)
+ break; /* Take the first one */
+String [] elenames = name.split("-");
+if (elenames[elenames.length-1].compareTo(sport) != 0)
+continue; /* port doesn't match */
+if (host==null)
+break; /* Only port done */
+String [] shosts = elenames[1].split("%2F");
+if (shosts[0].compareTo(host) == 0)
+break; /* Done port and host are the expected ones */
+}
+if (objName == null)
+throw(new Exception("Can't find connector for " + host + ":" +
sport));
+
+}
+
+public void refresh() throws Exception {
+if (mBeanServer == null || objName == null) {
+throw(new Exception("Not initialized!!!"));
+}
+Integer imax = (Integer) mBeanServer.getAttribute(objName,
"maxThreads");
+
+// the currentThreadCount could be 0 before the threads are created...
+// Integer iready = (Integer) mBeanServer.getAttribute(objName,
"currentThreadCount");
+
+Integer ibusy = (Integer) mBeanServer.getAttribute(objName,
"currentThreadsBusy");
+
+busy = ibusy.intValue();
+ready = imax.intValue() - ibusy;
+}
+}
Added: tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java?rev=762374&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java (added)
+++ tomcat/trunk/java/org/apache/catalina/cluster/H
svn commit: r762411 - /tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Author: jfclere
Date: Mon Apr 6 16:40:12 2009
New Revision: 762411
URL: http://svn.apache.org/viewvc?rev=762411&view=rev
Log:
Arrange the code according to Rainer's comments.
Modified:
tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Modified: tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java?rev=762411&r1=762410&r2=762411&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java Mon
Apr 6 16:40:12 2009
@@ -46,7 +46,7 @@
public class HeartbeatListener
implements LifecycleListener, ContainerListener {
-public static Log log = LogFactory.getLog(HeartbeatListener.class);
+private static Log log = LogFactory.getLog(HeartbeatListener.class);
/* To allow to select the connector */
int port = 0;
@@ -59,9 +59,14 @@
InetAddress group = null;
String ip = "224.0.1.105"; /* Multicast IP */
int multiport = 23364; /* Multicast Port */
+int ttl = 16;
public void setGroup(String ip) { this.ip = ip; }
+public String getGroup() { return ip; }
public void setMultiport(int multiport) { this.multiport = multiport; }
+public int getMultiport() { return multiport; }
+public void setTtl(int ttl) { this.ttl = ttl; }
+public int getTtl() { return ttl; }
private CollectedInfo coll = null;
@@ -83,10 +88,8 @@
return;
}
}
-// * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
-// v = version (1)
-// ready & ready are read from the scoreboard in httpd.
-// Endpoint ( getCurrentThreadsBusy ) ( getMaxThreads )
+
+/* Read busy and ready */
if (coll == null) {
try {
coll = new CollectedInfo(host, port);
@@ -116,7 +119,6 @@
s.send(data);
} catch (Exception ex) {
log.error("Unable to send colllected load information: " + ex);
-System.out.println(ex);
s.close();
s = null;
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PATCH]: configurable session cookie domain (subdomain session support)
Brane F. Grac(nar wrote: > Hello :) > > We needed subdomain session cookie support for our java webapp; currently > there is no way to configure cookie domain attribute in tomcat <= 6.0.18. > > This patch adds this functionality. Cookie domain can be specified as Manager > property (default null == turned off) in conf/context.xml or on per webapp > context property (conf///appname.xml or > META-INF/context.xml). Please create a bugzilla entry for this and attach the patch there so it doesn't get lost. To keep this consistent with httpOnly, this should be configured at the Context level rather than the manager. It would also be a good idea to include an update to the documentation in your patch. Mark > > --- snip --- > > > > --- snip --- > > Webapp will then issue session cookies in the following form: > > JSESSIONID=D29B85A0D5E3AADA7DAA2B8DE660B0B3; Domain=.example.org; Path=/ > > Browser will send this cookie to sites www.example.org, subsite.example.org, > etc... > > This functionality is already implemented in Resin and Jetty. > > How to use/apply: > svn co http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18 > cd TOMCAT_6_0_18 > patch -p0 < /path/to/tomcat-6.0.18-subdomain-session-cookie.patch > ant download > ant > > Best regards, Brane > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
A few comments inline.
On 06.04.2009 17:09, jfcl...@apache.org wrote:
> Author: jfclere
> Date: Mon Apr 6 15:09:19 2009
> New Revision: 762374
>
> URL: http://svn.apache.org/viewvc?rev=762374&view=rev
> Log:
> First support for httpd-trunk heartbeat logic.
>
> Added:
> tomcat/trunk/java/org/apache/catalina/cluster/
> tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
> tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
> Modified:
> tomcat/trunk/build.xml
>
> Modified: tomcat/trunk/build.xml
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=762374&r1=762373&r2=762374&view=diff
> ==
> --- tomcat/trunk/build.xml (original)
> +++ tomcat/trunk/build.xml Mon Apr 6 15:09:19 2009
> @@ -204,7 +204,6 @@
>
>
>
> -
>
>
>
See below concerning the package name.
> Added: tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java?rev=762374&view=auto
> ==
> --- tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java (added)
> +++ tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java Mon Apr
> 6 15:09:19 2009
...
> +package org.apache.catalina.cluster;
Should we really reuse this package name? Until TC 5.5 that was the old
cluster, and the package name is still in use for the same classes in
the oacc sandbox.
> +
> +/* for MBean to read ready and busy */
> +
> +import javax.management.MBeanServer;
> +import javax.management.ObjectName;
> +import javax.management.ObjectInstance;
> +import java.util.Enumeration;
> +import java.util.Iterator;
> +import java.util.Set;
> +
> +import org.apache.tomcat.util.modeler.Registry;
> +import org.apache.juli.logging.Log;
> +import org.apache.juli.logging.LogFactory;
> +
> +/*
> + * Listener to provider informations to mod_heartbeat.c
> + * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
> + * send the muticast merssage using the format...
> + * what about the bind(IP. port) only IP makes sense (for the moment).
> + * BTW:v = version :-)
> + */
> +public class CollectedInfo {
> +
> +/* Collect info via JMX */
> +protected MBeanServer mBeanServer = null;
> +protected ObjectName objName = null;
> +
> +int ready;
> +int busy;
> +
> +public CollectedInfo(String host, int port) throws Exception {
> +init(host, port);
> +}
> +public void init(String host, int port) throws Exception {
> +String sport = Integer.toString(port);
> +mBeanServer = Registry.getRegistry(null, null).getMBeanServer();
> +String onStr = "*:type=ThreadPool,*";
Use a constant for this string?
> +ObjectName objectName = new ObjectName(onStr);
> +Set set = mBeanServer.queryMBeans(objectName, null);
> +Iterator iterator = set.iterator();
> +while (iterator.hasNext()) {
> +ObjectInstance oi = iterator.next();
> +objName = oi.getObjectName();
> +String name = objName.getKeyProperty("name");
> +/* Name are:
> + * http-8080
> + * jk-10.33.144.3-8009
> + * jk-jfcpc%2F10.33.144.3-8009
> + */
> +if (port==0 && host==null)
> + break; /* Take the first one */
> +String [] elenames = name.split("-");
> +if (elenames[elenames.length-1].compareTo(sport) != 0)
> +continue; /* port doesn't match */
> +if (host==null)
> +break; /* Only port done */
> +String [] shosts = elenames[1].split("%2F");
> +if (shosts[0].compareTo(host) == 0)
> +break; /* Done port and host are the expected ones */
> +}
> +if (objName == null)
> +throw(new Exception("Can't find connector for " + host + ":" +
> sport));
> +
> +}
> +
> +public void refresh() throws Exception {
> +if (mBeanServer == null || objName == null) {
> +throw(new Exception("Not initialized!!!"));
> +}
> +Integer imax = (Integer) mBeanServer.getAttribute(objName,
> "maxThreads");
> +
> +// the currentThreadCount could be 0 before the threads are
> created...
> +// Integer iready = (Integer) mBeanServer.getAttribute(objName,
> "currentThreadCount");
> +
> +Integer ibusy = (Integer) mBeanServer.getAttribute(objName,
> "currentThreadsBusy");
> +
> +busy = ibusy.intValue();
> +ready = imax.intValue() - ibusy;
> +}
> +}
>
> Added: tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java?rev=762374&view=auto
> =
[PATCH]: configurable session cookie domain (subdomain session support)
Hello :)
We needed subdomain session cookie support for our java webapp; currently
there is no way to configure cookie domain attribute in tomcat <= 6.0.18.
This patch adds this functionality. Cookie domain can be specified as Manager
property (default null == turned off) in conf/context.xml or on per webapp
context property (conf///appname.xml or
META-INF/context.xml).
--- snip ---
--- snip ---
Webapp will then issue session cookies in the following form:
JSESSIONID=D29B85A0D5E3AADA7DAA2B8DE660B0B3; Domain=.example.org; Path=/
Browser will send this cookie to sites www.example.org, subsite.example.org,
etc...
This functionality is already implemented in Resin and Jetty.
How to use/apply:
svn co http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_18
cd TOMCAT_6_0_18
patch -p0 < /path/to/tomcat-6.0.18-subdomain-session-cookie.patch
ant download
ant
Best regards, Brane
Index: java/org/apache/catalina/Manager.java
===
--- java/org/apache/catalina/Manager.java (revision 762245)
+++ java/org/apache/catalina/Manager.java (working copy)
@@ -363,4 +363,17 @@
*/
public void backgroundProcess();
+
+ /**
+ * This method sets cookie domain for session cookies
+ *
+ * @param domain Cookie domain name (Use ".domain.tld" to issue
+ * subdomain valid session cookies)
+ */
+ public void setCookieDomain (String domain);
+
+ /**
+ * Returns cookie domain if set, otherwise null
+ */
+ public String getCookieDomain ();
}
Index: java/org/apache/catalina/session/ManagerBase.java
===
--- java/org/apache/catalina/session/ManagerBase.java (revision 762245)
+++ java/org/apache/catalina/session/ManagerBase.java (working copy)
@@ -197,7 +197,12 @@
*/
private int count = 0;
+/**
+ * Cookie domain for session cookies
+ */
+protected String cookieDomain = null;
+
/**
* Frequency of the session expiration, and related manager operations.
* Manager operations will be done once for the specified amount of
@@ -668,6 +673,34 @@
}
/**
+ * This method sets cookie domain for session cookies
+ *
+ * @param domain Cookie domain name (Use ".domain.tld" to issue
+ * subdomain valid session cookies)
+ */
+public void setCookieDomain (String domain) {
+ if (domain == null) {
+cookieDomain = null;
+return;
+}
+
+// sanitize && apply cookie domain string
+domain = domain.trim();
+if (domain.length() > 0) {
+cookieDomain = domain;
+} else {
+cookieDomain = null;
+}
+}
+
+/**
+ * Returns cookie domain if set, otherwise null
+ */
+public String getCookieDomain () {
+return cookieDomain;
+}
+
+/**
* Invalidate all sessions that have expired.
*/
public void processExpires() {
Index: java/org/apache/catalina/connector/Request.java
===
--- java/org/apache/catalina/connector/Request.java (revision 762245)
+++ java/org/apache/catalina/connector/Request.java (working copy)
@@ -2346,6 +2346,13 @@
} else {
cookie.setPath("/");
}
+
+// set cookie domain if manager is associated with cookie domain
+ String cookieDomain = context.getManager().getCookieDomain();
+ if (cookieDomain != null) {
+ cookie.setDomain(cookieDomain);
+ }
+
if (isSecure()) {
cookie.setSecure(true);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762374 - in /tomcat/trunk: build.xml java/org/apache/catalina/cluster/ java/org/apache/catalina/cluster/CollectedInfo.java java/org/apache/catalina/cluster/HeartbeatListener.java
Author: jfclere
Date: Mon Apr 6 15:09:19 2009
New Revision: 762374
URL: http://svn.apache.org/viewvc?rev=762374&view=rev
Log:
First support for httpd-trunk heartbeat logic.
Added:
tomcat/trunk/java/org/apache/catalina/cluster/
tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
tomcat/trunk/java/org/apache/catalina/cluster/HeartbeatListener.java
Modified:
tomcat/trunk/build.xml
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=762374&r1=762373&r2=762374&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Mon Apr 6 15:09:19 2009
@@ -204,7 +204,6 @@
-
Added: tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java?rev=762374&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java (added)
+++ tomcat/trunk/java/org/apache/catalina/cluster/CollectedInfo.java Mon Apr 6
15:09:19 2009
@@ -0,0 +1,99 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+
+package org.apache.catalina.cluster;
+
+/* for MBean to read ready and busy */
+
+import javax.management.MBeanServer;
+import javax.management.ObjectName;
+import javax.management.ObjectInstance;
+import java.util.Enumeration;
+import java.util.Iterator;
+import java.util.Set;
+
+import org.apache.tomcat.util.modeler.Registry;
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+
+/*
+ * Listener to provider informations to mod_heartbeat.c
+ * *msg_format = "v=%u&ready=%u&busy=%u"; (message to send).
+ * send the muticast merssage using the format...
+ * what about the bind(IP. port) only IP makes sense (for the moment).
+ * BTW:v = version :-)
+ */
+public class CollectedInfo {
+
+/* Collect info via JMX */
+protected MBeanServer mBeanServer = null;
+protected ObjectName objName = null;
+
+int ready;
+int busy;
+
+public CollectedInfo(String host, int port) throws Exception {
+init(host, port);
+}
+public void init(String host, int port) throws Exception {
+String sport = Integer.toString(port);
+mBeanServer = Registry.getRegistry(null, null).getMBeanServer();
+String onStr = "*:type=ThreadPool,*";
+ObjectName objectName = new ObjectName(onStr);
+Set set = mBeanServer.queryMBeans(objectName, null);
+Iterator iterator = set.iterator();
+while (iterator.hasNext()) {
+ObjectInstance oi = iterator.next();
+objName = oi.getObjectName();
+String name = objName.getKeyProperty("name");
+/* Name are:
+ * http-8080
+ * jk-10.33.144.3-8009
+ * jk-jfcpc%2F10.33.144.3-8009
+ */
+if (port==0 && host==null)
+ break; /* Take the first one */
+String [] elenames = name.split("-");
+if (elenames[elenames.length-1].compareTo(sport) != 0)
+continue; /* port doesn't match */
+if (host==null)
+break; /* Only port done */
+String [] shosts = elenames[1].split("%2F");
+if (shosts[0].compareTo(host) == 0)
+break; /* Done port and host are the expected ones */
+}
+if (objName == null)
+throw(new Exception("Can't find connector for " + host + ":" +
sport));
+
+}
+
+public void refresh() throws Exception {
+if (mBeanServer == null || objName == null) {
+throw(new Exception("Not initialized!!!"));
+}
+Integer imax = (Integer) mBeanServer.getAttribute(objName,
"maxThreads");
+
+// the currentThreadCount could be 0 before the threads are created...
+// Integer iready = (Integer) mBeanServer.getAttribute(objName,
"currentThreadCount");
+
+Integer ibusy = (Integer) mBeanServer.getAttribute(objName,
"currentThreadsBusy");
+
+busy = ibusy.intValue
DO NOT REPLY [Bug 34110] The message "SEVERE: Error listenerStart" should be more explicit
https://issues.apache.org/bugzilla/show_bug.cgi?id=34110 --- Comment #6 from Dan Armbrust 2009-04-06 07:58:11 PST --- This issue does not occur under Tomcat 6.0.18. I believe that Charles has the correct explanation for what is going on: http://marc.info/?l=tomcat-user&m=123889737632345&w=2 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
How to produce a Com et READ Event (Event Type.READ) from the client side?
Hello,
Recently I started to develop a web application
that is based on the Comet Architecture. After a lot of research, I realize
that there is a lack of documentation and tutorials about how to build simple
Comet
applications on Tomcat. The tomcat Advanced IO documentation previews the way
that the server handles the incoming different type events, but doesn’t explain
how to produce these events from the client side (ex. IE, Firefox). The
javascript snippet
below produces such an event.
function newConnection(){
xhr = new XMLHttpRequest();
xhr.open('GET','/comet' ,true);
xhr.send(null);
}
When I execute this function, a new event (EventType.Begin)
arrives on the CometServlet.
I am wondering if there is way to produce an (EventType.READ)
event from the client side.
Any suggestions?
Thanks in advance!
_
Drag n’ drop—Get easy photo sharing with Windows Live™ Photos.
http://www.microsoft.com/windows/windowslive/products/photos.aspx
DO NOT REPLY [Bug 46907] Jasper with log4j in web-app classpath and debug level enabled prevents reading HTTP POST stream from JSP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 IzhikovNikolay changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from IzhikovNikolay 2009-04-06 04:34:45 PST --- Can't reproduce bug with test application -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46907] Jasper with log4j in web-app classpath and debug level enabled prevents reading HTTP POST stream from JSP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 --- Comment #3 from IzhikovNikolay 2009-04-06 04:33:44 PST --- Created an attachment (id=23445) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23445) test application. I try to reproduce bug with it I can't reproduce problem with attached test application. I test it with tomcat builded from this url http://svn.apache.org/repos/asf/tomcat/current-svn15/tc5.5.x Can you provide test application and log file to reproduce problem -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters & Async Support in Servlet 3.0
Mark Thomas wrote: > Anas Ahmed wrote: > >> I wrote proposal for the second project "improve the JMX support within >> Apache Tomcat" >> i'm waiting for your feedback >> and i need your advice about which project i have to put my focus because >> i'm student and the time is valuable > > My suggestion (but it is only a suggestion) is that you focus on the JMX > proposal. And if you haven't seen, I have asked you for some additional information. You should be able to add it as a comment to your proposal. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 46907] Jasper with log4j in web-app classpath and debug level enabled prevents reading HTTP POST stream from JSP
https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 --- Comment #2 from IzhikovNikolay 2009-04-06 03:17:08 PST --- I will investigate this bug and fix it if I needed -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters & Async Support in Servlet 3.0
Anas Ahmed wrote: > I wrote proposal for the second project "improve the JMX support within > Apache Tomcat" > i'm waiting for your feedback > and i need your advice about which project i have to put my focus because i'm > student and the time is valuable My suggestion (but it is only a suggestion) is that you focus on the JMX proposal. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat newbie developer tasks?
NorthDragon NorthDragon wrote: > Hi, Mark. > I want to investigate and fix this bug > https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 > How I should inform on it? Create yourself a bugzilla account and then add comments to the bug report. Those comments are automatically sent to the dev list so everyone here will see them. When you have a patch the fixes the issue you can add the patch as an attachment. Mark > > >> Welcome back. >> >> These should be be a good place to get started: >> https://issues.apache.org/bugzilla/show_bug.cgi?id=46958 >> https://issues.apache.org/bugzilla/show_bug.cgi?id=46924 >> https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 >> >> Ask questions here, add patches to bugzilla and ping the list if you don't >> see >> any response to a proposed patch after a few days. >> >> Mark >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat newbie developer tasks?
Hi, Mark. I want to investigate and fix this bug https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 How I should inform on it? > Welcome back. > > These should be be a good place to get started: > https://issues.apache.org/bugzilla/show_bug.cgi?id=46958 > https://issues.apache.org/bugzilla/show_bug.cgi?id=46924 > https://issues.apache.org/bugzilla/show_bug.cgi?id=46907 > > Ask questions here, add patches to bugzilla and ping the list if you don't see > any response to a proposed patch after a few days. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r762258 - /tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java
Author: markt Date: Mon Apr 6 09:05:33 2009 New Revision: 762258 URL: http://svn.apache.org/viewvc?rev=762258&view=rev Log: Minor javadoc correction Modified: tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java Modified: tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java?rev=762258&r1=762257&r2=762258&view=diff == --- tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java (original) +++ tomcat/tc6.0.x/trunk/java/javax/servlet/ServletContext.java Mon Apr 6 09:05:33 2009 @@ -104,10 +104,10 @@ /** * Returns the minor version of the Servlet API that this * servlet container supports. All implementations that comply - * with Version 2.4 must have this method - * return the integer 4. + * with Version 2.5 must have this method + * return the integer 5. * - * @return 4 + * @return 5 * */ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [GSOC] Filters & Async Support in Servlet 3.0
Anas Ahmed wrote: Two Scenarios of thread per request :- 1- if the request send directly to server without filter:- When a connection is idle between requests, the thread can be recycled, and the connection is placed in a centralized NIO select set to detect new requests without consuming a separate thread. the new async behavior in Servlet 3.0 is not related to the underlying IO technology. It has nothing to do with NIO or blocking IO. We should be able to implement it using BIO without any issues, since its not IO bound. Filip 2- if the request chain to filter :- when a connection is idle between requests , the thread is still allocated to the particular request since the servlet 3.0 specification says :"A Filter and the target servlet or resource at the end of the filter chain must execute in the same invocation thread" It is look like thread per connection. if that is false what do you understand from this sentence :"A Filter and the target servlet or resource at the end of the filter chain must execute in the same invocation thread" ?? I wrote proposal for the second project "improve the JMX support within Apache Tomcat" i'm waiting for your feedback and i need your advice about which project i have to put my focus because i'm student and the time is valuable Anas _ Quick access to your favorite MSN content and Windows Live with Internet Explorer 8. http://ie8.msn.com/microsoft/internet-explorer-8/en-us/ie8.aspx?ocid=B037MSN55C0701A - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Proposal] Remove older of the two BIO AJP connectors
Very interesting thread. What's the needs in server / tc communications ? - new apis - new communication layer ajp is a not so bad protocol but the jk impl mix comm & marsh/unmarsh & api. we could find a persistant communication layer (openwire from activemq ?) we could define a set of apis (getLoad, forwardRequest) Then we should be able to glue both to a servlet engine like tomcat. Could we assemble existing components and attract external people ? I hope so, that was the idea behind my original post on this thread. I'm pretty sure we could collects ideas and needs here and after have a general idea of what should be done, how and where. Incubator is a good idea, so it won't just be (seen) as a new tomcat sub project or a nth attempt to rewrite mod_jk. Also it could be used by other servlet engines, more brains, more ideas. Openess is the key. Le 4 avr. 09 à 19:15, Costin Manolache a écrit : On Sat, Apr 4, 2009 at 9:30 AM, Mladen Turk wrote: Costin Manolache wrote: On Sat, Apr 4, 2009 at 9:03 AM, David Jencks wrote: My understanding of 'what we talk about' is what to do with mod_jk - deprecate/remove old code, add few features to better match current tomcat ( and current requirements - larger clusters, etc ). It seems there is some agreement that current AJP protocol won't work, but bigger disagreement on weather to just do nothing at all ( i.e. just maintain current code ), or do some small addition to AJP, use HTTP, etc. I got the impression that majority of people here wish to maintain the mod_jk. Rainer wishes to add few things in new 1.3 branch which is fine with me. The rest like Jean-Frederic said 'Won't happen' which I read, there is no man power here that would do something new. I agree there is no man power to implement a new protocol. But if we just use one - openwire or something similar - it may be much easier. Adding the dependency and getting it to build should be few hours/ days, then adding various handlers can be done very incrementally. If I read correctly Rainer's list, some improvements will be easier if he had a better/more extensible communication mechanism, load balancing in particular. I don't have a lot of time - certainly not for a new connector/ branch/etc, but I and others may find few hours if it would be easier - and I think a more extensible communication would do that. Changing existing code - without breaking backward compat - is pretty hard. I would love to make 'something new', but it obviously won't happen under Tomcat umbrella. Why not ? It seems well in scope. Costin Regards -- ^(TM) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
