Changes between Initial Version and Version 1 of Ticket #546
- Timestamp:
- 2008-12-09T18:45:53Z (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #546 – Description
initial v1 10 10 11 11 * problem 1: mapupdate(MODE_WRITE) triggers on 1000, when it should use 1000$ 12 (to avoid triggering on 10001) 12 (to avoid triggering on 10001) (ticket #547) 13 13 14 14 * problem 2: the mapupdate can hit a false boundary because the inserted gap 15 15 was too large. It might be a good idea to increase epsilon for MODE_WRITE 16 to reduce the chance of this. 16 to reduce the chance of this. (ticket #549) 17 17 18 18 * problem 3: when mapupdate hits a false boundary (because of either of the … … 20 20 actually already have them. The code looks for these "surprise" shares and 21 21 raises UCWE if it sees them. The UCWE is probably inappropriate, instead a 22 new writev should be sent to update the old share. 22 new writev should be sent to update the old share. (this ticket, #546) 23 23 24 24 * problem 4: delete() which hits UCWE (because of problem 3, or other issues) 25 25 will retry, but will fail the second time because must_exist=True is the 26 default 26 default (ticket #550) 27 27 28 28 … … 91 91 servers) is incorrectly triggered (the pattern-match looks for "1000" but it 92 92 should really look for "1000$", to avoid matching on "10001"). But that is in 93 a different ticket .93 a different ticket (#547). 94 94 95 This ticket is about the fact that inserting a large batch of new servers can 96 confuse the boundary-matching code. 95 This ticket is about the fact that the publish process doesn't keep track of 96 which shares it's sent to whom, so if it needs to make a second pass (to 97 place shares that were not accepted by their first destination), it will get 98 confused and signal an inappropriate UCWE. 97 99 98 100 When a single new server is added, it is effectively inserted at a random