Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 1CE4A200C1A for ; Mon, 13 Feb 2017 21:18:46 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 1B84E160B60; Mon, 13 Feb 2017 20:18:46 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5DCD6160B4A for ; Mon, 13 Feb 2017 21:18:45 +0100 (CET) Received: (qmail 45786 invoked by uid 500); 13 Feb 2017 20:18:44 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 45774 invoked by uid 99); 13 Feb 2017 20:18:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Feb 2017 20:18:44 +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 278AC1865EF for ; Mon, 13 Feb 2017 20:18:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id bbDyn1xKsxk5 for ; Mon, 13 Feb 2017 20:18:43 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id CE3AA5FB44 for ; Mon, 13 Feb 2017 20:18:42 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 0CE89E0612 for ; Mon, 13 Feb 2017 20:18:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id AE1C521D65 for ; Mon, 13 Feb 2017 20:18:41 +0000 (UTC) Date: Mon, 13 Feb 2017 20:18:41 +0000 (UTC) From: "Marcelo Vanzin (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CRYPTO-125) CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 13 Feb 2017 20:18:46 -0000 [ https://issues.apache.org/jira/browse/CRYPTO-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864349#comment-15864349 ] Marcelo Vanzin commented on CRYPTO-125: --------------------------------------- Hi there, I don't think this fix is correct. The issue here is that {{CryptoOutputStream}} is not really following the API defined by {{WritableByteChannel}}. That API allows the channel to write less data than available in the input buffer (and the calling code needs to be able to handle that situation). That's required for non-blocking I/O. This change will cause really high CPU usage if the underlying channel is non-blocking and is not ready for write, and will undesirably block I/O threads in that situation (e.g., instead of giving control back to the application so it can write to other channels that are ready, it will go into a busy loop until this one output channel becomes ready). > CryptoOutputStream does not call write in a loop when underlying channel works in non-block mode. > ------------------------------------------------------------------------------------------------- > > Key: CRYPTO-125 > URL: https://issues.apache.org/jira/browse/CRYPTO-125 > Project: Commons Crypto > Issue Type: Bug > Components: Stream > Affects Versions: 1.0.0 > Reporter: Junjie Chen > Assignee: Junjie Chen > Fix For: 1.1.0 > > > The encrypt function call output.write without loop which lead to data loss when creating the output encryption stream with a SocketChannel and works in non-block mode. > As suggested, it should be call as following way: > while(buf.hasRemaining()) { > channel.write(buf); > } -- This message was sent by Atlassian JIRA (v6.3.15#6346)