[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2034: Update for mutable files is sensitive to the number of servers

[Tahoe-LAFS]

#2034: Update for mutable files is sensitive to the number of servers
------------------------------+-------------------------------------------
     Reporter:  markberger    |      Owner:  warner
         Type:  defect        |     Status:  new
     Priority:  normal        |  Milestone:  1.10.1
    Component:  code-mutable  |    Version:  1.10.0
   Resolution:                |   Keywords:  review-needed mutable publish
Launchpad Bug:                |
------------------------------+-------------------------------------------

Comment (by warner):

 Ok, I think the patch is a step forward. It basically changes the point at
 which we say "yes, this server gave us a good share". It used to set this
 mark as soon as the first response came back (saying "I *think* I have a
 share, fetch it if you want"). With the patch, it sets the mark later,
 after enough of the share has been fetched to verify its signature. In
 between those two points, the client is grabbing more data (the pubkey,
 maybe more), so there's a chance for other code to run, including the "are
 we done yet" checker. The problem here occurred when that other code ran
 too early.

 I have a feeling that the entire mutable tree is due for an overhaul.
 Although I can't currently think of any better way to organize it. Mostly
 I'm bothered by the large Deferred chains in there, and maybe a state
 machine (like the "new" immutable downloader) would provide fewer hiding
 places for concurrency/interleaving hazards to lurk.

 Landed in db12f1c.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2034#comment:18>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage