[Twisted-web] adpapi cp_reconnect problem

Werner Thie wthie at thiengineering.ch
Wed Oct 10 14:17:55 EDT 2007


Thxs Phil

Starting with V5 MySQL docs state, that there is no way to switch off 
the disconnects at all security reasons). One funy recipe I found was a 
guy stating that his provider reboots the servers every 24 hours, so he 
was setting disconnect timeouts to some value slightly bigger than 24 :-(

I hesitated to have a periodic SELECT 1; but if this is the way to go, 
why not?

I do not really have a problem when the exception bubbles up after a 
rerun of the query, moreover in this case I am interested in the 
exception, which could be handled at some outer level.

After some staring at my own code and being hit by the exception again 
it looks like the try/except should be around the actual code running 
the query, not in the setup of the interaction.

Werner

Phil Christensen wrote:
> On Oct 10, 2007, at 1:02 PM, Werner Thie wrote:
>> Hi all
>>
>> From what I was able to google and what I could deduce from the 
>> source/docs this is what I think the right way to get reconnects after 
>> all:
>>
>> def runQuery(self, query, *args):
>>   try:
>>     d = self.pool.runInteraction(self.mapQuery, query, args)
>>   except adbapi.ConnectionLost:
>>     #simply resend query, assuming cp_reconnect=True
>>     d = self.pool.runInteraction(self.mapQuery, query, args)
>>   return d
>>
>> Am I on the right track?
> 
> Is this intended to be kept in a trivial subclass of ConnectionPool? I 
> think I'd want to avoid that...
> 
> The only issue that could arise here is that subsequent connections 
> might also be down. In a similar app I'm working on, my pool might have 
> 5-10 broken connections if it's been sitting unused for awhile. Although 
> ConnectionPool will remove the broken connection instances when they 
> raise ConnectionLost, your followup query could also raise the same 
> exception.
> 
> I would hesitate to put the code in some kind of loop, since it's 
> difficult to tell at this point (i.e., in runQuery) **why** the 
> connection is lost, and how critical that fact is to the rest of the 
> application
> 
> I think the approach I'm going to take is to create a separate delayed 
> event loop that periodically runs "SELECT 1;" or similar every hour or 
> so. This will keep the connections live, and in the event that one of 
> them goes down for some other reason, it will make sure they are removed 
> from the pool.
> 
> Of course, the best solution would be to figure out how to turn off 
> those disconnects in MySQL, but I haven't had much luck finding that 
> info in the endless quagmire of mysql.com documentation.
> 
> -phil
> 
> _______________________________________________
> Twisted-web mailing list
> Twisted-web at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web



More information about the Twisted-web mailing list