Canceling submitted request


(mfeingold) #1

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?


(Shay Banon) #2

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.comwrote:

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?


(jp.lorandi) #3

.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>

Date: Mon, August 01, 2011 5:13 pm

To: elasticsearch <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?


(Alex Piggott) #4

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 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?


(jp.lorandi) #5

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>

Date: Mon, August 01, 2011 6:23 pm

To: elasticsearch <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> 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?


(David Pilato) #6

Hi Alex,

Thanks for sharing this.
Very useful for my needs.

Take care.
David :wink:

Le 1 août 2011 à 23:23, Alex at Ikanow 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 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?


(system) #7