Maybe you could set the timeout strategy globally:
/ivysettings/resolvers/@timeout-constraint

<ivysettings>
   <timeout-contraints>
      <timeout-constraint name="smaller-timeout" connection-timeout="" 
read-timeout="" />
      ...
   </timeout-constraints>
 
   <resolvers timeout-constraint="global-timeout">
      <ibiblio timeout-constraint="smaller-timeout" ... />
   </resolvers>
</ivysettings>


Jan


> -----Ursprüngliche Nachricht-----
> Von: jai.forums2...@gmail.com [mailto:jai.forums2...@gmail.com]
> Gesendet: Montag, 17. Juli 2017 06:56
> An: dev@ant.apache.org
> Betreff: Re: Proposed changes for IVY-735 - Ability to specify timeouts
> 
> I think, that's actually a good idea. Defining the timeout constraints
> separately as named constraints and then referencing them would allow
> reusing these values on whichever resolvers want to:
> 
> <ivysettings>
> 
>   <timeout-contraints>
> 
>      <timeout-constraint name="smaller-timeout" connection-timeout=""
> read-timeout="">
> 
>      ...
> 
>   </timeout-constraints>
> 
>   <resolvers>
> 
>      <ibiblio timeout-constraint="smaller-timeout" .../>
> 
>   </resolvers>
> 
> </ivysettings>
> 
> 
> -Jaikiran
> 
> 
> On 14/07/17 10:33 PM, Gintautas Grigelionis wrote:
> > my €.02 : currently, all resolvers only have artifact patterns as
> > child elements, so I'd rather have the timeouts as attributes that
> > might use references, similarly to cache managers or latest
> > strategies. That would imply a global default that may be overridden
> individually.
> >
> > Gintas
> >
> > 2017-07-14 13:34 GMT+02:00 <jaikiran....@cloudfabrix.com>:
> >
> >> 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:
> >>
> >>      <ivysettings>
> >>
> >>          <resolvers>
> >>
> >>              <ibiblio ...>
> >>
> >>                  <timeout-constraints connection-timeout=""
> >> read-timeout=""/>
> >>
> >>              </ibiblio>
> >>
> >>      ....
> >>
> >> - 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/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8
> >>
> >> [2] https://github.com/jaikiran/ant-ivy/commit/e501d9deca78db8b9
> >> 34f8a2710ebcfeaeb1456c8#diff-cd8ed454a52f4afa779574f5600a0ccb
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
> additional
> >> commands, e-mail: dev-h...@ant.apache.org
> >>
> >>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
> commands, e-mail: dev-h...@ant.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to