False timeouts when using StreamedAsyncHandler

[n-miles]

When using the StreamedAsyncHandler to download large files, I found what I think is a bug in how timeouts are handled.

The timeout mechanism relies on when the ListenableFuture for the request was last touch()ed. touch() is only called when a HttpResponseBodyPart is delivered to the downstream. This works fine if the downstream is downloading the response as fast as possible.

However, if the downstream has no outstanding request() (like if it's serving as a proxy and its own downstream is slow or whatever), there may be long periods of time where there are no body parts published because none have been requested. In those periods, the request may "time out" because of inactivity.

I think we should change the timeout logic to only count this as a timeout if there has been no activity AND there is no outstanding request on the Publisher. This can be implemented by periodically touch()ing the ListenableFuture if there is no outstanding request() on the Publisher.

I am willing to implement it if we want this feature.

[slandelle]

I am willing to implement it if we want this feature.

Sure.

[n-miles]

@slandelle do you have any concerns about backwards compatibility or should I just add it to the existing StreamedAsyncHandler logic?

[slandelle]

do you have any concerns about backwards compatibility

Not on the reactive-streams features. Those are quite experimental (originally contributed by Lightbend, then nobody ever answered my questions).

[n-miles]

Opened #1723

[n-miles]

@slandelle when will this change make it into a release?