Hello!
On Sat, Jul 19, 2014 at 8:51 PM, Vitaly Kosenko wrote:
> Okey. And what about stucked query?
Same thing from the perspective of the client. No difference at all.
Just leading to timeout errors if you specify a reasonable timeout via
set_timeout().
> Will correspoding read_reasult operation
> be failed?
The read_result() method returns nil, "... timeout" on the Lua land.
The easiest way is to run a long running MySQL query and check the
behavior yourself. For example, the MySQL query "select sleep(3600)"
requiring 3600 sec to run. Also always refer to the documentation :)
> Will next send_query in these connection be failed?
When a connection is timed out, it is already in an inconsistent
state. The only safe way to do is to discard this connection. And yes,
the next send_query() call on the same cosocket object will fail
immediately unless you call connect() to get a new connection again.
We could do more in case of timeout errors, that is, to kill the
running thread on the MySQL server side (the MySQL server does not
really respond to connection aborts the last time I checked. Alas).
For example, for the ngx_drizzle module, we have the
$drizzle_thread_id variable for current MySQL connection (or session)
that can be used in another MySQL connection (session) via the "kill
query" command:
https://github.com/openresty/drizzle-nginx-module#drizzle_thread_id
For lua-resty-mysql, we need to expose an API to return the MySQL
thread ID (we actually parse out the thread ID in the existing
implementation but we did not save nor make use of it at all). Patches
welcome and volunteers welcome :)
> When do I get
> timeout error?
Aren't we already talking about the various cases leading to timeout
errors all the time? Have you read my previous email?
> I need to know to retry query few times before "real" raising
> error
>
Sure. This is considered one of the standard practices of error handling :)
Regards,
-agentzh
