tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: svn commit: r1173082 - in /tomcat/trunk: java/org/apache/coyote/http11/Http11NioProtocol.java test/org/apache/catalina/comet/TestCometProcessor.java
Date Thu, 22 Sep 2011 14:49:43 GMT
On 21.09.2011 20:17, Rainer Jung wrote:
> On 21.09.2011 12:44, Mark Thomas wrote:
>> On 21/09/2011 01:41, Konstantin Kolinko wrote:
>>> 2011/9/20 Mark Thomas <markt@apache.org>:
>>>> On 20/09/2011 13:41, Konstantin Kolinko wrote:
>>>>>
>>>>> BTW: I am unable to reproduce Gump failure for TestCometProcessor with
NIO
>>>>> (running with JDK 6u26/WinXP),
>>>>> but this test fails for me when running it with APR connector.
>>>>
>>>> I *think* I have all these issues fixed now. The unit tests pass for me
>>>> on Linux and Windows. We'll find out tomorrow if Gump is happy now. If
>>>> you could test APR as well that would be great.
>>
>> Thanks for the test results.
>>
>>> Running trunk @r1173433,
>>> BIO - OK (it actually skips the test)
>>> APR - OK
>>> NIO failed first 2 of 8 runs:
>>>
>>> [[[
>>> ------------- ---------------- ---------------
>>>
>>> Testcase: testSimpleCometClient took 17,813 sec
>>> 	FAILED
>>> expected:<Client: READ: [4] bytes> but was:<Client: READ: [8] bytes>
>>> junit.framework.AssertionFailedError: expected:<Client: READ: [4]
>>> bytes> but was:<Client: READ: [8] bytes>
>>> 	at org.apache.catalina.comet.TestCometProcessor.testSimpleCometClient(TestCometProcessor.java:97)
>>>
>>> Testcase: testCometConnectorStop took 5,328 sec
>>> ]]]
>>>
>>> IIRC it is expected (two subsequent network packets arriving to Tomcat
>>> without a delay between them)
>>
>> That is unusual but not unexpected. We could handle that to prevent
>> false positives if you find it happening a lot.
> 
> That's the type of failure I saw intermittent with the old code. I
> didn't yet have a chance to retest. Last time I saw those failures it
> was always the first two "PING" messages that came in combined as
> PINGPING. When I added a 2 second delay before starting the write in the
> PingWriterThread, I could no longer reproduce the problem.

I checked the timing behaviour without the additional delay when the
problem occurs (this time first three PINGs concatenated):

PingWriterThread starting at 1316702527978
PING sent at 1316702527979
PingReaderThread starting at 1316702527980
BEGIN received at 1316702528903
PING sent at 1316702529003
PING sent at 1316702530009
READ starts at 1316702530013
READ first three PINGs
READ ends at 1316702530014
READ starts at 1316702531014
READ: PING-1316702531010
READ ends at 1316702531014
END received at 1316702532015
PingWriterThread ended at 1316702532010
PingReaderThread ended at 1316702535019

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message