[mythtv-users] 'Wakeup' Delay on Idle Frontend

[Jim Stichnoth]

On Wed, Dec 23, 2009 at 9:05 AM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 12/23/2009 11:47 AM, Jim Stichnoth wrote:
>>
>> On Wed, Dec 23, 2009 at 5:28 AM, Jim Stichnoth <stichnot at gmail.com> wrote:
>>
>>>
>>> I wonder if this is due to changeset 17834
>>> (http://svn.mythtv.org/trac/changeset/17834) which added the
>>> MDBManager::PurgeIdleConnections() function.  This function is run
>>> when a new DB connection is initiated, and "cleans up" items in the DB
>>> connection pool that have been idle for at least 1 hour.  Presumably
>>> some interaction between Myth, QT, and MySQL is causing this.
>>>
>>> I can try a few things:
>>>
>>> * Disable the PurgeIdleConnections() function.
>>>
>>
>> This seems to make the problem go away.  Specifically, I just put a
>> "return;" statement at the beginning of void
>> MDBManager::PurgeIdleConnections() and I did not see the problem
>> again.  Of course, that allows the problem addressed in changeset
>> 17834 to come back.
>>
>
> Now (with PurgeIdleConnections() disabled), get MySQL to timeout
> connections:
>
> http://www.gossamer-threads.com/lists/mythtv/users/372194#372194
> http://www.gossamer-threads.com/lists/mythtv/users/383430#383430
> http://www.gossamer-threads.com/lists/mythtv/users/389517#389517
>
> (especially interesting to this thread is the last para of that last
> post--"I've heard reports that some versions of MySQL/MySQL libs/Qt-MySQL
> drivers/something cause huge delays when Myth needs to reconnect.")
>
> I'll bet you'll see the same behavior.

Just to be clear, I wasn't suggesting disabling PurgeIdleConnections()
as a solution, but rather to see if it is linked to these delays.
Apparently it is.  I'm hoping to track down the real cause of the
problem, which I suspect is some thread that is not being cleanly shut
down with respect to Qt's mysql driver.  Barring that, periodically
pruning idle connections in a separate housekeeping thread would be
better.

Interestingly, by searching for the error string in the mailing list
archives, it's clear that many people are encountering this but not
realizing that it may contribute to a 5-second delay.

Jim