Ensure <connection object>:execute() don't block a fiber infinitely #34

Totktonada · 2019-11-22T04:40:26Z

Case: a connection is acquired from a pool, then three fibers use it: one calls <connection object>:execute() and acquires a lock (let's consider a long request), another one perform other calls to :execute() and third one put the connection back to the pool.

Say, when the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as unusable, however the lock will not be released (see conn_put). The second fiber will be blocked infinitely.

Even if we'll release the lock in <pool object>:put() and the second fiber will wake up in :execute(), it will at the point after self.usable check and will try to execute a request. It will even succeed, but it looks as a side effect of #32.

It is maybe not quite correct usage, but we should handle it appropriately: wait for necessary events, give an error for an incorrect usage, don't leak resources and surely don't block a fiber infinitely.

It seems the similar problem with passed <connection object>.usable check may appears for a connection that is created with mysql.connect() w/o a pool if we'll try the similar case, but with <connection object>:close() instead of <pool object>:put().

NB: Add test cases for both described situations.

The text was updated successfully, but these errors were encountered:

The absence of this operation could lead to an infinite bloсking when used with fiber (case in tests). Closes #34

Test that concurrent use of execute and close does not result to infinite blocking. Part of #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection `conn`is acquired from a pool, then three fibers use it: the first one calls `conn:execute()` and acquires a lock (let's consider a long request), another one perform other calls to `conn:execute()` and third one put the connection back to the pool. When the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as `unusable`, however the lock will not be released (before this patch). The second fiber will be blocked infinitely on `conn:execute()`'s `get()`. Closes #34

Test that concurrent use of execute and close does not result to infinite blocking. Part of #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection `conn`is acquired from a pool, then three fibers use it: the first one calls `conn:execute()` and acquires a lock (let's consider a long request), another one perform other calls to `conn:execute()` and third one put the connection back to the pool. When the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as `unusable`, however the lock will not be released (before this patch). The second fiber will be blocked infinitely on `conn:execute()`'s `get()`. Closes #34

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection `conn`is acquired from a pool, then three fibers use it: the first one calls `conn:execute()` and acquires a lock (let's consider a long request), another one perform other calls to `conn:execute()` and third one put the connection back to the pool. When the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as `unusable`, however the lock will not be released (before this patch). The second fiber will be blocked infinitely on `conn:execute()`'s `get()`. Closes #34

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection `conn`is acquired from a pool, then three fibers use it: the first one calls `conn:execute()` and acquires a lock (let's consider a long request), another one perform other calls to `conn:execute()` and third one put the connection back to the pool. When the long request will be done, the third fiber will acquire the lock and put the connection to the pool. The old connection object will be marked as `unusable`, however the lock will not be released (before this patch). The second fiber will be blocked infinitely on `conn:execute()`'s `get()`. Closes #34

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection conn is acquired from a pool and we acquire a lock. Then we start the first fiber with pool:put(conn)`, which try to acquire lock and yield. Then the second fiber is started to perform request with `conn:execute()` which try to acquire lock, because the connection is still marked as `usable` and yield too. Before this patch, it's appeared that the lock is never released. Closes #34

The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection conn is acquired from a pool and we acquire a lock. Then we start the first fiber with pool:put(conn)`, which try to acquire lock and yield. Then the second fiber is started to perform conn:execute(), conn:reset() and conn:quote() which try to acquire lock, because the connection is still marked as `usable` and yield too. Before this patch, it's appeared that the lock is never released. Closes #34

Make lock arithmetic proper and complite in conn:execute(), conn:close(), conn:reset() and conn:quote(). Release lock in pool:put(conn). The absence of this operation could lead to an infinite bloсking when used with fiber as describerd in the case below. A connection conn is acquired from a pool and we acquire a lock. Then we start the first fiber with pool:put(conn)`, which try to acquire lock and yield. Then the second fiber is started to perform conn:execute(), conn:reset() and conn:quote() which try to acquire lock, because the connection is still marked as `usable` and yield too. Before this patch, it's appeared that the lock is never released. Closes #34

Totktonada added the bug Something isn't working label Nov 22, 2019

Totktonada mentioned this issue Nov 22, 2019

timeout option for the pool:get() #28

Merged

Totktonada added the teamE label Dec 8, 2020

romanhabibov self-assigned this Dec 12, 2020

romanhabibov added a commit that referenced this issue Dec 17, 2020

api: release lock in pool:put(conn)

c8921d7

The absence of this operation could lead to an infinite bloсking when used with fiber (case in tests). Closes #34

romanhabibov added a commit that referenced this issue Dec 17, 2020

api: release lock in pool:put(conn)

6b616a5

The absence of this operation could lead to an infinite bloсking when used with fiber (case in tests). Closes #34

romanhabibov added a commit that referenced this issue Dec 17, 2020

test: fiber is not blocked by close/execute

e3dd69c

Test that concurrent use of execute and close does not result to infinite blocking. Part of #34

LeonidVas linked a pull request Dec 22, 2020 that will close this issue

fiber: release lock in pool:put(conn) #55

Merged

romanhabibov mentioned this issue Dec 23, 2020

fiber: release lock in pool:put(conn) #55

Merged

romanhabibov added a commit that referenced this issue Dec 23, 2020

test: fiber is not blocked by close/execute

7b362bd

Test that concurrent use of execute and close does not result to infinite blocking. Part of #34

romanhabibov added a commit that referenced this issue Dec 23, 2020

test: fiber is not blocked by close/execute

5bfab0c

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

romanhabibov added a commit that referenced this issue Dec 24, 2020

test: fiber is not blocked by close/execute

6382545

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

romanhabibov added a commit that referenced this issue Dec 24, 2020

test: fiber is not blocked by close/execute

e463b96

Test that concurrent use of `execute` and `close` does not result to infinite blocking. Part of #34

Totktonada closed this as completed in #55 Mar 2, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Ensure <connection object>:execute() don't block a fiber infinitely #34

Ensure <connection object>:execute() don't block a fiber infinitely #34

Totktonada commented Nov 22, 2019

Ensure <connection object>:execute() don't block a fiber infinitely #34

Ensure <connection object>:execute() don't block a fiber infinitely #34

Comments

Totktonada commented Nov 22, 2019