Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 33371 invoked from network); 14 Jul 2005 18:47:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Jul 2005 18:47:26 -0000 Received: (qmail 19071 invoked by uid 500); 14 Jul 2005 18:47:25 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 19023 invoked by uid 500); 14 Jul 2005 18:47:24 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 19009 invoked by uid 99); 14 Jul 2005 18:47:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Jul 2005 11:47:24 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [157.22.36.8] (HELO mail.plushpix.com) (157.22.36.8) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Jul 2005 11:47:21 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.plushpix.com (Postfix) with ESMTP id 8F4F3F9C3; Thu, 14 Jul 2005 12:10:32 -0700 (PDT) Date: Thu, 14 Jul 2005 12:10:32 -0700 (PDT) From: Alex Burmester Reply-To: To: Vinod Panicker Cc: , Apache Directory Developers List Subject: Re: losing packets when load testing my mina app In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I think I have isolated the problem to a firewall between the two machines I am using. If I look at traffic dumps from both the client and the server, I see the resets as originating from the client when I look at the server's dump but when I look at the client dump I see no resets, I just see no acknowledgement of the packet so the client does a few tcp retransmissions of the packet which the server then ignores because of the reset. This was confirmed by running the load test client on another machine on the same subnet and no resets were triggered. Thanks for helpful pointers all. Alex. On Thu, 14 Jul 2005, Vinod Panicker wrote: > On 7/14/05, Alex Burmester 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. >