Class TimeoutsHolder


  • public class TimeoutsHolder
    extends Object
    The request and read timeouts of one exchange, armed either on the client's Timer or on the event loop of the channel the exchange runs on. What the two differ in, and why the choice is the caller's, is AsyncHttpClientConfig.isUseEventLoopTimeouts().
    • Method Detail

      • start

        public void start()
        Arms the request timeout, which the constructor deliberately leaves undone. The task holds this holder and can run the moment it is armed, and on an event loop nothing rounds a short deadline up to the next tick, so arming from the constructor let it run before its own fields were frozen, before the future had been handed the holder, and on the pooled path before the channel had been attached to the future -- an expiry that then had no channel to close.

        Called by NettyResponseFuture.setTimeoutsHolder(org.asynchttpclient.netty.timeout.TimeoutsHolder), so that installing a holder is what arms it and neither can be done without the other.

        Only the first call arms. A second would overwrite the first handle, leaving an entry nobody can cancel to sit in its scheduler until the full deadline, pinning the task, the future and the channel.

      • remainingBudget

        public static long remainingBudget​(AsyncHttpClientConfig config,
                                           NettyResponseFuture<?> nettyResponseFuture)
        How much of a deadline spanning the whole exchange is left, in milliseconds, negative once it has passed. Long.MAX_VALUE when the timeout is per attempt or disabled, neither of which bounds an exchange as a whole: an attempt is then given the configured timeout of its own however long the exchange has run.

        Measured from the future's monotonic start rather than by comparing wall clocks across hops, so a clock correction landing mid-chain cannot move the deadline. Static, and asked of the future rather than of a holder, because a caller deciding whether a request is still worth sending has the future in hand before any holder exists for the attempt it is about to make.

        See Also:
        AsyncHttpClientConfig.isUseAbsoluteRequestDeadline()
      • rehomeOn

        public void rehomeOn​(io.netty.util.concurrent.EventExecutor executor)
        Moves this exchange's timeouts onto executor, the loop of the channel it turned out to run on. The connect path arms the request timeout before there is a channel -- deliberately, since it bounds address resolution and the connect as well -- so there the loop is only known once the connection succeeds. A no-op when the timeouts belong on the timer, or once the request timeout has fired or been cancelled.
      • setResolvedRemoteAddress

        public void setResolvedRemoteAddress​(InetSocketAddress address)
      • startReadTimeout

        public void startReadTimeout()
      • cancel

        public void cancel()