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

[Michael T. Dean]

On 12/23/2009 01:16 PM, Jim Stichnoth wrote:
> On Wed, Dec 23, 2009 at 9:05 AM, Michael T. Dean wrote:
>   
>> On 12/23/2009 11:47 AM, Jim Stichnoth wrote:
>>     
>>> On Wed, Dec 23, 2009 at 5:28 AM, Jim Stichnoth 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.
>   

Right.  I was just mentioning that there's another source of disconnections.

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

I don't think Greg found anything that fixed the problem, but we'd be 
very happy if you were able to.

Thanks,
Mike