BIND 10 #1356: Simultaneous transfers fail with Sqlite3 data source

BIND 10 Development do-not-reply at isc.org
Sat Jan 5 02:01:45 UTC 2013


#1356: Simultaneous transfers fail with Sqlite3 data source
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  low           |                    Milestone:
           Component:  xfrin         |  Sprint-20130108
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  High
Estimated Difficulty:  3             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:3 shane]:
 > Does this still happen? This exception should be caught properly. Jelte
 says he still sees lock errors.

 lock error should still happen, and we cannot do anything about it
 because it's a restriction of SQLite3.  But, as you also noted,
 the ugly failure mode should now be fixed, and I guess it's actually
 better than reducing the default value of max-transfers, at least
 unless also tweaking zone manager.  As far as I can see, the zone
 manager simply forgets the result if the request for a zone transfer
 immediately fails.  On the other hand, a transfer failure, including
 the one due to the above lock error, is reported to the zone manager,
 and it reschedules a next transfer within a relatively short period.

 We could tweak the already-so-broken zone manager to make it better,
 but I'm not sure if it was originally intended in the scope of this
 ticket.

 My suggestion for this ticket is either:
 - just do nothing, or
 - simply update detailed version of log message, explaining if the
   failure is due to DB lock error, it can happen with SQLite3, and not
   a critical problem.

 For a longer term, we should overhaul the zone manager, and (I guess)
 also introduce the concept of "datasrc capability" so the app (like
 xfrin) can choose an appropriate default for a specific parameter like
 max-transfer depending on the value.  At that point, the default
 max-transfer for SQLite3 datasrc would be set to 1.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1356#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list