query may timeout if next is not called in time.

[youngsofun]

currently, next_uri is called only when iter.next() is called, client may do some time-consuming tasks between 2 calls of next,
this may lead to timeout of the query in the server side.

since the results is keeped in memory now, the server does need a way to clear the queries that are not polled for long time.

one solution

1. client get timeout time from the server, from the first resp
2. start a thread to send the heartbeat request
   3. optionally, there can be a global thread to send all query-ids in use together, it never fails: client return query-ids finished, and the heartbeater simpliy not send them any more

[youngsofun]

cc @hantmac @flaneur2020 @wubx @everpcpc

[hantmac]

@youngsofun So that is mean we can't call next_uri concurrently?

[youngsofun]

@youngsofun So that is mean we can't call next_uri concurrently?

not for same query_id.

[hantmac]

The timeout was caused by memory leak which reason is presign stmt not closed correctly. And the bug was fixed the timeout disappeard.
I will close this issue.

[youngsofun]

I think this is still a problem, but not very easy to produce.
because most of time results is returned in one page (10000 rows/page)
I guess this will fail:

1. select numbers(20000) ,
2. call next. // this will fetch 10000 rows
3. sleep(5 sec)
4. call next again entil end (timeout!) // first consuming the 10000 rows already fetched, get timeout when fetching more

---

updated @hantmac

[youngsofun]

where is the reopen button?

[hantmac]

I think this is still a problem, but not very easy to produce. because most of time results is returned in one page (10000 rows/page) I guess this will fail:

1. select numbers(20000) ,
2. call next
3. sleep(3 sec)
4. call next again (timeout!)

I can't reproduce it.

I sleep 10s while call next but it works well.

[youngsofun]

@hantmac

I think this is still a problem, but not very easy to produce. because most of time results is returned in one page (10000 rows/page) I guess this will fail:

1. select numbers(20000) ,
2. call next. // this will fetch 10000 rows
3. sleep(5 sec)
4. call next again entil end (timeout!) // first consuming the 10000 rows already fetched, get timeout when fetching more
   updated @hantmac

[wubx]

Now for many case I have change http_handler_result_timeout_secs=300