You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2011/07/10 11:28:17 UTC
Sporadic failures in TestCometProcessor
I get sporadic failures in TestCometProcessor for NIO. They are due to
the Servlet reading two or more of the PING tokens during a single read
event call. The loop
while (is.available() > 0) {
is.read();
count ++;
}
then e.g. consumes PINGPING instead of PING and writes back "READ: 8 bytes".
Is this an error in the test case, e.g. if the chunks come in quickly
enough is it OK, that they might get combined into a single read event?
If so, we might want to add a little sleep in between sending the PING
lines.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Sporadic failures in TestCometProcessor
Posted by Mark Thomas <ma...@apache.org>.
On 10/07/2011 12:19, Rainer Jung wrote:
> On 10.07.2011 12:13, Mark Thomas wrote:
>> On 10/07/2011 10:28, Rainer Jung wrote:
>>> I get sporadic failures in TestCometProcessor for NIO. They are due to
>>> the Servlet reading two or more of the PING tokens during a single read
>>> event call. The loop
>>>
>>> while (is.available() > 0) {
>>> is.read();
>>> count ++;
>>> }
>>>
>>> then e.g. consumes PINGPING instead of PING and writes back "READ: 8 bytes".
>>>
>>> Is this an error in the test case, e.g. if the chunks come in quickly
>>> enough is it OK, that they might get combined into a single read event?
>>> If so, we might want to add a little sleep in between sending the PING
>>> lines.
>>
>> There is already a 1000ms sleep between sending the PINGs. That should
>> be enough to keep them separate.
>
> Sorry I was so convinced it's a timing issue, that I didn't check that.
>
>> Have you always seen these since that test was introduced or is this
>> something new?
>
> I added the test to 7.0.16 and ran it there and again it fails with the
> same symptom every now and then.
OK, so not a regression.
>> As an aside, I have noticed that running the unit tests on a heavily
>> loaded box can trigger various timing related failures.
>
> The system is mainly idle. It has two CPUs, so it should be able to
> handle the sending and the servlet in parallel.
>
> *Important*: One more observation, that always happens: the test doesn't
> write anything to the access log. None of the two public log messages of
> the AccessLogValve are called. I thought you added access log messages
> for comet and async not to far in the past, but I might be wrong about
> comet.
I'd expect there to be something, but I don't recall adding something
specifically.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Sporadic failures in TestCometProcessor
Posted by Rainer Jung <ra...@kippdata.de>.
On 10.07.2011 12:13, Mark Thomas wrote:
> On 10/07/2011 10:28, Rainer Jung wrote:
>> I get sporadic failures in TestCometProcessor for NIO. They are due to
>> the Servlet reading two or more of the PING tokens during a single read
>> event call. The loop
>>
>> while (is.available() > 0) {
>> is.read();
>> count ++;
>> }
>>
>> then e.g. consumes PINGPING instead of PING and writes back "READ: 8 bytes".
>>
>> Is this an error in the test case, e.g. if the chunks come in quickly
>> enough is it OK, that they might get combined into a single read event?
>> If so, we might want to add a little sleep in between sending the PING
>> lines.
>
> There is already a 1000ms sleep between sending the PINGs. That should
> be enough to keep them separate.
Sorry I was so convinced it's a timing issue, that I didn't check that.
> Have you always seen these since that test was introduced or is this
> something new?
I added the test to 7.0.16 and ran it there and again it fails with the
same symptom every now and then.
> As an aside, I have noticed that running the unit tests on a heavily
> loaded box can trigger various timing related failures.
The system is mainly idle. It has two CPUs, so it should be able to
handle the sending and the servlet in parallel.
*Important*: One more observation, that always happens: the test doesn't
write anything to the access log. None of the two public log messages of
the AccessLogValve are called. I thought you added access log messages
for comet and async not to far in the past, but I might be wrong about
comet.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Sporadic failures in TestCometProcessor
Posted by Mark Thomas <ma...@apache.org>.
On 10/07/2011 10:28, Rainer Jung wrote:
> I get sporadic failures in TestCometProcessor for NIO. They are due to
> the Servlet reading two or more of the PING tokens during a single read
> event call. The loop
>
> while (is.available() > 0) {
> is.read();
> count ++;
> }
>
> then e.g. consumes PINGPING instead of PING and writes back "READ: 8 bytes".
>
> Is this an error in the test case, e.g. if the chunks come in quickly
> enough is it OK, that they might get combined into a single read event?
> If so, we might want to add a little sleep in between sending the PING
> lines.
There is already a 1000ms sleep between sending the PINGs. That should
be enough to keep them separate.
Have you always seen these since that test was introduced or is this
something new?
As an aside, I have noticed that running the unit tests on a heavily
loaded box can trigger various timing related failures.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org