You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Ognjen Blagojevic <og...@gmail.com> on 2015/05/01 01:47:54 UTC
Re: [VOTE] Release Apache Tomcat 8.0.22
On 29.4.2015 18:41, Mark Thomas wrote:
> The proposed 8.0.22 release is:
> [X] Broken - do not release
> [ ] Stable - go ahead and release as 8.0.22
Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.8.0_45 and
APR/native 1.1.33:
- Crawled all links (except /manager, /host-manager and
/examples/async*). No broken links found, except links to JavaDocs.
- Smoke tests of BIO, NIO, NIO2 and APR, with and without TLS. Only
NIO2+TLS fails.
Connector configuration:
<Connector port="449"
protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS"
keystoreFile="(snip).p12" keyAlias="(snip)"
keystoreType="pkcs12" />
I smoke tested with this crawler:
https://bz.apache.org/bugzilla/attachment.cgi?id=31184
I get in the logs some of those:
01-May-2015 01:29:59.631 SEVERE [http-apr-83-exec-7]
org.apache.coyote.http11.AbstractHttp11Processor.endRequest Error
finishing response
org.apache.tomcat.jni.Error: 20005: An invalid socket was returned
at org.apache.tomcat.jni.Socket.sendbb(Native Method)
at
org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:287)
at
org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:244)
at
org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:213)
at
org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:378)
at
org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1800)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1143)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463)
at
org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
And a lot of those:
01-May-2015 01:29:59.625 WARNING [http-nio2-84-exec-6]
org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
Incorrect connection count, multiple socket.close called on the same socket.
01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-4]
org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
Incorrect connection count, multiple socket.close called on the same socket.
01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-1]
org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
Incorrect connection count, multiple socket.close called on the same socket.
I probably won't be able to do any more tests before Monday.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 1. Mai 2015 15:19:44 MESZ, schrieb Mark Thomas <ma...@apache.org>:
>On 01/05/2015 14:07, Felix Schumacher wrote:
>> Am 01.05.2015 um 14:53 schrieb Mark Thomas:
>>> On 01/05/2015 13:07, Felix Schumacher wrote:
>
><snip/>
>
>>>> * NIO2 seems to run OK at first, but after a while (last test the
>>>> "while" ended after 17900 requests) jmeters threads will not get a
>>>> response from tomcat. The test will continue when the clients
>timeout
>>>> after 60 seconds.
>>>>
>>>> I see no errors in tomcat logs. The access logs show a time jump of
>one
>>>> minute:
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1"
>200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1"
>200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1"
>200
>>>> 11250 <--- JUMP
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1"
>200
>>>> 11250 <---
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1"
>200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1"
>200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1"
>200
>>>> 11250
>>>>
>>>> If I repeat the same tests with 8.0.21 the test will run without
>delay
>>>> (or timeout on jmeter side).
>>>>
>>>> Without encryption all connectors will complete the tests without
>delay
>>>> on 8.0.22.
>>> This looks to be the culprit:
>>> http://svn.apache.org/viewvc?view=revision&revision=1672626
>> Looks to be OK, when I revert that patch on the 8.0.22. NIO2 with TLS
>> completes without delay.
>
>That patch looks to be addressing multiple issues. Are you able to
>figure out which part of the patch is causing the problem? (It may
>require some reverse engineering to figure out which part of the patch
>is addressing which issue.)
I can take a look tomorrow.
Felix
>
>Mark
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 07.05.2015 um 16:32 schrieb Rémy Maucherat:
> 2015-05-03 12:32 GMT+02:00 Felix Schumacher <
> felix.schumacher@internetallee.de>:
>
>> The rest of the patch will not influence the jmeter test.
>>
>> Ping to get feedback on the fix, if possible.
Tested again on trunk and found no delays.
Felix
> Rémy
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-03 12:32 GMT+02:00 Felix Schumacher <
felix.schumacher@internetallee.de>:
> The rest of the patch will not influence the jmeter test.
>
> Ping to get feedback on the fix, if possible.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-05 2:32 GMT+02:00 Christopher Schultz <ch...@christopherschultz.net>
:
> Hmm... I thought that NIO2 was listed as "experimental" in Tomcat 8.0.x,
> but the configuration guide doesn't say anything to that effect.
>
> How much *more* broken in 8.0.22 is it than 8.0.21? I would say that
> failing spectacularly is better than failing in difficult-to-detect
> ways, so in that sense... is 8.0.22 an improvement over 8.0.21?
>
> Is it no longer experimental since 8.0.9, since there weren't enough bugs
reported. The major fix since then has been on sendfile [the initial
algorithm was wrong]. SSL is less used so issues are found later.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 5/4/15 3:58 PM, Mark Thomas wrote:
> On 04/05/2015 19:49, Ognjen Blagojevic wrote:
>> On 3.5.2015 19:36, Rémy Maucherat wrote:
>>> 2015-05-03 18:28 GMT+02:00 Felix Schumacher <
>>> felix.schumacher@internetallee.de>:
>>>
>>>> In my test case position() will be either 0 or 341 (complete request).
>>>> They seem to happen at about the same rate.
>
> Felix,
>
> Thanks for tracking this down.
>
>>>> r1672626 fixed a loop issue, but oversimplified. So I am going back
>>>> to the
>>> previous code, with an added fix to resolve the loop, and hopefully it
>>> will
>>> be fine now.
>>>
>>> Since there's something wrong in both cases, it's not really a regression
>>> and I doubt it is worth doing a new build for this.
>
> I agree 8.0.21 and 8.0.22 are both broken to some extent for NIO2 + TLS.
>
>> I repeated my smoke/stress tests against latest 8.0.x/trunk (r1677647),
>> and all connectors pass them, with and without TLS.
>>
>> I still get NIO2 warnings and APR 20005 errors in the log, as I reported
>> earlier, but everything else seems Ok. They seem to be unrelated to the
>> NIO2+TLS failure I reported with 8.0.22.
>>
>> Same warnings and errors exists with 8.0.21.
>>
>> I wouldn't say that 8.0.22 is not a regression compared to 8.0.21, as
>> 8.0.21 passes my tests, 8.0.x/trunk also passes them, but 8.0.22 does
>> not pass them.
>
> They are both broken, it is just more obvious with 8.0.22. I'll make my
> mind up finally tomorrow but I am leaning towards releasing 8.0.22
> making it clear that there is a known issue with NIO2 + TLS and then
> looking at 8.0.23 almost immediately (I want to look at BZ 57802 first).
+1 to release 8.0.22 as-is.
Hmm... I thought that NIO2 was listed as "experimental" in Tomcat 8.0.x,
but the configuration guide doesn't say anything to that effect.
How much *more* broken in 8.0.22 is it than 8.0.21? I would say that
failing spectacularly is better than failing in difficult-to-detect
ways, so in that sense... is 8.0.22 an improvement over 8.0.21?
-chris
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-04 21:58 GMT+02:00 Mark Thomas <ma...@apache.org>:
> They are both broken, it is just more obvious with 8.0.22. I'll make my
> mind up finally tomorrow but I am leaning towards releasing 8.0.22
> making it clear that there is a known issue with NIO2 + TLS and then
> looking at 8.0.23 almost immediately (I want to look at BZ 57802 first).
>
> Before a new tag, I would need to get test results for SSL of course.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Mark Thomas <ma...@apache.org>.
On 04/05/2015 19:49, Ognjen Blagojevic wrote:
> On 3.5.2015 19:36, Rémy Maucherat wrote:
>> 2015-05-03 18:28 GMT+02:00 Felix Schumacher <
>> felix.schumacher@internetallee.de>:
>>
>>> In my test case position() will be either 0 or 341 (complete request).
>>> They seem to happen at about the same rate.
Felix,
Thanks for tracking this down.
>>> r1672626 fixed a loop issue, but oversimplified. So I am going back
>>> to the
>> previous code, with an added fix to resolve the loop, and hopefully it
>> will
>> be fine now.
>>
>> Since there's something wrong in both cases, it's not really a regression
>> and I doubt it is worth doing a new build for this.
I agree 8.0.21 and 8.0.22 are both broken to some extent for NIO2 + TLS.
> I repeated my smoke/stress tests against latest 8.0.x/trunk (r1677647),
> and all connectors pass them, with and without TLS.
>
> I still get NIO2 warnings and APR 20005 errors in the log, as I reported
> earlier, but everything else seems Ok. They seem to be unrelated to the
> NIO2+TLS failure I reported with 8.0.22.
>
> Same warnings and errors exists with 8.0.21.
>
> I wouldn't say that 8.0.22 is not a regression compared to 8.0.21, as
> 8.0.21 passes my tests, 8.0.x/trunk also passes them, but 8.0.22 does
> not pass them.
They are both broken, it is just more obvious with 8.0.22. I'll make my
mind up finally tomorrow but I am leaning towards releasing 8.0.22
making it clear that there is a known issue with NIO2 + TLS and then
looking at 8.0.23 almost immediately (I want to look at BZ 57802 first).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Ognjen Blagojevic <og...@gmail.com>.
On 3.5.2015 19:36, Rémy Maucherat wrote:
> 2015-05-03 18:28 GMT+02:00 Felix Schumacher <
> felix.schumacher@internetallee.de>:
>
>> In my test case position() will be either 0 or 341 (complete request).
>> They seem to happen at about the same rate.
>>
>> r1672626 fixed a loop issue, but oversimplified. So I am going back to the
> previous code, with an added fix to resolve the loop, and hopefully it will
> be fine now.
>
> Since there's something wrong in both cases, it's not really a regression
> and I doubt it is worth doing a new build for this.
I repeated my smoke/stress tests against latest 8.0.x/trunk (r1677647),
and all connectors pass them, with and without TLS.
I still get NIO2 warnings and APR 20005 errors in the log, as I reported
earlier, but everything else seems Ok. They seem to be unrelated to the
NIO2+TLS failure I reported with 8.0.22.
Same warnings and errors exists with 8.0.21.
I wouldn't say that 8.0.22 is not a regression compared to 8.0.21, as
8.0.21 passes my tests, 8.0.x/trunk also passes them, but 8.0.22 does
not pass them.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-03 18:28 GMT+02:00 Felix Schumacher <
felix.schumacher@internetallee.de>:
> In my test case position() will be either 0 or 341 (complete request).
> They seem to happen at about the same rate.
>
> r1672626 fixed a loop issue, but oversimplified. So I am going back to the
previous code, with an added fix to resolve the loop, and hopefully it will
be fine now.
Since there's something wrong in both cases, it's not really a regression
and I doubt it is worth doing a new build for this.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 3. Mai 2015 16:53:55 MESZ, schrieb "Rémy Maucherat" <re...@apache.org>:
>2015-05-03 12:32 GMT+02:00 Felix Schumacher <
>felix.schumacher@internetallee.de>:
>
>> The problem apears to be caused by this part of the patch:
>>
>> diff --git a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
>> b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
>> index ba16492..bbc18b0 100644
>> --- a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
>> +++ b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
>> @@ -784,21 +753,15 @@ public class SecureNio2Channel extends
>Nio2Channel {
>> handler.completed(Integer.valueOf(-1), attachment);
>> return;
>> }
>> if (!handshakeComplete) {
>> throw new
>>
>IllegalStateException(sm.getString("channel.nio.ssl.incompleteHandshake"));
>> }
>>
>> if (readPending) {
>> throw new ReadPendingException();
>> } else {
>> readPending = true;
>> }
>> .
>> - ReadCompletionHandler<A> readCompletionHandler = new
>> ReadCompletionHandler<>(dst, handler);
>> - if (netInBuffer.position() > 0 ) {
>> -
>readCompletionHandler.completed(Integer.valueOf(netInBuffer.position()),
>> attachment);
>> } else {
>> - sc.read(netInBuffer, timeout, unit, attachment,
>> readCompletionHandler);
>> + sc.read(netInBuffer, timeout, unit, attachment, new
>> ReadCompletionHandler<>(dst, handler));
>> }
>> .
>> @Override
>>
>> The rest of the patch will not influence the jmeter test.
>>
>> I suppose then netInBuffer.position() > 0 really does happen, and the
>change was a bad idea. OTOH, I guess I added it for a reason
>originally,
>but I thought it was no longer needed. I'll add back the code and test
>again the testsuite.
In my test case position() will be either 0 or 341 (complete request). They seem to happen at about the same rate.
Felix
>
>Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Rémy Maucherat <re...@apache.org>.
2015-05-03 12:32 GMT+02:00 Felix Schumacher <
felix.schumacher@internetallee.de>:
> The problem apears to be caused by this part of the patch:
>
> diff --git a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
> b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
> index ba16492..bbc18b0 100644
> --- a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
> +++ b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
> @@ -784,21 +753,15 @@ public class SecureNio2Channel extends Nio2Channel {
> handler.completed(Integer.valueOf(-1), attachment);
> return;
> }
> if (!handshakeComplete) {
> throw new
> IllegalStateException(sm.getString("channel.nio.ssl.incompleteHandshake"));
> }
>
> if (readPending) {
> throw new ReadPendingException();
> } else {
> readPending = true;
> }
> .
> - ReadCompletionHandler<A> readCompletionHandler = new
> ReadCompletionHandler<>(dst, handler);
> - if (netInBuffer.position() > 0 ) {
> - readCompletionHandler.completed(Integer.valueOf(netInBuffer.position()),
> attachment);
> } else {
> - sc.read(netInBuffer, timeout, unit, attachment,
> readCompletionHandler);
> + sc.read(netInBuffer, timeout, unit, attachment, new
> ReadCompletionHandler<>(dst, handler));
> }
> .
> @Override
>
> The rest of the patch will not influence the jmeter test.
>
> I suppose then netInBuffer.position() > 0 really does happen, and the
change was a bad idea. OTOH, I guess I added it for a reason originally,
but I thought it was no longer needed. I'll add back the code and test
again the testsuite.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.05.2015 um 15:19 schrieb Mark Thomas:
> On 01/05/2015 14:07, Felix Schumacher wrote:
>> Am 01.05.2015 um 14:53 schrieb Mark Thomas:
>>> On 01/05/2015 13:07, Felix Schumacher wrote:
> <snip/>
>
>>>> * NIO2 seems to run OK at first, but after a while (last test the
>>>> "while" ended after 17900 requests) jmeters threads will not get a
>>>> response from tomcat. The test will continue when the clients timeout
>>>> after 60 seconds.
>>>>
>>>> I see no errors in tomcat logs. The access logs show a time jump of one
>>>> minute:
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>>> 11250 <--- JUMP
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>>> 11250 <---
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>>> 11250
>>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>>> 11250
>>>>
>>>> If I repeat the same tests with 8.0.21 the test will run without delay
>>>> (or timeout on jmeter side).
>>>>
>>>> Without encryption all connectors will complete the tests without delay
>>>> on 8.0.22.
>>> This looks to be the culprit:
>>> http://svn.apache.org/viewvc?view=revision&revision=1672626
>> Looks to be OK, when I revert that patch on the 8.0.22. NIO2 with TLS
>> completes without delay.
> That patch looks to be addressing multiple issues. Are you able to
> figure out which part of the patch is causing the problem? (It may
> require some reverse engineering to figure out which part of the patch
> is addressing which issue.)
The problem apears to be caused by this part of the patch:
diff --git a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
index ba16492..bbc18b0 100644
--- a/java/org/apache/tomcat/util/net/SecureNio2Channel.java
+++ b/java/org/apache/tomcat/util/net/SecureNio2Channel.java
@@ -784,21 +753,15 @@ public class SecureNio2Channel extends Nio2Channel {
handler.completed(Integer.valueOf(-1), attachment);
return;
}
if (!handshakeComplete) {
throw new
IllegalStateException(sm.getString("channel.nio.ssl.incompleteHandshake"));
}
if (readPending) {
throw new ReadPendingException();
} else {
readPending = true;
}
.
- ReadCompletionHandler<A> readCompletionHandler = new
ReadCompletionHandler<>(dst, handler);
- if (netInBuffer.position() > 0 ) {
-
readCompletionHandler.completed(Integer.valueOf(netInBuffer.position()),
attachment);
} else {
- sc.read(netInBuffer, timeout, unit, attachment,
readCompletionHandler);
+ sc.read(netInBuffer, timeout, unit, attachment, new
ReadCompletionHandler<>(dst, handler));
}
.
@Override
The rest of the patch will not influence the jmeter test.
Regards
Felix
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Mark Thomas <ma...@apache.org>.
On 01/05/2015 14:07, Felix Schumacher wrote:
> Am 01.05.2015 um 14:53 schrieb Mark Thomas:
>> On 01/05/2015 13:07, Felix Schumacher wrote:
<snip/>
>>> * NIO2 seems to run OK at first, but after a while (last test the
>>> "while" ended after 17900 requests) jmeters threads will not get a
>>> response from tomcat. The test will continue when the clients timeout
>>> after 60 seconds.
>>>
>>> I see no errors in tomcat logs. The access logs show a time jump of one
>>> minute:
>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>> 11250
>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>> 11250
>>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>>> 11250 <--- JUMP
>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>> 11250 <---
>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>> 11250
>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>> 11250
>>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>>> 11250
>>>
>>> If I repeat the same tests with 8.0.21 the test will run without delay
>>> (or timeout on jmeter side).
>>>
>>> Without encryption all connectors will complete the tests without delay
>>> on 8.0.22.
>> This looks to be the culprit:
>> http://svn.apache.org/viewvc?view=revision&revision=1672626
> Looks to be OK, when I revert that patch on the 8.0.22. NIO2 with TLS
> completes without delay.
That patch looks to be addressing multiple issues. Are you able to
figure out which part of the patch is causing the problem? (It may
require some reverse engineering to figure out which part of the patch
is addressing which issue.)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.05.2015 um 14:53 schrieb Mark Thomas:
> On 01/05/2015 13:07, Felix Schumacher wrote:
>> Am 01.05.2015 um 01:47 schrieb Ognjen Blagojevic:
>>> On 29.4.2015 18:41, Mark Thomas wrote:
>>>> The proposed 8.0.22 release is:
>>>> [X] Broken - do not release
>>>> [ ] Stable - go ahead and release as 8.0.22
>>> Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.8.0_45 and
>>> APR/native 1.1.33:
>>>
>>> - Crawled all links (except /manager, /host-manager and
>>> /examples/async*). No broken links found, except links to JavaDocs.
>>>
>>> - Smoke tests of BIO, NIO, NIO2 and APR, with and without TLS. Only
>>> NIO2+TLS fails.
>>>
>>> Connector configuration:
>>>
>>> <Connector port="449"
>>> protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true"
>>> maxThreads="150" scheme="https" secure="true"
>>> clientAuth="false" sslProtocol="TLS"
>>> keystoreFile="(snip).p12" keyAlias="(snip)"
>>> keystoreType="pkcs12" />
>>>
>>>
>>> I smoke tested with this crawler:
>>>
>>> https://bz.apache.org/bugzilla/attachment.cgi?id=31184
>>>
>>>
>>>
>>> I get in the logs some of those:
>>>
>>> 01-May-2015 01:29:59.631 SEVERE [http-apr-83-exec-7]
>>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest Error
>>> finishing response
>>> org.apache.tomcat.jni.Error: 20005: An invalid socket was returned
>>> at org.apache.tomcat.jni.Socket.sendbb(Native Method)
>>> at
>>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:287)
>>>
>>> at
>>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:244)
>>>
>>> at
>>> org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:213)
>>>
>>> at
>>> org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:378)
>>>
>>> at
>>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1800)
>>>
>>> at
>>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1143)
>>>
>>> at
>>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
>>>
>>> at
>>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463)
>>>
>>> at
>>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>
>>> at
>>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>>
>>> at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>> And a lot of those:
>>>
>>> 01-May-2015 01:29:59.625 WARNING [http-nio2-84-exec-6]
>>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>>> Incorrect connection count, multiple socket.close called on the same
>>> socket.
>>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-4]
>>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>>> Incorrect connection count, multiple socket.close called on the same
>>> socket.
>>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-1]
>>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>>> Incorrect connection count, multiple socket.close called on the same
>>> socket.
>>>
>>>
>>> I probably won't be able to do any more tests before Monday.
>> I have done some tests with jmeter. Calling the "home" page of tomcat
>> through TLS with the different connectors BIO, NIO and NIO2. Using 100
>> concurrent "clients" and letting each client repeat 1000 requests, I get
>> the following results:
>>
>> * NIO and BIO run without errors.
>>
>> * NIO2 seems to run OK at first, but after a while (last test the
>> "while" ended after 17900 requests) jmeters threads will not get a
>> response from tomcat. The test will continue when the clients timeout
>> after 60 seconds.
>>
>> I see no errors in tomcat logs. The access logs show a time jump of one
>> minute:
>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
>> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
>> 11250 <--- JUMP
>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
>> 11250 <---
>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
>> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
>>
>> If I repeat the same tests with 8.0.21 the test will run without delay
>> (or timeout on jmeter side).
>>
>> Without encryption all connectors will complete the tests without delay
>> on 8.0.22.
> This looks to be the culprit:
> http://svn.apache.org/viewvc?view=revision&revision=1672626
Looks to be OK, when I revert that patch on the 8.0.22. NIO2 with TLS
completes without delay.
Felix
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Mark Thomas <ma...@apache.org>.
On 01/05/2015 13:07, Felix Schumacher wrote:
> Am 01.05.2015 um 01:47 schrieb Ognjen Blagojevic:
>> On 29.4.2015 18:41, Mark Thomas wrote:
>>> The proposed 8.0.22 release is:
>>> [X] Broken - do not release
>>> [ ] Stable - go ahead and release as 8.0.22
>>
>> Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.8.0_45 and
>> APR/native 1.1.33:
>>
>> - Crawled all links (except /manager, /host-manager and
>> /examples/async*). No broken links found, except links to JavaDocs.
>>
>> - Smoke tests of BIO, NIO, NIO2 and APR, with and without TLS. Only
>> NIO2+TLS fails.
>>
>> Connector configuration:
>>
>> <Connector port="449"
>> protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true"
>> maxThreads="150" scheme="https" secure="true"
>> clientAuth="false" sslProtocol="TLS"
>> keystoreFile="(snip).p12" keyAlias="(snip)"
>> keystoreType="pkcs12" />
>>
>>
>> I smoke tested with this crawler:
>>
>> https://bz.apache.org/bugzilla/attachment.cgi?id=31184
>>
>>
>>
>> I get in the logs some of those:
>>
>> 01-May-2015 01:29:59.631 SEVERE [http-apr-83-exec-7]
>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest Error
>> finishing response
>> org.apache.tomcat.jni.Error: 20005: An invalid socket was returned
>> at org.apache.tomcat.jni.Socket.sendbb(Native Method)
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:287)
>>
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:244)
>>
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:213)
>>
>> at
>> org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:378)
>>
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1800)
>>
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1143)
>>
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>>
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> And a lot of those:
>>
>> 01-May-2015 01:29:59.625 WARNING [http-nio2-84-exec-6]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-4]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-1]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>>
>>
>> I probably won't be able to do any more tests before Monday.
>
> I have done some tests with jmeter. Calling the "home" page of tomcat
> through TLS with the different connectors BIO, NIO and NIO2. Using 100
> concurrent "clients" and letting each client repeat 1000 requests, I get
> the following results:
>
> * NIO and BIO run without errors.
>
> * NIO2 seems to run OK at first, but after a while (last test the
> "while" ended after 17900 requests) jmeters threads will not get a
> response from tomcat. The test will continue when the clients timeout
> after 60 seconds.
>
> I see no errors in tomcat logs. The access logs show a time jump of one
> minute:
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
> 11250 <--- JUMP
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
> 11250 <---
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
>
> If I repeat the same tests with 8.0.21 the test will run without delay
> (or timeout on jmeter side).
>
> Without encryption all connectors will complete the tests without delay
> on 8.0.22.
This looks to be the culprit:
http://svn.apache.org/viewvc?view=revision&revision=1672626
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.05.2015 um 14:07 schrieb Felix Schumacher:
> Am 01.05.2015 um 01:47 schrieb Ognjen Blagojevic:
>> On 29.4.2015 18:41, Mark Thomas wrote:
>>> The proposed 8.0.22 release is:
>>> [X] Broken - do not release
>>> [ ] Stable - go ahead and release as 8.0.22
>>
>> Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.8.0_45 and
>> APR/native 1.1.33:
>>
>> - Crawled all links (except /manager, /host-manager and
>> /examples/async*). No broken links found, except links to JavaDocs.
>>
>> - Smoke tests of BIO, NIO, NIO2 and APR, with and without TLS. Only
>> NIO2+TLS fails.
>>
>> Connector configuration:
>>
>> <Connector port="449"
>> protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true"
>> maxThreads="150" scheme="https" secure="true"
>> clientAuth="false" sslProtocol="TLS"
>> keystoreFile="(snip).p12" keyAlias="(snip)"
>> keystoreType="pkcs12" />
>>
>>
>> I smoke tested with this crawler:
>>
>> https://bz.apache.org/bugzilla/attachment.cgi?id=31184
>>
>>
>>
>> I get in the logs some of those:
>>
>> 01-May-2015 01:29:59.631 SEVERE [http-apr-83-exec-7]
>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest Error
>> finishing response
>> org.apache.tomcat.jni.Error: 20005: An invalid socket was returned
>> at org.apache.tomcat.jni.Socket.sendbb(Native Method)
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:287)
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:244)
>> at
>> org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:213)
>> at
>> org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:378)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1800)
>> at
>> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1143)
>> at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
>> at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463)
>> at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> at
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> And a lot of those:
>>
>> 01-May-2015 01:29:59.625 WARNING [http-nio2-84-exec-6]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-4]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-1]
>> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
>> Incorrect connection count, multiple socket.close called on the same
>> socket.
>>
>>
>> I probably won't be able to do any more tests before Monday.
>
> I have done some tests with jmeter. Calling the "home" page of tomcat
> through TLS with the different connectors BIO, NIO and NIO2. Using 100
> concurrent "clients" and letting each client repeat 1000 requests, I
> get the following results:
>
> * NIO and BIO run without errors.
>
> * NIO2 seems to run OK at first, but after a while (last test the
> "while" ended after 17900 requests) jmeters threads will not get a
> response from tomcat. The test will continue when the clients timeout
> after 60 seconds.
>
> I see no errors in tomcat logs. The access logs show a time jump of
> one minute:
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
> 11250
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
> 11250
> 192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
> 11250 <--- JUMP
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
> 11250 <---
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
> 11250
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
> 11250
> 192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
> 11250
>
> If I repeat the same tests with 8.0.21 the test will run without delay
> (or timeout on jmeter side).
>
> Without encryption all connectors will complete the tests without
> delay on 8.0.22.
A bit more information:
My tests were done on ubuntu 14.04 LTS with java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.5)
(7u79-2.5.5-0ubuntu0.14.04.2). The jmeter request sampler used
httphc4imp and keepalive. Without keepalive the pause will come earlier
(last test I did it came after about 1400 requests).
I try to attach the threaddumps for jmeter and tomcat to this mail, not
sure if they come through, so in a short:
jmeter mostly looks like this:
"Thread-Gruppe 1-100" prio=10 tid=0x00007f40cc094800 nid=0x3c79 runnable
[0x00007f4088124000]
java.lang.Thread.State: RUNNABLE
>-------at java.net.SocketInputStream.socketRead0(Native Method)
>-------at java.net.SocketInputStream.read(SocketInputStream.java:152)
>-------at java.net.SocketInputStream.read(SocketInputStream.java:122)
>-------at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
>-------at sun.security.ssl.InputRecord.read(InputRecord.java:480)
>-------at
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
>-------- locked <0x00000000f761a7d0> (a java.lang.Object)
>-------at
sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:891)
>-------at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
>-------- locked <0x00000000f763f940> (a sun.security.ssl.AppInputStream)
>-------at
org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
>-------at
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
>-------at
org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
>-------at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
>-------at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
>-------at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
>-------at
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
>-------at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
>-------at
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
>-------at
org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:201)
>-------at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
>-------at
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
and tomcat mostly looks like this:
"http-nio2-8449-exec-47" daemon prio=10 tid=0x00007faf20012800
nid=0x3968 waiting on condition [0x00007faedd8d7000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000c4263498> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:103)
at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:31)
at
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
... more http-nio2-8449-exec threads ...
"http-nio-8444-Acceptor-0" daemon prio=10 tid=0x00007faf605fb800
nid=0x38cc runnable [0x00007faf44c61000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at
sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:241)
- locked <0x00000000c44d4800> (a java.lang.Object)
at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:686)
at java.lang.Thread.run(Thread.java:745)
"http-nio-8444-ClientPoller-1" daemon prio=10 tid=0x00007faf605fa000
nid=0x38cb runnable [0x00007faf44d62000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x00000000c4ae16d0> (a sun.nio.ch.Util$2)
- locked <0x00000000c4ae16c0> (a
java.util.Collections$UnmodifiableSet)
- locked <0x00000000c4ae1588> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1049)
at java.lang.Thread.run(Thread.java:745)
"http-nio-8444-ClientPoller-0" daemon prio=10 tid=0x00007faf605eb000
nid=0x38ca runnable [0x00007faf44e63000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
- locked <0x00000000c4ae2da8> (a sun.nio.ch.Util$2)
- locked <0x00000000c4ae2d98> (a
java.util.Collections$UnmodifiableSet)
- locked <0x00000000c4ae2c60> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
at
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1049)
at java.lang.Thread.run(Thread.java:745)
"http-nio2-8449-AsyncTimeout" daemon prio=10 tid=0x00007faf605db800
nid=0x38c9 waiting on condition [0x00007faf44f64000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.tomcat.util.net.AbstractEndpoint$AsyncTimeout.run(AbstractEndpoint.java:129)
at java.lang.Thread.run(Thread.java:745)
"http-nio2-8449-Acceptor-0" daemon prio=10 tid=0x00007faf605d9800
nid=0x38c8 waiting on condition [0x00007faf45065000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f2b542f0> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
at sun.nio.ch.PendingFuture.get(PendingFuture.java:180)
at
org.apache.tomcat.util.net.Nio2Endpoint$Acceptor.run(Nio2Endpoint.java:698)
at java.lang.Thread.run(Thread.java:745)
Regards
Felix
>
> Regards
> Felix
>>
>> -Ognjen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: [VOTE] Release Apache Tomcat 8.0.22
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 01.05.2015 um 01:47 schrieb Ognjen Blagojevic:
> On 29.4.2015 18:41, Mark Thomas wrote:
>> The proposed 8.0.22 release is:
>> [X] Broken - do not release
>> [ ] Stable - go ahead and release as 8.0.22
>
> Tested .zip distribution on Windows 7 64-bit, Oracle JDK 1.8.0_45 and
> APR/native 1.1.33:
>
> - Crawled all links (except /manager, /host-manager and
> /examples/async*). No broken links found, except links to JavaDocs.
>
> - Smoke tests of BIO, NIO, NIO2 and APR, with and without TLS. Only
> NIO2+TLS fails.
>
> Connector configuration:
>
> <Connector port="449"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol" SSLEnabled="true"
> maxThreads="150" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"
> keystoreFile="(snip).p12" keyAlias="(snip)"
> keystoreType="pkcs12" />
>
>
> I smoke tested with this crawler:
>
> https://bz.apache.org/bugzilla/attachment.cgi?id=31184
>
>
>
> I get in the logs some of those:
>
> 01-May-2015 01:29:59.631 SEVERE [http-apr-83-exec-7]
> org.apache.coyote.http11.AbstractHttp11Processor.endRequest Error
> finishing response
> org.apache.tomcat.jni.Error: 20005: An invalid socket was returned
> at org.apache.tomcat.jni.Socket.sendbb(Native Method)
> at
> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:287)
> at
> org.apache.coyote.http11.InternalAprOutputBuffer.writeToSocket(InternalAprOutputBuffer.java:244)
> at
> org.apache.coyote.http11.InternalAprOutputBuffer.flushBuffer(InternalAprOutputBuffer.java:213)
> at
> org.apache.coyote.http11.AbstractOutputBuffer.endRequest(AbstractOutputBuffer.java:378)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.endRequest(AbstractHttp11Processor.java:1800)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1143)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:668)
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2463)
> at
> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2452)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.lang.Thread.run(Thread.java:745)
>
>
> And a lot of those:
>
> 01-May-2015 01:29:59.625 WARNING [http-nio2-84-exec-6]
> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
> Incorrect connection count, multiple socket.close called on the same
> socket.
> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-4]
> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
> Incorrect connection count, multiple socket.close called on the same
> socket.
> 01-May-2015 01:29:59.627 WARNING [http-nio2-84-exec-1]
> org.apache.tomcat.util.net.AbstractEndpoint.countDownConnection
> Incorrect connection count, multiple socket.close called on the same
> socket.
>
>
> I probably won't be able to do any more tests before Monday.
I have done some tests with jmeter. Calling the "home" page of tomcat
through TLS with the different connectors BIO, NIO and NIO2. Using 100
concurrent "clients" and letting each client repeat 1000 requests, I get
the following results:
* NIO and BIO run without errors.
* NIO2 seems to run OK at first, but after a while (last test the
"while" ended after 17900 requests) jmeters threads will not get a
response from tomcat. The test will continue when the clients timeout
after 60 seconds.
I see no errors in tomcat logs. The access logs show a time jump of one
minute:
192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200 11250
192.168.178.20 - - [01/May/2015:13:57:39 +0200] "GET / HTTP/1.1" 200
11250 <--- JUMP
192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200
11250 <---
192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
192.168.178.20 - - [01/May/2015:13:58:33 +0200] "GET / HTTP/1.1" 200 11250
If I repeat the same tests with 8.0.21 the test will run without delay
(or timeout on jmeter side).
Without encryption all connectors will complete the tests without delay
on 8.0.22.
Regards
Felix
>
> -Ognjen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org