View Issue Details

IDProjectCategoryView StatusLast Update
0000750LDMud 3.3Runtimepublic2011-02-23 23:22
Reporterfufu Assigned Tofufu  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Version3.3.718 
Target Version3.3.720Fixed in Version3.3.720 
Summary0000750: pkg-mysql: "MySQL server has gone away" errors on long-lived db connections
DescriptionIf a long-lived database connection goes idle for too long, executing statements on the handle will abort with a "MySQL server has gone away" error. This happens since mysql-5.0.3, which changed the default for db handles for automatic reconnects from on to off.

I'm proposing to restore the pre-mysql-5.0.3 behaviour by explicitely switching on reconnects using

my_bool true = MY_TRUE;
mysql_options(tmp->mysql_dat, MYSQL_OPT_RECONNECT, &true);

after the mysql_real_connect(...) call.

Are there any objections to this change?
TagsNo tags attached.



2010-04-30 17:35

administrator   ~0001862

I don't think I object. Was there a special reason, why this default was changed by the MySQL guys?


2010-05-02 03:35

manager   ~0001863

As far as I understand, the reason they changed it was that on reconnect, all session settings (as modified with the SET statement) and temporary tables are lost. Letting this happen silently is a bad default.

On the other hand, automatic reconnects are very convenient if you do not rely on such state.

I'll document the fact that reconnects may happen silently if/when I make this change.

As an alternative, we could provide a db_options function exposing this setting, so every MUD can deal with this matter as appropriate. But I'd only do this if anybody actually cares about session state.


2010-05-02 10:44

administrator   ~0001864

Uh, that sounds really like a bad default in general.
Currently I don't really know if I would care about the session state, because we don't use pkg-mysql.
I could imagine creating temporary tables for data which should be discarded once the object gets destroyed, but then it sounds not like a good idea in the first place because of the possible disconnects and it is probably anyway better to keep it in the driver's memory.
So, I guess, I don't mind the silent loss of session state right now.


2010-05-04 11:03

manager   ~0001866

committed as r2917 (3.5 branch) and r2918 (3.3 branch)

Issue History

Date Modified Username Field Change
2010-04-30 09:46 fufu New Issue
2010-04-30 09:46 fufu Status new => assigned
2010-04-30 09:46 fufu Assigned To => fufu
2010-04-30 17:35 zesstra Note Added: 0001862
2010-05-02 03:35 fufu Note Added: 0001863
2010-05-02 10:44 zesstra Note Added: 0001864
2010-05-04 11:03 fufu Note Added: 0001866
2010-05-04 11:03 fufu Status assigned => resolved
2010-05-04 11:03 fufu Resolution open => fixed
2010-05-04 13:14 zesstra Project LDMud => LDMud 3.3
2010-05-04 13:15 zesstra Fixed in Version => 3.3.720
2011-02-23 23:22 zesstra Target Version => 3.3.720