From dev-return-89834-apmail-ant-dev-archive=ant.apache.org@ant.apache.org Fri Jul 14 12:25:18 2017 Return-Path: X-Original-To: apmail-ant-dev-archive@www.apache.org Delivered-To: apmail-ant-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 D358A1AD31 for ; Fri, 14 Jul 2017 12:25:18 +0000 (UTC) Received: (qmail 84865 invoked by uid 500); 14 Jul 2017 12:25:18 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 84787 invoked by uid 500); 14 Jul 2017 12:25:18 -0000 Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list dev@ant.apache.org Received: (qmail 19795 invoked by uid 99); 14 Jul 2017 11:35:08 -0000 X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudfabrix-com.20150623.gappssmtp.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudfabrix-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=mu3CYZMMnBVKQssESjXUJRd5YyCJKCFq0cKplhFH3Bw=; b=e6386+ulDk6D6O+6NhhSu0dIycAzT3L4lrecsXu8EEfXXyh8Ffb+hdiLNRlO0dbbNv BgOmmoI0EFf0hRNNDRAaj9LO8vXtrWpBIU5iL5b5wnJYSAXDys/YUtEuJBZbJhtoAeao 49pYvKAKhJEQDKK0SDIySPj9HFsJ0PtOxpdbYdT5u75X2z6m44AUvdP5dEopc+orttRW WJOOjGverV2y1g27PvG8+/VjnSNemBsh9beFK8OkEPUh2C1MaNPedQNXoS8sM7yEe1HZ XabG1PyfPHAXdDwGW0C5fqchytSxV+NhBjMFd5Q2I3Alv7ewoxuITJDcKgRhM91nXLsr XmGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=mu3CYZMMnBVKQssESjXUJRd5YyCJKCFq0cKplhFH3Bw=; b=XNxsZbxTU8tgqXb4/azApqOuTwWozREZ1rW+yfFmgdRul811ZmEX5dubK5ywrcVb/H qnAWQaendFAhKyurY02Sf6DvX93Gu9VU9FFYB5lHRAlJcNBYi/owUSG7l42TfYk2teqU qVMAXyPIuDJHFeZMQ7ia06+muKYPats9mCKcQh61qHyzhneLlevqKcGCH+7tJ2oqvQ5/ NS5ymMfDihVioL8OIh5wcc9YruwuRKGcKLMzyOWcEOkkpMnYQxqO96NqzoHZMTCNXAe5 orF0806S/cTbzM7vm9J5ZrRxrjXMU7L//A89adCVXg8brzQyYuge7kdi7nsR8IU24WPN Y2TQ== X-Gm-Message-State: AIVw111bvMRmDw2v50qqaomcpHrYlVnuY8CkpGMhCpZHmFkmxIyRg1C6 5NXQpnjcuBz/OLhpQHRDLg== X-Received: by 10.84.213.151 with SMTP id g23mr3079588pli.59.1500032091874; Fri, 14 Jul 2017 04:34:51 -0700 (PDT) From: jaikiran.pai@cloudfabrix.com X-Google-Original-From: jaikiran@apache.org To: dev@ant.apache.org Subject: Proposed changes for IVY-735 - Ability to specify timeouts Message-ID: Date: Fri, 14 Jul 2017 17:04:49 +0530 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US https://issues.apache.org/jira/browse/IVY-735 is a feature request where the users have asked for relevant timeouts while dealing with downloads. A few weeks back we had a very brief discussion in an unrelated mail where it was proposed that we allow configuring these timeout all the way from ivy settings. I have an initial proposal/attempt to implement this feature. The initial changes are here in my personal repo[1]. It's a work in progress commit which sets up the necessary interfaces and the flow to show what I have in mind. Before proceeding further, I would like some inputs on whether this looks fine. Here's a summary of what the changes are going to be: - Each (dependency) resolver will have the ability to specify "timeout constraints"[2]. - These timeout constraints will be specified while defining the resolver in the ivy settings file. Imagine something like: .... - Each of the resolver will then use these timeout constraints (if specified) while resolving the module descriptor and downloading the artifacts and dealing with those resources. - The absence of the timeout constraints will let the resolvers behave the way they do currently The changes in the linked commit deprecate some APIs which weren't using timeouts and are replaced by APIs which pass along (an optional) TimeoutConstraints[2]. In summary, the change being proposed is that (dependency) resolvers have the ability to specify these timeout constraints and then use them while dealing with module descriptors and artifacts. One thing I have (to some extent intentionally) left out is the ability to define a global Ivy settings level or "all resolvers" level timeout-constraints. That's because I'm not too sure if it adds much value instead of defining it at individual resolver level. I'm however open to adding that support as well. The linked commit currently doesn't have the necessary support for parsing these additional XML elements, but if this whole approach looks fine, I will take this further and make sure things work as expected. [1] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b934f8a2710ebcfeaeb1456c8 [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b934f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb -Jaikiran --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org