Changing the wait_timeout to a higher value is not something that's in my
hands. But I am surely going to try the shardedthreadedconnectionpooling
and the queue implementation of connection_handling. I will let you know
the results very soon.
But, I still can't understand the behavior of DB.disconnect. DB.disconnect
as I understand, in a default threadedconnectionpool, closes all
connections which are not currently in use. Since I am using DB.disconnect
at the end of every thread, there can't be an instance that a connection
wasn't used for 10 seconds and DB.disconnect wasn't called in between. So,
why am I getting errors related to wait_timeout? It goes without saying
that none of my threads take more than 10 seconds to complete the request
And then there is one hypothetical problem that I want an answer to. Is
there a way to get a situation like the one I am mentioning below handled
by the sequel connection pool itself with the restriction of of not
changing the wait_timeout at mysql level:
get "/*" do
DB.execute("statement 1")
sleep(11)
DB.execute("statement 2")
end
Connection pools like JNDI handle this using the validation query.
Thanks
-Azitabh
On Saturday, 28 July 2012 21:58:14 UTC+5:30, Jeremy Evans wrote:
>
> On Saturday, July 28, 2012 5:47:08 AM UTC-7, azi wrote:
>>
>> Thanks Jeremy for the suggestions.
>> I am no longer using jndi pooling and things are working pretty much fine
>> for me except for in some special conditions. During the off hours, I am
>> getting
>> W, [2012-07-27T23:09:42.424000 #9252] WARN -- : 134341078229443 ==
>> NativeException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException:
>> Communications link failure
>>
>> The last packet successfully received from the server was 106,383
>> milliseconds ago. The last packet sent successfully to the server was 26
>> milliseconds ago.
>>
>> This I understand is occurring due to the wait_timeout that's set to 10
>> seconds.
>>
>
> Have you tried changing the wait_timeout? That's your best option, IMO.
> 10 seconds is just ridiculous. The wait_timeout is supposed to be used to
> check for actual connection failure, what are the odds of connection
> failure happening in 10 seconds?
>
>
>> I am using DB.disconnect at the end of every thread(in after "/*" do
>> block) and I thought this would close the connection in use by that thread.
>> This claerly is not happening.
>> One solution the I can think of is putting a dummy query at the start of
>> every thread(in the before "/*" block). But is there a way to get this
>> handled by Sequel itself.
>>
>
> Are you using the sharded connection pool as I mentioned in an earlier
> message? If not, it's possible that by the time you call disconnect in
> after, another thread is using the connection, so it wouldn't be
> disconnected. In Sequel, connections are only assigned to a thread for the
> minimum amount of time required. If you do:
>
> 2.times{DB[:table].all}
>
> There are no guarantees that the same connection will be used for both
> queries.
>
> If you really want to force all queries for a given web request to use the
> same connection, add a rack middleware that uses Database#synchronize to
> check out a connection for the duration of the request. Note that that
> won't fix your issues by itself, since unless you use the sharded
> connection pool, there's no way to ensure that Database#disconnect will
> disconnect the connection. To do that, you'd want to use the rack
> middleware I suggested and modify the release method of the connection pool
> to disconnect the connection instead of returning it to the pool. That may
> be another way of solving your issue. All that being said, the suggestion
> I made in an earlier message (using :servers=>{},
> :connection_handling=>:queue) is better a better solution, IMO.
>
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/y8_9YPZIyGEJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
