# Canceling submitted request **URL:** \ **Category:** Elasticsearch\ **Created:** [August 1, 2011, 8:13pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021 "2011-08-01T20:13:08Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mfeingold](https://avatars.discourse-cdn.com/v4/letter/m/ecb155/32.png) [@mfeingold](https://discuss.elastic.co/u/mfeingold)\ **Post date:** [August 1, 2011, 8:13pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/1 "2011-08-01T20:13:08Z")
Is there a way to cancel a previously submitted search request? Here is why: I want to give a list of suggestions as they type the search parameters. But I do not really want to show/update it until the user pauses in his typing. Now I implemented a sliding timeout - I do not submit the request until after .2 sec of the last keypress, which is my definition of pause in the typing, but it means that I add .2 sec to the search time. Removing the delay will generate a ton of requests I care nothing about, but if I can cancel it as soon as I get the next keypress - there is not much harm done. Any thoughts? ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [August 1, 2011, 8:21pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/2 "2011-08-01T20:21:02Z")
No, you can't cancel a search request. If you think about it, an API like that is quite complex to use (you send a search request, get a handle back, use the handle to check if you got a result, and be able to cancel it), and cumbersome (with perf overhead) to implement for a system that aims to be realtime. On Mon, Aug 1, 2011 at 11:13 PM, Michael Feingold [mfeingold@hill30.com](mailto:mfeingold@hill30.com)wrote: > Is there a way to cancel a previously submitted search request? > > Here is why: I want to give a list of suggestions as they type the > search parameters. But I do not really want to show/update it until > the user pauses in his typing. Now I implemented a sliding timeout - I > do not submit the request until after .2 sec of the last keypress, > which is my definition of pause in the typing, but it means that I > add .2 sec to the search time. > > Removing the delay will generate a ton of requests I care nothing > about, but if I can cancel it as soon as I get the next keypress - > there is not much harm done. > > Any thoughts? ---
**Author:** ![jp\_lorandi](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@jp\_lorandi](https://discuss.elastic.co/u/jp_lorandi)\ **Post date:** [August 1, 2011, 8:25pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/3 "2011-08-01T20:25:28Z")
.2 sec delay? Really? Really? I mean... really? You're walking down the razor's edge of the law of marginally diminishing returns here. I don't think you can stop a search request unless an API is created for it. > -------- Original Message -------- > > Subject: Canceling submitted request > > From: Michael Feingold \<[mfeingold@hill30.com](mailto:mfeingold@hill30.com)\> > > Date: Mon, August 01, 2011 5:13 pm > > To: elasticsearch \<[elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com)\> > > Is there a way to cancel a previously submitted search request? > > Here is why: I want to give a list of suggestions as they type the > > search parameters. But I do not really want to show/update it until > > the user pauses in his typing. Now I implemented a sliding timeout - I > > do not submit the request until after .2 sec of the last keypress, > > which is my definition of pause in the typing, but it means that I > > add .2 sec to the search time. > > Removing the delay will generate a ton of requests I care nothing > > about, but if I can cancel it as soon as I get the next keypress - > > there is not much harm done. > > Any thoughts? ---
**Author:** ![Alex\_At\_Ikanow](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alex_at_ikanow/32/676_2.png) [@Alex\_At\_Ikanow](https://discuss.elastic.co/u/Alex_At_Ikanow)\ **Post date:** [August 1, 2011, 9:23pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/4 "2011-08-01T21:23:19Z")
Hi, in case it's useful: what I did in response to the problem you discussed was only allow 1 "search suggest" request to be active at any one time. 1] So if I type 'a', my client fires a search request 2] I type (a)'l': this request is stored but not sent (because the response to 'a' has not yet returned) 3] I type (al)'e': this request is stored, overwriting 'al' with 'ale' 4] The response for 'a' appears ... I immediately send out the request for 'ale', then display the results 5] I type (ale)'x', this request is stored but not sent (because the response to 'ale' has not yet returned) etc That way regardless of how fast the user types, they can only have to wait for (worst case) 2 requests to return, and there is no risk of overloading the server with "useless" requests This has worked really well in practice for me, though of course it is dependent on: - the number of users you have concurrently typing into the search window - the time it takes for an individual request to return) - the number of of ES nodes you are distributing across Hope this helps! Alex On Aug 1, 4:13 pm, Michael Feingold [mfeing...@hill30.com](mailto:mfeing...@hill30.com) wrote: > Is there a way to cancel a previously submitted search request? > > Here is why: I want to give a list of suggestions as they type the > search parameters. But I do not really want to show/update it until > the user pauses in his typing. Now I implemented a sliding timeout - I > do not submit the request until after .2 sec of the last keypress, > which is my definition of pause in the typing, but it means that I > add .2 sec to the search time. > > Removing the delay will generate a ton of requests I care nothing > about, but if I can cancel it as soon as I get the next keypress - > there is not much harm done. > > Any thoughts? ---
**Author:** ![jp\_lorandi](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@jp\_lorandi](https://discuss.elastic.co/u/jp_lorandi)\ **Post date:** [August 1, 2011, 9:34pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/5 "2011-08-01T21:34:40Z")
We're doing that as well, queing up requests (we have to support searching thru GPRS phones so it's quite stringent). One of the keys is managing the size. But if the idea is to make an interactive search field, introducing a delay (and I'd go over .2 secs easily) is the key. You might want to affect user's perception by showing a progress icon of some sort before the threshold... something like: 1. Queue searches. If X searches are in progress, don't queue any more.2) After .1 secs of the last typed char, show a progress icon3) After .3/.4/.5 secs of the last typed char, fire the search. > -------- Original Message -------- > > Subject: Re: Canceling submitted request > > From: Alex at Ikanow \<[apiggott@ikanow.com](mailto:apiggott@ikanow.com)\> > > Date: Mon, August 01, 2011 6:23 pm > > To: elasticsearch \<[elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com)\> > > Hi, in case it's useful: what I did in response to the problem you > > discussed was only allow 1 "search suggest" request to be active at > > any one time. > > 1] So if I type 'a', my client fires a search request > > 2] I type (a)'l': this request is stored but not sent (because the > > response to 'a' has not yet returned) > > 3] I type (al)'e': this request is stored, overwriting 'al' with 'ale' > > 4] The response for 'a' appears ... I immediately send out the request > > for 'ale', then display the results > > 5] I type (ale)'x', this request is stored but not sent (because the > > response to 'ale' has not yet returned) > > etc > > That way regardless of how fast the user types, they can only have to > > wait for (worst case) 2 requests to return, and there is no risk of > > overloading the server with "useless" requests > > This has worked really well in practice for me, though of course it is > > dependent on: > > - the number of users you have concurrently typing into the search > > window > > - the time it takes for an individual request to return) > > - the number of of ES nodes you are distributing across > > Hope this helps! > > Alex > > On Aug 1, 4:13 pm, Michael Feingold \<[mfeing...@hill30.com](mailto:mfeing...@hill30.com)\> wrote: > > \> Is there a way to cancel a previously submitted search request? > > \> > > \> Here is why: I want to give a list of suggestions as they type the > > \> search parameters. But I do not really want to show/update it until > > \> the user pauses in his typing. Now I implemented a sliding timeout - I > > \> do not submit the request until after .2 sec of the last keypress, > > \> which is my definition of pause in the typing, but it means that I > > \> add .2 sec to the search time. > > \> > > \> Removing the delay will generate a ton of requests I care nothing > > \> about, but if I can cancel it as soon as I get the next keypress - > > \> there is not much harm done. > > \> > > \> Any thoughts? ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [August 1, 2011, 11:13pm UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/6 "2011-08-01T23:13:44Z")
Hi Alex, Thanks for sharing this. Very useful for my needs. Take care. David 😉 Le 1 août 2011 à 23:23, Alex at Ikanow [apiggott@ikanow.com](mailto:apiggott@ikanow.com) a écrit : > Hi, in case it's useful: what I did in response to the problem you > discussed was only allow 1 "search suggest" request to be active at > any one time. > > 1] So if I type 'a', my client fires a search request > 2] I type (a)'l': this request is stored but not sent (because the > response to 'a' has not yet returned) > 3] I type (al)'e': this request is stored, overwriting 'al' with 'ale' > 4] The response for 'a' appears ... I immediately send out the request > for 'ale', then display the results > 5] I type (ale)'x', this request is stored but not sent (because the > response to 'ale' has not yet returned) > etc > > That way regardless of how fast the user types, they can only have to > wait for (worst case) 2 requests to return, and there is no risk of > overloading the server with "useless" requests > > This has worked really well in practice for me, though of course it is > dependent on: > > - the number of users you have concurrently typing into the search > window > - the time it takes for an individual request to return) > - the number of of ES nodes you are distributing across > > Hope this helps! > > Alex > > On Aug 1, 4:13 pm, Michael Feingold [mfeing...@hill30.com](mailto:mfeing...@hill30.com) wrote: > > > Is there a way to cancel a previously submitted search request? > > > > Here is why: I want to give a list of suggestions as they type the > > search parameters. But I do not really want to show/update it until > > the user pauses in his typing. Now I implemented a sliding timeout - I > > do not submit the request until after .2 sec of the last keypress, > > which is my definition of pause in the typing, but it means that I > > add .2 sec to the search time. > > > > Removing the delay will generate a ton of requests I care nothing > > about, but if I can cancel it as soon as I get the next keypress - > > there is not much harm done. > > > > Any thoughts? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:58am UTC](https://discuss.elastic.co/t/canceling-submitted-request/5021/7 "2017-07-06T03:58:33Z")