Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

per query timeouts not respected #162

Open
Wijnand opened this issue Dec 16, 2016 · 8 comments · Fixed by #239 · May be fixed by #172
Open

per query timeouts not respected #162

Wijnand opened this issue Dec 16, 2016 · 8 comments · Fixed by #239 · May be fixed by #172

Comments

@Wijnand
Copy link

Wijnand commented Dec 16, 2016

When running "ALTER TABLE" queries on a large table I discovered the given timeout was not respected. After 5 seconds I got an error: Mariaex.Protocol (#PID<0.3419.0>) disconnected: ** (Mariaex.Error) [tcp] recv failed with: :timeout

I did not try it with a direct connection to Mariaex, in this case I perform the queries via Ecto (and thus DBConnection).
Ecto.Adapters.SQL.query!(MyApp.Repo, "select sleep(6)", [], timeout: 7000)

I traced the given timeout option through ecto and db_connection, but MariaEx.Protocol is where its get lost., in handle_execute to be precise.

I don't know what the correct solution should be so I have no pull request for you, sorry.
@fishcakez
Copy link
Contributor

@Wijnand the issue is at:

mariaex/lib/mariaex/protocol.ex

Line 1055 in f4fe6f6

case sock_mod.recv(sock, more, state.timeout) do
. We should use an :infinity timeout here when doing a query/transactions. However we probably don't want to wait forever when handshaking or doing a ping. It might be helpful to see how postgrex handles this situation.

@fishcakez
Copy link
Contributor

To be clear an :infinity timeout is ok when doing queries/transactions because DBConnection will trigger a disconnect/ socket close using a timer. This will interrupt the receive.

@fishcakez fishcakez mentioned this issue Jan 4, 2017
Open
@cristianberneanu cristianberneanu mentioned this issue Jan 11, 2017
Closed
@cristianberneanu
Copy link

I encountered the same problem and fixed it by setting the timeout value in the start_link call.

@hogjosh hogjosh linked a pull request Feb 22, 2017 that will close this issue
Open
@fishcakez fishcakez mentioned this issue May 29, 2017
Closed
@dbhobbs
Copy link

dbhobbs commented Jun 20, 2017

I believe I'm seeing this issue surface when modifying the schema of a larger table (~700_000 records) in an Ecto migration.

The alter table(:table_name) do ... end statement will timeout (even though Ecto migrations have a timeout of :infinity). This causes the migration to fail, however, because of implicit commits (https://dev.mysql.com/doc/refman/5.7/en/implicit-commit.html) the schema alteration will have happened. The migration is attempted again (because it previously failed) and now it will continually fail with the error #{code => 1060, message => <<"Duplicate column name 'new_column_name'">>} requiring manual intervention to get the database back in sync with our migrations.

@dbhobbs dbhobbs mentioned this issue Jun 20, 2017
Open
@capeskychung
Copy link

Have someone use mongodb have this problem : "Timeout while waiting for migration commit"

rixmann pushed a commit to rixmann/mariaex that referenced this issue Sep 27, 2018
fix not applying :timeout in query options
9a3eafa 
The :timeout option parameter in DBConnection callbacks was not forwarded to
the message receiving function.
Instead the configured general :timeout was used.

Added two testcases which will block for ~1.5 seconds.

closes xerions#162
rixmann pushed a commit to rixmann/mariaex that referenced this issue Sep 27, 2018
fix not applying :timeout in query options
f48e99b 
The :timeout option parameter in DBConnection callbacks was not forwarded to
the message receiving function.
Instead the configured general :timeout was used.

Added two testcases which will block for ~1.5 seconds.

closes xerions#162
@rixmann rixmann mentioned this issue Sep 27, 2018
Merged
@0xAX 0xAX closed this as completed in #239 Oct 9, 2018
@fishcakez
Copy link
Contributor

For DBConnection drivers we should always pass :infinity to socket receive and rely on DBConnection to handle the timeout when not inside connect/1. Inside connect/1 requires the driver to handle timeouts. #239 is an improvement but we are still not doing the correct thing.

@fishcakez fishcakez reopened this Oct 11, 2018
@thawatchai
Copy link

@cristianberneanu Could you give me more details what you've done in the following?

I encountered the same problem and fixed it by setting the timeout value in the start_link call.

Thank you very much.

@cristianberneanu
Copy link

Somthing like this: {:ok, connection} = Mariaex.start_link(parameters ++ [timeout: :timer.hours(1)])

nulian pushed a commit to bettyblocks/mariaex that referenced this issue Aug 8, 2019
fix not applying :timeout in query options
18a0151 
The :timeout option parameter in DBConnection callbacks was not forwarded to
the message receiving function.
Instead the configured general :timeout was used.

Added two testcases which will block for ~1.5 seconds.

closes xerions#162

(cherry picked from commit f48e99b)
@nulian nulian mentioned this issue Aug 8, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix not applying :timeout in query options rixmann/mariaex
Respect timeouts specified per query
6 participants
@Wijnand @thawatchai @dbhobbs @fishcakez @capeskychung @cristianberneanu