[freenet-dev] [freenet-cvs] r16635 - trunk/freenet/src/freenet/node

Robert Hailey robert at emu.freenetproject.org
Mon Dec 17 17:44:57 UTC 2007


On Dec 17, 2007, at 11:35 AM, Florent Daignière wrote:

> * Robert Hailey <robert at emu.freenetproject.org> [2007-12-17 11:07:55]:
>
>>
>> On Dec 16, 2007, at 6:11 PM, nextgens at freenetproject.org wrote:
>>
>>> Author: nextgens
>>> Date: 2007-12-17 00:11:57 +0000 (Mon, 17 Dec 2007)
>>> New Revision: 16635
>>>
>>> Modified:
>>>  trunk/freenet/src/freenet/node/RequestHandler.java
>>> Log:
>>> Fix a silly bug which might have weird effects
>>>
>>> Modified: trunk/freenet/src/freenet/node/RequestHandler.java
>>> ===================================================================
>>> --- trunk/freenet/src/freenet/node/RequestHandler.java	2007-12-17
>>> 00:11:18 UTC (rev 16634)
>>> +++ trunk/freenet/src/freenet/node/RequestHandler.java	2007-12-17
>>> 00:11:57 UTC (rev 16635)
>>> @@ -246,13 +246,13 @@
>>> 				} else {
>>> 					sendTerminal(df);
>>> 				}
>>> -				return;
>>> 			} else {
>>> 				if(!rs.transferStarted()) {
>>> 					Logger.error(this, "Status is SUCCESS but we never started a
>>> transfer on "+uid);
>>> 				}
>>> 				// Wait for transfer to start
>>> 			}
>>> +			return;
>>>            	case RequestSender.VERIFY_FAILURE:
>>>            		if(key instanceof NodeCHK) {
>>>            			if(shouldHaveStartedTransfer)
>>>
>>
>> I'm not so sure... when I was reviewing the code earlier the comment
>> "wait for transfer to start" made me think this was intentional.
>> Specifically, that the code will loop and consider it again?
>>
>> Certainly returning immediately is not waiting for the transfer to
>> start, although... as written it would simply run on into the
>> VERIFY_FAILURE action
> ...
>
> Which is sending an FNPRejectedOverload message... That's definitly  
> not
> what we want to do in that case.
>
> Let's "continue" instead... see r16659
>
> NextGen$

I'm still confused by that comment. If we continue & loop, will the  
status ever change from SUCCESS? And why is this behavior so much  
different from a SSK block?

--
Robert Hailey




More information about the Devl mailing list