[Tomcat Wiki] Update of "PoweredBy" by denisang
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "PoweredBy" page has been changed by denisang.
http://wiki.apache.org/tomcat/PoweredBy?action=diff&rev1=252&rev2=253
--
http://www.synetek.com uses Tomcat for their
[[http://www.leaseeagle.com|{{http://www.leaseeagle.com/images/logo.gif|http://www.leaseeagle.com}}]]
and
[[http://www.mailrevive.com|{{http://www.synetek.com/images/mr_logo_small_200wide.jpg|http://www.mailrevive.com}}]]
products.
=== Tixeo ===
-
[[http://www.tixeo.com|{{http://www.tixeo.com/images/Small_logo_tixeo.gif|http://www.tixeo.com}}]]
uses Tomcat for their
[[http://www.tixeo.com/meeting3DEn.php3|{{http://www.tixeo.com/images/Logomeeting3D.jpg|http://www.tixeo.com/meeting3DEn.php3}}]]
and
[[http://www.tixeo.com/WorkSpace3DEn.php3|{{http://www.tixeo.com/images/WorkSpace3D_Tr.gif|http://www.tixeo.com/WorkSpace3DEn.php3}}]]
products, solutions for [[http://www.tixeo.com|web conferencing]], video
conferencing, desktop sharing and realtime collaborative work in 3D.
+
[[http://www.tixeo.com|{{http://www.tixeo.com/images/Small_logo_tixeo2.gif|http://www.tixeo.com}}]]
uses Tomcat for their
[[http://www.tixeo.com/en/hosted-video-conferencing/WorkSpace3D-PE.htm|{{http://www.tixeo.com/images/products/Logo_WorkSpace3D_Transparen.png|http://www.tixeo.com/en/hosted-video-conferencing/WorkSpace3D-PE.htm}}]]
products, solutions for [[http://www.tixeo.com|web conferencing]], video
conferencing, desktop sharing and realtime collaborative work in 3D.
=== TeamDev ===
[[http://teamdev.com|{{http://teamdev.com/logo.gif|http://teamdev.com}}]]
uses Tomcat for own production systems and development services.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47242] request for AJP command line client
https://issues.apache.org/bugzilla/show_bug.cgi?id=47242 --- Comment #15 from chamith buddhika 2010-04-02 10:01:00 UTC --- Created an attachment (id=25223) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25223) AJPClient patch I have attached the related patch file. If possible some committer please have a look at it and make a comment. Anyway I am not sure where this should belong to in the code base if this is to be incorporated in to trunk subsequently. -- 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 47714] Reponse mixed between users
https://issues.apache.org/bugzilla/show_bug.cgi?id=47714 Konstantin Kolinko changed: What|Removed |Added Component|Library |mod_jk Version|1.1.0 |1.2.28 Product|Tomcat Native |Tomcat Connectors OS/Version|Windows 2000|Linux --- Comment #15 from Konstantin Kolinko 2010-04-02 10:06:38 UTC --- (In reply to comment #14) > # > # A fatal error has been detected by the Java Runtime Environment: > # I see that the above is also posted separately, as bug 49038. There is no explanation, how that is related to this issue, so I assume this is submitter's fault to post it here. He also changed Product/Component/Version/Platform for this issue. Please ignore comment #14, see bug 49038 if you want to follow it. I am resetting Product etc. to their previous values. -- 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 49038] Crash in tcnative
https://issues.apache.org/bugzilla/show_bug.cgi?id=49038 --- Comment #1 from Konstantin Kolinko 2010-04-02 10:17:07 UTC --- First question: what version of Tomcat-Native (tcnative-1.dll) you are using. Right-click on the tcnative-1.dll file, select "Properties". There should be "Version" tab in the file properties dialog. As you are using Tomcat 6.0.14, which is 2,5 years old, there are good chances that the issue that you are observing is fixed in a later version of Tomcat / TC-Native. Your stacktrace looks similar to the one in https://issues.apache.org/bugzilla/show_bug.cgi?id=42104#c0 -- 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: r930253 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: kkolinko Date: Fri Apr 2 12:12:06 2010 New Revision: 930253 URL: http://svn.apache.org/viewvc?rev=930253&view=rev Log: votes Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=930253&r1=930252&r2=930253&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Fri Apr 2 12:12:06 2010 @@ -130,7 +130,7 @@ PATCHES PROPOSED TO BACKPORT: session events http://svn.apache.org/viewvc?rev=928482&view=rev (apply to both cluster implementations) - +1: markt + +1: markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48840 @@ -150,5 +150,5 @@ PATCHES PROPOSED TO BACKPORT: Ensure web application class loader is used when calling session listeners http://svn.apache.org/viewvc?view=revision&revision=899138 http://svn.apache.org/viewvc?view=revision&revision=900131 - +1: kfujino + +1: kfujino, kkolinko -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r930270 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Fri Apr 2 13:42:30 2010 New Revision: 930270 URL: http://svn.apache.org/viewvc?rev=930270&view=rev Log: votes Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=930270&r1=930269&r2=930270&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 2 13:42:30 2010 @@ -242,14 +242,14 @@ PATCHES PROPOSED TO BACKPORT: the sessionCreated event is fired if the Manager is configured to replicate session events http://svn.apache.org/viewvc?rev=928482&view=rev - +1: markt + +1: markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48839 Correctly handle multi-line headers with the NIO connector Patch suggested by Richa Baronia http://svn.apache.org/viewvc?rev=928695&view=rev - +1: markt + +1: markt, kkolinko -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48840 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48843] Tomcat Acceptor Thread goes into wait() and it will never come back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 --- Comment #2 from Konstantin Kolinko 2010-04-02 13:59:46 UTC --- > This issue appears to only affect 6.0.x. The above phrase means only that it does not affect trunk. That is because Workers are not used there anymore. This issue does affect TC 5.5.x -- 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: r930284 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko
Date: Fri Apr 2 14:50:02 2010
New Revision: 930284
URL: http://svn.apache.org/viewvc?rev=930284&view=rev
Log:
votes
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=930284&r1=930283&r2=930284&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 2 14:50:02 2010
@@ -214,6 +214,11 @@ PATCHES PROPOSED TO BACKPORT:
http://people.apache.org/~markt/patches/2010-03-18-SslSessionTimeout.patch
+1: markt
-1:
+ kkolinko: In NioEndpoint (and in AbstractEndpoint in trunk) there is
+#setSessionCacheTimeout(String). It will need renaming as well?
+Generally, I would be against renaming some attributes, but this one
+is already documented as "sessionTimeout" in config/http.xml, though,
+still, renaming might break someone's configurations.
* Fix cluster regression, previous incorrect patch
http://svn.apache.org/viewvc?rev=924776&view=rev
@@ -269,21 +274,21 @@ PATCHES PROPOSED TO BACKPORT:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48862
Port pero's patch to add backlog to JK ChannelSocket
http://svn.apache.org/viewvc?view=revision&revision=493480
- +1: markt
+ +1: markt, kkolinko
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48895
Make clearing thread locals optional and disabled by default since it isn't
thread-safe
http://svn.apache.org/viewvc?rev=928798&view=rev
- +1: markt
+ +1: markt, kkolinko
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48917
Correct name of mod_jk module in ApacheConfig
https://issues.apache.org/bugzilla/attachment.cgi?id=25132
Patch provided by Todd Hicks
- +1: markt
+ +1: markt, kkolinko
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49030
@@ -292,3 +297,8 @@ PATCHES PROPOSED TO BACKPORT:
http://svn.apache.org/viewvc?rev=929521&view=rev
+1: markt
-1:
+ +0: kkolinko: good, but maybe we should also prevent against starting
+those connectors, that failed to initialize, in StandardService#start()?
+Also the message name (some generic name, "connector.failed"), vs.
+message text ("starting"), vs. what actually happened (initialize()) -
+I won't insist on fixing that inconsistency.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r930289 - /tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Author: fhanik
Date: Fri Apr 2 14:59:33 2010
New Revision: 930289
URL: http://svn.apache.org/viewvc?rev=930289&view=rev
Log:
Fix copy paste error
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=930289&r1=930288&r2=930289&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Apr 2
14:59:33 2010
@@ -5714,7 +5714,7 @@ public class StandardContext
"web application is running"
),
new MBeanNotificationInfo(new String[] {
- "j2ee.state.stopped"},
+ "j2ee.state.stopping"},
Notification.class.getName(),
"web application start to stopped"
),
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
On 04/01/2010 07:43 AM, Costin Manolache wrote:
+1 on switching to chunked by default.
can't you achieve this through a filter?
Filip
I don't think the extra few bytes are a problem ( or few extra
objects/cycles on server ) - at least compared with not knowing if the
response was really fully sent.
Costin
2010/4/1 Óscar Frías Barranco
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use when
the content-length cannot initially be determined. While it is mandatory
to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a
client
to distinguish a connection abort from a complete response in order to
avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections
with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody&& http11&& keepAlive) {
+if (entityBody&& http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem in NIOEndpoint
The NioX509KeyManager was added in so that you could force an alias to be used. Meaning, you have a keystore, and you want to use the attribute keyAlias="tomcat" in your connector, in 6.0.18, the NIO connector ignores it, and the JVM picks any key in your keystore, and this is not always what you want. You can open a bug in bugzilla, attach your configurations there and I can see why its not working for you. Filip On 03/31/2010 05:47 PM, Christopher Lee wrote: Tomcat version 6.0.26: There was a method introduced: NIOEndpoint#wrap (post 6.0.18) called from NIOEndpoint#init which wraps KeyManagers with NioX509KeyManager. I am not sure why (I could not get the JSSE source to fully debug) but when I run embedded Tomcat with SSL enabled and my own keystores I get the following exception: "javax.net.ssl. SSLHandshakeException: no cipher suites in common". Removing this wrapping will result in a working instance. This method is not present in 6.0.18. Please let me know if there is something I can do as a work around or if this actually causes a real bug. I wasn't sure where to post this. Please advise if you think I should post this elsewhere. Thanks, Chris. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
The HTTP spec says that when you close the connection, that is the
delimiter for the content.
Filip
On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use when
the content-length cannot initially be determined. While it is mandatory to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a client
to distinguish a connection abort from a complete response in order to avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody&& http11&& keepAlive) {
+if (entityBody&& http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
Ok, but it does not say that chunked encoding cannot be used when closing
the connection.
In fact chunked encoding takes precedence over connection close in the
determination of the transfer-length:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
Oscar
On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists wrote:
> The HTTP spec says that when you close the connection, that is the
> delimiter for the content.
>
> Filip
>
>
> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>
>> Hello.
>>
>> Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
>> if
>> keepalive is not used. This happens when an HTTP 1.1 request contains a
>> "Connection: close" header.
>> I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
>> keepalive is disabled.
>>
>> Chunked transfer-encoding is an alternative to content-length, for use
>> when
>> the content-length cannot initially be determined. While it is mandatory
>> to
>> have either of them to support keep-alive, its use is not restricted to
>> keep-alive and one useful immediate benefit of using it is to allow a
>> client
>> to distinguish a connection abort from a complete response in order to
>> avoid
>> storing truncated data.
>>
>> Another useful case is when a reverse-proxy is installed in front of the
>> server, and this reverse proxy tries to maintain keep-alive connections
>> with
>> the clients and intends to close the connections with the servers (like
>> apache 1.3, haproxy, and I think nginx). The lack of content-length and
>> chunked encoding prevents the proxy from keeping client connections alive.
>> The "connection: close" sent by the proxy to the server only indicates
>> that
>> the proxy will send just one request to the server, not that it does not
>> care about the response length. The same is true when that proxy caches.
>> Without any content-length nor chunked encoding, the cache could store and
>> distribute truncated response believing they are complete, while this
>> would
>> not happen with chunked encoding because the cache will be able to know it
>> has not seen the end of the response.
>>
>> The fix seems easy. This is the patch:
>>
>> Index: java/org/apache/coyote/http11/Http11Processor.java
>> ===
>> --- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
>> 18:09:50 CET 2010
>> +++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
>> 18:09:50 CET 2010
>> @@ -1547,7 +1547,7 @@
>> (outputFilters[Constants.IDENTITY_FILTER]);
>> contentDelimitation = true;
>> } else {
>> -if (entityBody&& http11&& keepAlive) {
>> +if (entityBody&& http11) {
>> outputBuffer.addActiveFilter
>> (outputFilters[Constants.CHUNKED_FILTER]);
>> contentDelimitation = true;
>>
>>
>> What do you think ?
>>
>> Regards,
>> Oscar Frias
>> Trabber.com
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
DO NOT REPLY [Bug 48843] Tomcat Acceptor Thread goes into wait() and it will never come back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 --- Comment #3 from Konstantin Kolinko 2010-04-02 15:41:21 UTC --- Created an attachment (id=25225) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25225) 2010-04-02_tc6_bug48843.patch -- 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: Chunked encoding should be used also when not using keepalive
so the spec says, use apples or oranges, we use oranges, and you want apples
my suggestion would be to write a filter and set the chunked header yourself
On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
Ok, but it does not say that chunked encoding cannot be used when closing
the connection.
In fact chunked encoding takes precedence over connection close in the
determination of the transfer-length:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
Oscar
On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Listswrote:
The HTTP spec says that when you close the connection, that is the
delimiter for the content.
Filip
On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use
when
the content-length cannot initially be determined. While it is mandatory
to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a
client
to distinguish a connection abort from a complete response in order to
avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections
with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections alive.
The "connection: close" sent by the proxy to the server only indicates
that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy caches.
Without any content-length nor chunked encoding, the cache could store and
distribute truncated response believing they are complete, while this
would
not happen with chunked encoding because the cache will be able to know it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody&& http11&& keepAlive) {
+if (entityBody&& http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
-
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
DO NOT REPLY [Bug 48843] Tomcat Acceptor Thread goes into wait() and it will never come back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 --- Comment #5 from Konstantin Kolinko 2010-04-02 15:58:04 UTC --- The above patches were proposed for 6.0 and 5.5. -- 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: r930303 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Fri Apr 2 15:56:12 2010 New Revision: 930303 URL: http://svn.apache.org/viewvc?rev=930303&view=rev Log: proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=930303&r1=930302&r2=930303&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Fri Apr 2 15:56:12 2010 @@ -269,8 +269,16 @@ PATCHES PROPOSED TO BACKPORT: Port deadlock prevention for worker allocation from NIO to BIO and APR http://people.apache.org/~markt/patches/2010-03-29-bug48843-tc6.patch +1: markt + +1: kkolinko: I will work, but I think that leaving/re-entering +synchronization when we are inside the loop is unneeded extra overhead. +Thus I am proposing another patch below. -1: + Alternative patch: + https://issues.apache.org/bugzilla/attachment.cgi?id=25225 + +1: kkolinko + -1: + * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48862 Port pero's patch to add backlog to JK ChannelSocket http://svn.apache.org/viewvc?view=revision&revision=493480 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Chunked encoding should be used also when not using keepalive
But as described in the thread using chunked encoding has 2 advantages:
- detection of truncated responses
- better interoperability with reverse proxies
And the only drawback is a slight increase in bytes and cpu cycles.
On Fri, Apr 2, 2010 at 17:46, Filip Hanik - Dev Lists wrote:
> so the spec says, use apples or oranges, we use oranges, and you want
> apples
>
> my suggestion would be to write a filter and set the chunked header
> yourself
>
>
> On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
>
>> Ok, but it does not say that chunked encoding cannot be used when closing
>> the connection.
>>
>> In fact chunked encoding takes precedence over connection close in the
>> determination of the transfer-length:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>>
>> Oscar
>>
>>
>> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists> >wrote:
>>
>>
>>
>>> The HTTP spec says that when you close the connection, that is the
>>> delimiter for the content.
>>>
>>> Filip
>>>
>>>
>>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>>
>>>
>>>
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even
if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use
when
the content-length cannot initially be determined. While it is
mandatory
to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a
client
to distinguish a connection abort from a complete response in order to
avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections
with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections
alive.
The "connection: close" sent by the proxy to the server only indicates
that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy
caches.
Without any content-length nor chunked encoding, the cache could store
and
distribute truncated response believing they are complete, while this
would
not happen with chunked encoding because the cache will be able to know
it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody&& http11&& keepAlive) {
+if (entityBody&& http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
>>>
>>> -
>>> 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: r930305 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: kkolinko Date: Fri Apr 2 15:57:29 2010 New Revision: 930305 URL: http://svn.apache.org/viewvc?rev=930305&view=rev Log: proposal Modified: tomcat/tc5.5.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=930305&r1=930304&r2=930305&view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Fri Apr 2 15:57:29 2010 @@ -146,9 +146,15 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=928732&view=rev -1: - * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47774 +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47774 Ensure web application class loader is used when calling session listeners http://svn.apache.org/viewvc?view=revision&revision=899138 http://svn.apache.org/viewvc?view=revision&revision=900131 +1: kfujino, kkolinko -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 + Prevent possible deadlock for worker allocation in APR + https://issues.apache.org/bugzilla/attachment.cgi?id=25226 + +1: kkolinko + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48843] Tomcat Acceptor Thread goes into wait() and it will never come back
https://issues.apache.org/bugzilla/show_bug.cgi?id=48843 --- Comment #4 from Konstantin Kolinko 2010-04-02 15:51:29 UTC --- Created an attachment (id=25226) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25226) 2010-04-02_tc55_bug48843.patch -- 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 2010
Hi Mark, Thanks for the reply. Since I was hoping to put a proposal regarding the JMX idea I was wondering whether it would be viable if I have not satisfied with the criteria "not be accepting applications from a student unless they have already provided an acceptable patch for at least one and preferably more currently open, non-trivial bugzilla items (bugs or enhancements).". Currently I have done some work on an enhancement regarding a command line client for AJP. (https://issues.apache.org/bugzilla/show_bug.cgi?id=47242). I searched bugzilla for JMX related bugs or enhancements but couldn't find satisfactory issues on that front which hasn't been addressed already. I would like to know your comments on the above. Regards, Chamith
Re: Chunked encoding should be used also when not using keepalive
The question is what to use by default - yes, the spec allows you to use
either.
Closing the connection has the benefit of saving few bytes on network and
maybe few cycles on server.
Chunked has the benefit of better detecting failures - since a close could
happen for other reasons besides normal end. Seems like a good deal to me.
Costin
On Fri, Apr 2, 2010 at 8:46 AM, Filip Hanik - Dev Lists
wrote:
> so the spec says, use apples or oranges, we use oranges, and you want
> apples
>
> my suggestion would be to write a filter and set the chunked header
> yourself
>
>
> On 04/02/2010 09:25 AM, Óscar Frías Barranco wrote:
>
>> Ok, but it does not say that chunked encoding cannot be used when closing
>> the connection.
>>
>> In fact chunked encoding takes precedence over connection close in the
>> determination of the transfer-length:
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4
>>
>> Oscar
>>
>>
>> On Fri, Apr 2, 2010 at 17:09, Filip Hanik - Dev Lists> >wrote:
>>
>>
>>
>>> The HTTP spec says that when you close the connection, that is the
>>> delimiter for the content.
>>>
>>> Filip
>>>
>>>
>>> On 04/01/2010 04:02 AM, Óscar Frías Barranco wrote:
>>>
>>>
>>>
Hello.
Currently Tomcat HTTP 1.1 Connector disables the use of chunked encoding
if
keepalive is not used. This happens when an HTTP 1.1 request contains a
"Connection: close" header.
I propose to change Coyote to use chunked encoding (for HTTP 1.1) even
if
keepalive is disabled.
Chunked transfer-encoding is an alternative to content-length, for use
when
the content-length cannot initially be determined. While it is
mandatory
to
have either of them to support keep-alive, its use is not restricted to
keep-alive and one useful immediate benefit of using it is to allow a
client
to distinguish a connection abort from a complete response in order to
avoid
storing truncated data.
Another useful case is when a reverse-proxy is installed in front of the
server, and this reverse proxy tries to maintain keep-alive connections
with
the clients and intends to close the connections with the servers (like
apache 1.3, haproxy, and I think nginx). The lack of content-length and
chunked encoding prevents the proxy from keeping client connections
alive.
The "connection: close" sent by the proxy to the server only indicates
that
the proxy will send just one request to the server, not that it does not
care about the response length. The same is true when that proxy
caches.
Without any content-length nor chunked encoding, the cache could store
and
distribute truncated response believing they are complete, while this
would
not happen with chunked encoding because the cache will be able to know
it
has not seen the end of the response.
The fix seems easy. This is the patch:
Index: java/org/apache/coyote/http11/Http11Processor.java
===
--- java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
+++ java/org/apache/coyote/http11/Http11Processor.javaTue Mar 09
18:09:50 CET 2010
@@ -1547,7 +1547,7 @@
(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
} else {
-if (entityBody&& http11&& keepAlive) {
+if (entityBody&& http11) {
outputBuffer.addActiveFilter
(outputFilters[Constants.CHUNKED_FILTER]);
contentDelimitation = true;
What do you think ?
Regards,
Oscar Frias
Trabber.com
>>>
>>> -
>>> 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: GSOC 2010
On 02/04/2010 17:33, buddhika chamith wrote: Hi Mark, Thanks for the reply. Since I was hoping to put a proposal regarding the JMX idea I was wondering whether it would be viable if I have not satisfied with the criteria "not be accepting applications from a student unless they have already provided an acceptable patch for at least one and preferably more currently open, non-trivial bugzilla items (bugs or enhancements).". Currently I have done some work on an enhancement regarding a command line client for AJP. (https://issues.apache.org/bugzilla/show_bug.cgi?id=47242). I searched bugzilla for JMX related bugs or enhancements but couldn't find satisfactory issues on that front which hasn't been addressed already. I would like to know your comments on the above. My thoughts are that there is plenty that needs fixing with the the JMX implementation - hence the GSoC project. Providing quality patches for some of those issues would be an advantage for anyone looking to apply for that project. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem in NIOEndpoint
Thanks Filip there is no bug as it turns out the alias name set was wrong. -Chris. On Fri, Apr 2, 2010 at 8:09 AM, Filip Hanik - Dev Lists wrote: > The NioX509KeyManager was added in so that you could force an alias to be > used. Meaning, you have a keystore, and you want to use the attribute > > keyAlias="tomcat" > > in your connector, in 6.0.18, the NIO connector ignores it, and the JVM > picks any key in your keystore, and this is not always what you want. > > You can open a bug in bugzilla, attach your configurations there and I can > see why its not working for you. > Filip > > > On 03/31/2010 05:47 PM, Christopher Lee wrote: > >> Tomcat version 6.0.26: >> >> There was a method introduced: NIOEndpoint#wrap (post 6.0.18) called from >> NIOEndpoint#init which wraps KeyManagers with NioX509KeyManager. >> I am not sure why (I could not get the JSSE source to fully debug) but >> when >> I run embedded Tomcat with SSL enabled and my own keystores >> I get the following exception: "javax.net.ssl. >> SSLHandshakeException: no cipher suites in common". Removing this >> wrapping >> will result in >> a working instance. This method is not present in 6.0.18. Please let me >> know if there is something I can do as a work around or if >> this actually causes a real bug. >> >> I wasn't sure where to post this. Please advise if you think I should >> post >> this elsewhere. >> >> Thanks, >> Chris. >> >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[Tomcat Wiki] Update of "AmericanInsurance" by American Insurance
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "AmericanInsurance" page has been changed by AmericanInsurance. The comment on this change is: http://american-insuranceleads.com/";>Health Insurance Leads. http://wiki.apache.org/tomcat/AmericanInsurance -- New page: ##language:en AmericanInsurance Email: americaninsuranc...@yahoo.com ... CategoryHomepage - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "AmericanInsurance" by American Insurance
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "AmericanInsurance" page has been changed by AmericanInsurance. http://wiki.apache.org/tomcat/AmericanInsurance?action=diff&rev1=1&rev2=2 -- ##language:en AmericanInsurance - Email: americaninsuranc...@yahoo.com + Email: http://american-insuranceleads.com ... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "AmericanInsurance" by American Insurance
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "AmericanInsurance" page has been changed by AmericanInsurance. http://wiki.apache.org/tomcat/AmericanInsurance?action=diff&rev1=2&rev2=3 -- ##language:en - AmericanInsurance + Health Insurance Leads Email: http://american-insuranceleads.com ... - CategoryHomepage + http://american-insuranceleads.com/";>Health Insurance Leads - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "AmericanInsurance" by American Insurance
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "AmericanInsurance" page has been changed by AmericanInsurance. http://wiki.apache.org/tomcat/AmericanInsurance?action=diff&rev1=3&rev2=4 -- ... - http://american-insuranceleads.com/";>Health Insurance Leads - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
