Changeset dc402ac


Ignore:
Timestamp:
Mar 27, 2012 8:10:30 PM (8 years ago)
Author:
zzz <zzz@…>
Branches:
master
Children:
fbd230f
Parents:
e3dab56e
Message:
  • FloodfillVerify?:
    • Fix verifies stuck on one peer by blamimg the verify peer on failure
    • Follow DSRM in response to RI verifies, to help integration
    • Increase floodfill verify timeout
File:
1 edited

Legend:

Unmodified
Added
Removed
  • router/java/src/net/i2p/router/networkdb/kademlia/FloodfillVerifyStoreJob.java

    re3dab56e rdc402ac  
    2525 *
    2626 */
    27 public class FloodfillVerifyStoreJob extends JobImpl {
     27class FloodfillVerifyStoreJob extends JobImpl {
    2828    private final Log _log;
    2929    private final Hash _key;
     
    3333    private long _expiration;
    3434    private long _sendTime;
    35     private long _published;
     35    private final long _published;
    3636    private final boolean _isRouterInfo;
    3737    private MessageWrapper.WrappedMessage _wrappedMessage;
     
    3939   
    4040    private static final int START_DELAY = 20*1000;
    41     private static final int VERIFY_TIMEOUT = 15*1000;
    42     private static final int MAX_PEERS_TO_TRY = 5;
     41    private static final int VERIFY_TIMEOUT = 20*1000;
     42    private static final int MAX_PEERS_TO_TRY = 4;
    4343   
    4444    /**
     
    219219                    _log.info("Rcvd older data: " + dsm.getEntry());
    220220            } else if (_message instanceof DatabaseSearchReplyMessage) {
     221                DatabaseSearchReplyMessage dsrm = (DatabaseSearchReplyMessage) _message;
    221222                // assume 0 old, all new, 0 invalid, 0 dup
    222223                getContext().profileManager().dbLookupReply(_target,  0,
    223                                 ((DatabaseSearchReplyMessage)_message).getNumReplies(), 0, 0, delay);
     224                                dsrm.getNumReplies(), 0, 0, delay);
    224225                if (_log.shouldLog(Log.WARN))
    225226                    _log.warn("Verify failed (DSRM) for " + _key);
     227                // only for RI... LS too dangerous?
     228                if (_isRouterInfo)
     229                    getContext().jobQueue().addJob(new SingleLookupJob(getContext(), dsrm));
    226230            }
    227231            // store failed, boo, hiss!
    228             // For now, blame the sent-to peer, but not the verify peer
     232            // blame the sent-to peer, but not the verify peer
    229233            if (_sentTo != null)
    230234                getContext().profileManager().dbStoreFailed(_sentTo);
     235            // Blame the verify peer also.
     236            // We must use dbLookupFailed() or dbStoreFailed(), neither of which is exactly correct,
     237            // but we have to use one of them to affect the FloodfillPeerSelector ordering.
     238            // If we don't do this we get stuck using the same verify peer every time even
     239            // though it is the real problem.
     240            if (_target != null && !_target.equals(_sentTo))
     241                getContext().profileManager().dbLookupFailed(_target);
    231242            getContext().statManager().addRateData("netDb.floodfillVerifyFail", delay, 0);
    232243            resend();
Note: See TracChangeset for help on using the changeset viewer.