On 7/14/05, Alex Burmester <[EMAIL PROTECTED]> wrote: > I just noticed in my ethereal traffic that it is the load testing client > that is initiating the tcp reset packets so this may be unrelated to mina > as the client currently doesn't use mina.
IIRC, the RST would be generated if the client got an unexpected response/timeout from the server. > The server is runing mina 0.7.3 using jdk1.5.0_04 and the os/kernel is > redhat 2.4.21-20.ELsmp Linux kernels 2.6.x are known to have an improved tcp implementation - maybe that would help. > The client is fedora 2.6.10-1.741_FC3smp > > What is strange is that I don't see any tcp errors on either machine > using netstat -i eth0 -t -c 10 > > Both jvms have ample memory allocated. Could you tell me the command line args that you are using for the jvm? And did you notice the memory/cpu utilization of both apps during the test? > After running the load test for about 10 seconds I start to see occasional > read timeouts on the client. First I thought the mina server was not > responding but then I found that the client is actually issuing a tcp > reset before actually trying to send it's payload to the mina server. > As a result the mina server never actually accepts the packet and the > client after doing a tcp retransmission a few times eventually times out. > > Any suggestions? You could post the source and I could try it out on my machines and see if the problem can be reproduced. --snip-- Regards, Vinod.
