Opened 16 years ago
Closed 15 years ago
#4094 closed defect (fixed)
SBE failed to reconnect after MBE reboot
Reported by: | Owned by: | Isaac Richards | |
---|---|---|---|
Priority: | minor | Milestone: | 0.22 |
Component: | mythtv | Version: | 0.20-fixes |
Severity: | high | Keywords: | |
Cc: | Ticket locked: | no |
Description
After re-booting the master backend, the slave backend failed to re-connect to the MBE. From the log it appears that it connected to itself. From looking at the code, this shouldn't happen because it should get the correct value from the settings cache. The cache only gets cleared around the call to update the schema.
So if the first connection to the MBE socket happens before the schema upgrade happens, and it doesn't try again until it needs to reconnect after a failure, and the database is unavailable, then it would use the default of localhost.
I'll turn on database logging and see if I can re-create it, but it would only happen if it tried to grab the value during the time when the database was offline.
It might be an idea to reload the cache with the master's IP and port and maybe a few other key values after turning it back on, if I'm correct about the cause.
Attachments (2)
Change History (8)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Ok, so, mythfilldatabase tells the backends to clear the settings cache (as well as exiting the settings menu). So here's a little patch to reload the master server IP and port after clearing the cache. I'll let you know how it works.
Changed 16 years ago by
Attachment: | reconnect.patch added |
---|
comment:3 Changed 16 years ago by
On further reflection, I don't think re-loading the cache is the right way to do it. Perhaps the proper solution is to change MythContext::ConnectToMasterServer? to NOT use localhost as a default. Is there any situation where ConnectToMasterServer? should succeed if it can't fetch the proper address from the database?
Another thing. If I'm reading MythContext::GetSetting? correctly, it looks like it puts the default value into the settings cache even if the database is unavailable. So any call to GetSetting? when the database is unavailable will poison the settings cache. This should probably be changed so it only does this if the setting really isn't in the settings table
comment:4 Changed 15 years ago by
Milestone: | unknown → 0.22 |
---|---|
Status: | new → infoneeded_new |
Still an issue with trunk? Or even 0.21-fixes?
comment:5 Changed 15 years ago by
You've already fixed the bug with loading default values in the settings cache. The only thing I'm doing different than in 0.21-fixes is that MythContext::ConnectToMasterServer? uses "" as a default, rather than localhost. It doesn't break anything, at least in my setup, and I think is more correct.
comment:6 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | infoneeded_new → closed |
Well, it doesn't grab the MasterServerIP untill after it checks for database update, so there goes that theory out the window.