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 > -------------- 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/20070214/f038300a/attachment.pgp>
