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, 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?
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20080321/6963aadf/attachment.pgp>
