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/-/WWhnIrJ3NXkJ.
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.
