On Friday 21 March 2008 15:52, Robert Hailey wrote:
>
> On Mar 20, 2008, at 2:57 PM, Matthew Toseland wrote:
>
> > On Thursday 20 March 2008 16:44, [EMAIL PROTECTED] 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?It's still likely to be fatal, because the previous node's timeout will also have expired. The problem with this is that each node on the chain will blame the next one.
pgpoJm97t8TaO.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
