Ah, nevermind. I was misunderstanding how maxRequestDuration related to the retries.
Locally, I had Flink set not to retry on failure, so once maxRequestDuration expired without a successful result, Flink itself was stopping, and I wasn't seeing the function get called again. But I see now that, if Flink is set to retry on failure, then it will start from the last checkpoint and retry, which is what I wanted to happen. Sorry for the confusion. On Wed, Feb 2, 2022 at 2:55 PM Galen Warren <ga...@cvillewarrens.com> wrote: > Gotcha, thanks. I may be able to work on that one in a couple weeks if > you're looking for help. > > Unrelated question -- another thing that would be useful for me would be > the ability to set a maximum backoff interval in BoundedExponentialBackoff > or the async equivalent. My situation is this. I'd like to set a long > maxRequestDuration, so it takes a good while for Statefun to "give up" on a > function call, i.e. perhaps several hours or even days. During that time, > if the backoff interval doubles on each failure, those backoff intervals > get pretty long. > > Sometimes, in exponential backoff implementations, I've seen the concept > of a max backoff interval, i.e. once the backoff interval reaches that > point, it won't go any higher. So I could set it to, say, 60 seconds, and > no matter how long it would retry the function, the interval between > retries wouldn't be more than that. > > Do you think that would be a useful addition? I could post something to > the dev list if you want. > > On Wed, Feb 2, 2022 at 2:39 PM Igal Shilman <i...@apache.org> wrote: > >> Hi Galen, >> You are right, it is not possible, but there is no real reason for that. >> We should fix this, and I've created the following JIRA issue [1] >> >> >> [1] https://issues.apache.org/jira/browse/FLINK-25933 >> >> On Wed, Feb 2, 2022 at 6:30 PM Galen Warren <ga...@cvillewarrens.com> >> wrote: >> >> > Is it possible to choose the async HTTP transport using >> > RequestReplyFunctionBuilder? It looks to me that it is not, but I >> wanted to >> > double check. Thanks. >> > >> >
