From dev-return-29383-apmail-mina-dev-archive=mina.apache.org@mina.apache.org Thu Dec 24 17:09:40 2015 Return-Path: X-Original-To: apmail-mina-dev-archive@www.apache.org Delivered-To: apmail-mina-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 A122618005 for ; Thu, 24 Dec 2015 17:09:40 +0000 (UTC) Received: (qmail 63315 invoked by uid 500); 24 Dec 2015 17:09:40 -0000 Delivered-To: apmail-mina-dev-archive@mina.apache.org Received: (qmail 63280 invoked by uid 500); 24 Dec 2015 17:09:40 -0000 Mailing-List: contact dev-help@mina.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@mina.apache.org Delivered-To: mailing list dev@mina.apache.org Received: (qmail 63267 invoked by uid 99); 24 Dec 2015 17:09:40 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Dec 2015 17:09:40 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 87056180455 for ; Thu, 24 Dec 2015 17:09:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id CowiN2nbRfmS for ; Thu, 24 Dec 2015 17:09:38 +0000 (UTC) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 3A3282026A for ; Thu, 24 Dec 2015 17:09:38 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id l126so190053901wml.1 for ; Thu, 24 Dec 2015 09:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=BBeIx7DmEb6d3psuyB+FEapfnx3J2nZvoVeoK327pCg=; b=XMGkkW7YZjo2legTt1oiIybMfaAv7zm/oXfd/iuM5rhARc3y7My29zeGtRVMCZeTS4 nD1JE+h7e/lL/GFrQ+qn92Mx2JSyOAdEuAhg7ejAYL9uiua3zGwEGXfQoPfWKCSDsnaU EVaIZ20E7LXcERBLWdta9zGduRIYDcokv2cOm8cIMNUjPs7lQtr9WubWbDuQQ+duCHHs jgptfHA8TozBlV78GxE1hRAqj4PEyjqV0jNNKX1wfqCsFuGWMP4jz59tX4cRv8j9cs1j lrKrvk2Zg4xU1D6w/WTc4xvVTfgUuGW7jLdPhq7j02BJPpkgHK4HJaf2Lf35p/Jqbm15 Mxag== X-Received: by 10.194.119.232 with SMTP id kx8mr46054374wjb.94.1450976972230; Thu, 24 Dec 2015 09:09:32 -0800 (PST) Received: from [192.168.1.29] (LFbn-1-4146-141.w92-169.abo.wanadoo.fr. [92.169.142.141]) by smtp.googlemail.com with ESMTPSA id q4sm42318885wja.6.2015.12.24.09.09.31 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Dec 2015 09:09:31 -0800 (PST) To: dev From: =?UTF-8?Q?Emmanuel_L=c3=a9charny?= Subject: [MINA 2] Big bug in the NioDatagramAcceptor X-Enigmail-Draft-Status: N1110 Message-ID: <567C26C9.8050706@gmail.com> Date: Thu, 24 Dec 2015 18:09:29 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi guys, as this is a bit slow those days, I'm spending some time doing some cleanup on MINA 2.0 code (cleaning the Javadoc, checking https://analysis.apache.org/dashboard/index/109933). It's absolutly incredible the numbers of bug I have found... A few of them were easy, but this one : public void write(NioSession session, WriteRequest writeRequest) { ... final WriteRequestQueue writeRequestQueue =3D session.getWriteRequestQueue(); ... // Deal with the special case of a Message marker (no bytes in the request) // We just have to return after having calle dthe messageSent eve= nt IoBuffer buf =3D (IoBuffer) writeRequest.getMessage(); ... // Now, write the data try { for (;;) { if (writeRequest =3D=3D null) { writeRequest =3D writeRequestQueue.poll(session); if (writeRequest =3D=3D null) { setInterestedInWrite(session, false); break; } session.setCurrentWriteRequest(writeRequest); } ... } Here, there is *no chance* the writeRequest can be null when we enter the for loop, and there is no place in the for loop where we update the writeRequest object ! That means we actually never loop on the queue content. =46rom the performance POV, this is atrocious, because it means we will simply have to wait for the next event loop to be processed, instead of trying to fill the socket with all what we have. We most certainly can do better !