On Jan 3, 2008, at 9:11 AM, Matthew Toseland wrote:
> Isn't sendSync() a longer timeout than the waitFor()? We could
> change that
> though, pass in a timeout..?
I think that this place is one of the few exceptions to the sendAsync-
is-better-for-acks, and that's why I changed it back. Whereas requests
are more of a 'trigger' and inserts 'pushing'... we require
information from the node anyway (the actual data insert), and we
*will* wait for it... either the 10minutes+DATA_INSERT_TIMEOUT, or
just the DATA_INSERT_TIMEOUT. So using sendSync (to absorb the time of
the send queues) really does help! Otherwise an error is propagated
back to the source (thinking that they asked for an insert & forgot
the data).
Rather than passing in a timeout, would would help more is to somehow
know if it ever made it of the queue. e.g. If it takes longer than 10
minutes, remove it from the send queue and throw a 'waited-too-long'
exception.
--
Robert Hailey
> On Friday 28 December 2007 16:51, robert at freenetproject.org wrote:
>> Author: robert
>> Date: 2007-12-28 16:51:18 +0000 (Fri, 28 Dec 2007)
>> New Revision: 16826
>>
>> Modified:
>> trunk/freenet/src/freenet/node/InsertHandler.java
>> Log:
>> less timeouts which are really disconnects
>>
>>
>> Modified: trunk/freenet/src/freenet/node/InsertHandler.java
>> ===================================================================
>> --- trunk/freenet/src/freenet/node/InsertHandler.java 2007-12-28
>> 16:50:28
> UTC (rev 16825)
>> +++ trunk/freenet/src/freenet/node/InsertHandler.java 2007-12-28
>> 16:51:18
> UTC (rev 16826)
>> @@ -91,7 +91,8 @@
>> // Send Accepted
>> Message accepted = DMT.createFNPAccepted(uid);
>> try {
>> - source.sendAsync(accepted, null, 0, this);
>> + //Using sendSync here will help the next message filter
>> not
>> timeout...
> wait here or at the message filter.
>> + source.sendSync(accepted, this);
>> } catch (NotConnectedException e1) {
>> if(logMINOR) Logger.minor(this, "Lost connection to
>> source");
>> return;
>>
>>
