On Mar 20, 2008, at 2:57 PM, Matthew Toseland wrote:

> On Thursday 20 March 2008 16:44, robert at freenetproject.org wrote:
>> Author: robert
>> Date: 2008-03-20 16:44:32 +0000 (Thu, 20 Mar 2008)
>> New Revision: 18643
>>
>> Modified:
>>   trunk/freenet/src/freenet/node/RequestHandler.java
>> Log:
>> comments
>>
>>
>> Modified: trunk/freenet/src/freenet/node/RequestHandler.java
>> ===================================================================
>> --- trunk/freenet/src/freenet/node/RequestHandler.java       2008-03-20  
>> 16:42:11
> UTC (rev 18642)
>> +++ trunk/freenet/src/freenet/node/RequestHandler.java       2008-03-20  
>> 16:44:32
> UTC (rev 18643)
>> @@ -266,6 +266,7 @@
>>              case RequestSender.INTERNAL_ERROR:
>>                      // Locally generated.
>>                  // Propagate back to source who needs to reduce  
>> send rate
>> +                                    ///@bug: we may not want to translate 
>> fatal timeouts into non- 
>> fatal
> timeouts.
>
> Not sure I follow... This isn't usually caused by a timeout.

Looks like it is to me (the TIMED_OUT case which is clipped off the  
top of the diff).

 From RequestSender:
if(msg == null) {
        Logger.normal(this, "request fatal-timeout (null) after accept  
("+gotMessages+" messages; last="+lastMessage+")");
        // Fatal timeout
        next.localRejectedOverload("FatalTimeout");
        forwardRejectedOverload();
        finish(TIMED_OUT, next, false);
        node.failureTable.onFinalFailure(key, next, htl,  
FailureTable.REJECT_TIME, source);
        return;
}

 From RequestHandler:
case RequestSender.GENERATED_REJECTED_OVERLOAD:
case RequestSender.TIMED_OUT:
case RequestSender.INTERNAL_ERROR:
        // Locally generated.
        // Propagate back to source who needs to reduce send rate
        ///@bug: we may not want to translate fatal timeouts into non-fatal  
timeouts.
        Message reject = DMT.createFNPRejectedOverload(uid, true);
        sendTerminal(reject);
        return;

So.... TIMED_OUT (a fatal timeout) is (or can be) translated into a  
RejectedOverload (non-fatal). I guess it's not an issue with the  
'responseDeadline' code?

--
Robert Hailey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080321/e97534a1/attachment.html>

Reply via email to