View Issue Details

IDProjectCategoryView StatusLast Update
0001494Anope Development (1.9.x series)IRCD Supportpublic2013-03-18 19:19
ReporterCuttingEdge Assigned ToAdam  
Status resolvedResolutionfixed 
Platformx86_64OSUbuntu Linux 
Summary0001494: Upstream timeout when using MySQL with flatfile database on boot.
DescriptionIf I enable both the 'db_flatfile' and 'db_sql' modules on boot, Anope takes too long to run through its database tables, resulting in a timeout when trying to connect to its upstream server.

From what I can tell, it starts the connection to the upstream server first (it opens the socket, but doesn't send anything), then starts to generate tables, etc, and because it takes quite a while, the upstream server considers the incoming connection as not one being registered within the stipulated time frame, and disconnects the connection from Anope before it is able to complete the handshake.

It could just be the size of my database.

I'd suggest changing the sequence within Anope, so that only once all the tables are generated (and data propagated) in MySQL, that it attempt to connect to the upstream server.
Steps To Reproduce1) Enable both 'db_flatfile' and 'db_sql' database modules.
2) Start Anope.
Additional InformationThe disks on the machine are SSD drives, so it can't be a disk IO issue.

Using latest Anope 1.9.9 GIT.
Using InspIRCd 2.0.10.
TagsNo tags attached.



2013-03-18 19:19

administrator   ~0006406

The upstream timeout is actually intentional on large databases (it is trickier than waiting and opening the socket later). However, db_sql wasn't supposed to re-import everything on load if it is already imported. Because this should only possibly happen on the first import I don't think it's that big of a deal.

Your setup however makes it impossible to tell if things are already imported, so I've added a configuration option to tell db_sql whether or not to import stuff. If you keep imported at false now it will no longer re-import things on startup, and start much faster.

Fixed in 731912f01eb14d811575c492dc64b60084bd412c.

If you're going to keep reporting bugs like this you should really idle in, it can help.


Issue History

Date Modified Username Field Change
2013-03-18 06:59 CuttingEdge New Issue
2013-03-18 19:19 Adam Note Added: 0006406
2013-03-18 19:19 Adam Status new => resolved
2013-03-18 19:19 Adam Resolution open => fixed
2013-03-18 19:19 Adam Assigned To => Adam