Return-Path: X-Original-To: apmail-hc-dev-archive@www.apache.org Delivered-To: apmail-hc-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 CB01E11A2C for ; Tue, 16 Sep 2014 11:37:03 +0000 (UTC) Received: (qmail 5210 invoked by uid 500); 16 Sep 2014 11:37:03 -0000 Delivered-To: apmail-hc-dev-archive@hc.apache.org Received: (qmail 5167 invoked by uid 500); 16 Sep 2014 11:37:03 -0000 Mailing-List: contact dev-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpComponents Project" Delivered-To: mailing list dev@hc.apache.org Received: (qmail 5156 invoked by uid 99); 16 Sep 2014 11:37:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2014 11:37:03 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [5.148.180.21] (HELO kalnich2.nine.ch) (5.148.180.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Sep 2014 11:36:57 +0000 Received: from [192.168.42.18] (unknown [213.55.184.160]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by kalnich2.nine.ch (Postfix) with ESMTPSA id 0FEBF160224 for ; Tue, 16 Sep 2014 11:36:34 +0000 (UTC) Message-ID: <1410867393.20201.10.camel@ubuntu> Subject: Re: High server load due to SessionOutputBufferImpl.flush() From: Oleg Kalnichevski To: HttpComponents Project Date: Tue, 16 Sep 2014 13:36:33 +0200 In-Reply-To: References: <1410353938.21468.2.camel@ubuntu> <1410770497.1489.3.camel@ubuntu> <1410772936.2359.1.camel@ubuntu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Tue, 2014-09-16 at 13:08 +0200, Tobias Bieniek wrote: > > If you do not want me to make wild guesses, please make available a > > _complete_ context / header log of the session. > > I'll see what I can do. The problem is that with our production > traffic on the server the log files are rotating very fast and it is > hard to catch a log of one entire request session, but without the > production traffic the problem doesn't seem to be reproducible. > > Since yesterday more of the I/O workers have started spinning again > and are cluttering the log files now. > > I know it is wild guessing, but could the problem be related to > streaming file downloads over SSL that are cancelled on the client > side? It appears as if the SSL session might be staying in the CLOSING > state forever with some data in the buffer but unable to flush it out. > > Tobias > Tobias This is quite likely to be related to abnormal SSL connection termination causing the I/O session to spin while trying to complete SSL session handshake. But I need to see the session log to be 100% sure. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional commands, e-mail: dev-help@hc.apache.org