ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Proposed changes for IVY-735 - Ability to specify timeouts
Date Fri, 14 Jul 2017 11:37:17 GMT 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: 



            <ibiblio ...> 

                <timeout-constraints connection-timeout="" read-timeout=""/> 



- 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. 




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message