Return-Path: X-Original-To: apmail-tomcat-dev-archive@www.apache.org Delivered-To: apmail-tomcat-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9AF4BC7EB for ; Mon, 3 Jun 2013 12:45:07 +0000 (UTC) Received: (qmail 3313 invoked by uid 500); 3 Jun 2013 12:45:06 -0000 Delivered-To: apmail-tomcat-dev-archive@tomcat.apache.org Received: (qmail 3065 invoked by uid 500); 3 Jun 2013 12:45:06 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 3056 invoked by uid 99); 3 Jun 2013 12:45:04 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2013 12:45:04 +0000 Received: from localhost (HELO [192.168.23.9]) (127.0.0.1) (smtp-auth username markt, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Jun 2013 12:45:04 +0000 Message-ID: <51AC8FCC.7030501@apache.org> Date: Mon, 03 Jun 2013 13:45:00 +0100 From: Mark Thomas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: APR/native errors with non-blocking I/O References: <51A8EE07.3000105@apache.org> <99C8B2929B39C24493377AC7A121E21FC4B0DB5B04@USEA-EXCH8.na.uis.unisys.com> <0348c161-7715-4a02-a98a-a176ca51b8d6@email.android.com> <51AC5D72.3080405@apache.org> In-Reply-To: <51AC5D72.3080405@apache.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 03/06/2013 10:10, Mark Thomas wrote: > My next step is to look more closely at the server code (the issue is > sensitive to timing so it can be tricky to add debug code and still see > the issue) to figure out if I am misusing the API or if there might be > an APR/native bug at the root of this. I've finally figured out what is going on. The non-blocking write test is more likely to hit this bug because it uses a slow client so the buffers all fill up. In theory, any of the non-blocking code could hit this. The problem is actually quite simple. When the buffers are almost full the next write triggers an APR_STATUS_IS_EAGAIN. However, some of the requested data will have been written. How much data is not available through the current API. The Tomcat code assumes no data was written and hence ends up duplicating part of the previous write. Thoughts on how to extend the tc native API? I'm thinking something along the lines of the following: if (ss == APR_SUCCESS) return (jint)sent; else if ((APR_STATUS_IS_EAGAIN(ss) || ss == TCN_EAGAIN) && sent > 0) { return (jint)sent; } else { TCN_ERROR_WRAP(ss); return -(jint)ss; } to fix the immediate problem. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org For additional commands, e-mail: dev-help@tomcat.apache.org