You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API returns either a subscriber or a 404 the first 5 times I GET a subscriber. The 6th time I get a timeout. After each of the first 5 GETs, there is one more read+write file descriptor open for newsletter.db. I would expect there to be only one all the time.
The reason for the timeout is that Thin starts processing each request in a thread and finishes processing the request in another thread. ConnectionManagement only returns to the pool those connections that are active for the current thread and Thin applies ConnectionManagement in the second thread instead of the first.
Do you think it makes sense to provide the following version of ConnectionManagement in gem sinatra-activerecord?
Consider the following example Sinatra API.
The API returns either a subscriber or a 404 the first 5 times I GET a subscriber. The 6th time I get a timeout. After each of the first 5 GETs, there is one more read+write file descriptor open for newsletter.db. I would expect there to be only one all the time.
The reason for the timeout is that Thin starts processing each request in a thread and finishes processing the request in another thread.
ConnectionManagement
only returns to the pool those connections that are active for the current thread and Thin appliesConnectionManagement
in the second thread instead of the first.Do you think it makes sense to provide the following version of
ConnectionManagement
in gemsinatra-activerecord
?The text was updated successfully, but these errors were encountered: