On Sat, Feb 17, 2007 at 07:35:51PM +0100, bbackde at googlemail.com wrote: > Then we should do this always:
I don't see that it matters that much; as long as we check in onSuccess, onFailure, and when queueing (iirc we check isCancelled in the scheduler?), we'll catch it fast enough. > e.g. in ClientGet alot of methods (like > onFailure, receive) have this as the first line: > if(finished) return; > > This is what I added to the progress sender too. Should we really > write a log message each time we return because the request is > finished? The objective is to get notified (as an error) if requests aren't finishing properly. Is this reasonably achievable? > > On 2/14/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > On Wed, Feb 14, 2007 at 06:59:58PM +0100, bbackde at googlemail.com wrote: > > > All code (http client and external clients) end up in a call of > > > FcpClient.removeByIdentifier with kill=true. The request is removed > > > from any queues. Then req.cancel is called, which finally results in > > > ClientRequester.cancel. This method doesn't do anything except > > > "cancelled = true;". > > > > Some places do check isCancelled(). I have added several more. Also > > ClientGetter and ClientPutter override this to try to cancel the request > > immediately, but this will not always work because of things like > > multi-level metadata and container fetches. However with recent changes > > the cancel should take effect more or less immediately as we now check > > on both success and failure on block fetches and inserts. > > > > > Could you check, or give us some advise, how this > > > works? Do all splitfile requester/inserter check for this? If they are > > > blocked in a transfer, it would be normal if they finish later and > > > maybe send a SimpleProgress. The queue itself should not contain this > > > request any longer, and it is not stored to the disk file as mentioned > > > in bug 608. I assume this is a normal behavior if you not cancel the > > > running blocking transfers of the single blocks. But I didn't write > > > this code and I'm not sure, please advise. > > > > With the above changes it should work okay. However somebody will need > > to put a warning log in when we are about to generate a > > SimpleProgressMessage but suppress it because the request is finished. > > > > > > On 2/14/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote: > > > > I meant MY code is finished, I did'nt care about the other bugs ;) > > > > and the recent reports about this or that failing are with the current > > > > 1015 and there is no change from me in this version... My change only > > > > masks the SimpleProgress messages from bug 608, but the bug itself is > > > > in the node since a much longer time. > > > > > > > > I will help to debug the problems in the next days. > > > > > > > > > > > > On 2/14/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > > > > On Wed, Feb 14, 2007 at 08:08:11AM +0100, bbackde at googlemail.com > > > > > wrote: > > > > > > Tese issues were fixed when you wrote this mail, you missing my > > > > > > follow > > > > > > up mail? A layout like googlemail provides for mails helps alot to > > > > > > keep up to date with all recent follow ups ;) > > > > > > > > > > > > imho the code is finished, you could review it and maybe release it. > > > > > > > > > > It's not finished. See bug #608 (inserts continue after being > > > > > supposedly > > > > > cancelled and the node masks this!), and the numerous recent reports > > > > > about downloads being broken. I'm trying to sort out the bug reports > > > > > and > > > > > will then see if I can replicate and debug the latter. I don't think > > > > > we > > > > > should release a new build until at the very least the node logs an > > > > > error when it suppresses a SimpleProgress. > > > > > > > > > > > > On 2/14/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > > > > > > On Mon, Feb 12, 2007 at 06:58:52PM +0100, bbackde at > > > > > > > googlemail.com wrote: > > > > > > > > If I run 2 FCP2 clients (frost) then I see PRModified and > > > > > > > > PRRemoved > > > > > > > > messages if the other client changes the global queue. But if I > > > > > > > > change > > > > > > > > the priority in fproxy, or remove the request in fproxy, no > > > > > > > > message is > > > > > > > > sent to the clients. How does fproxy access the global queue, > > > > > > > > some > > > > > > > > special path??? > > > > > > > > > > > > > > It shouldn't... FCPServer.removeGlobalRequest, > > > > > > > fcp.getGlobalRequests() > > > > > > > and then call functions on them etc. Maybe these should be wrapped > > > > > > > better for proper internal use. It's all called from > > > > > > > QueueToadlet.handlePost, have a look at it. > > > > > > > > > > > > > > > > Another observation: I added a new upload request into the > > > > > > > > global > > > > > > > > queue using frost. Then I removed the request using fproxy. No > > > > > > > > PRRemoved was sent, but after next ListPR from Frost the request > > > > > > > > disappeared. But then the node started to send SimpleProgress > > > > > > > > messages > > > > > > > > for the removed requests, it looks like the request wasn't > > > > > > > > really > > > > > > > > deleted. Did it continue to run in the background? No client > > > > > > > > (including fproxy) showed the request. > > > > > > > > > > > > > > That I have seen, it's some kind of bug. Are you sure it's not > > > > > > > caused by > > > > > > > your recent changes? The request does get cancelled? > > > > > > > > > > > > > > > > This was with the latest SVN code... > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > > > > > > > > > iD8DBQFF0mjQA9rUluQ9pFARAkeEAJ0cGNDYZMmccNmx1wSq9ATmaI3TCwCglISq > > > > > > > utlwYumsz/vIsMlqeuEDqSU= > > > > > > > =AOVh > > > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Devl mailing list > > > > > > > Devl at freenetproject.org > > > > > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > > _______________________________________________ > > > > > > Devl mailing list > > > > > > Devl at freenetproject.org > > > > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > > > > > iD8DBQFF0z7SA9rUluQ9pFARAjq9AJ9WM+DhhaS8aLSW53UWRoz2SkbJCgCgn9oJ > > > > > DzUk4c0tkoJN1EloJ+Lu2K0= > > > > > =1ysv > > > > > -----END PGP SIGNATURE----- > > > > > > > > > > _______________________________________________ > > > > > Devl mailing list > > > > > Devl at freenetproject.org > > > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > > > > > > _______________________________________________ > > > Devl mailing list > > > Devl at freenetproject.org > > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > iD8DBQFF03JyA9rUluQ9pFARAm/bAJ9c+QNaFtrLH7I8R3Hy9M0aTe4mtACfdbwa > > 1+YbjYXH+F8GbIGQgS461QA= > > =hD3f > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070217/a513a43a/attachment.pgp>
