[freenet-support] Problem with Freemail plugin
Try the freemail mailing list. On Thursday 10 January 2008 22:35, Ermanno Baschiera wrote: > Hi all, > I loaded the Freemail plugin into Freenet (just to learn something > about it), but I'm having some issues... > I got Freemail listed in the plugin list, but if I "visit" it, it > tells "Plugin not found!". > Then I tried to Unload it, but the operation never gets completed (the > browser still loads the page, but it goes timeout). > Additionally, in my logs there's plenty of this: > "Jan 10, 2008 22:10:06:808 (freemail.fcp.HighLevelFCPClient, Scheduled > job: freenet.pluginmanager.PluginHandler$PluginStarter at 16e4ff1, > ERROR): Warning - no connection to node. Waiting..." > It seems that every 5 seconds, that error happens. > > I tried also to rm Freemail.jar.url from /plugins, but it gets redownloaded. > > Can anyone help me please? > > Thanks a lot. > > -ermanno baschiera > ___ > Support mailing list > Support at freenetproject.org > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:support-request at freenetproject.org?subject=unsubscribe > > -- 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/support/attachments/20080111/d6fd4a5a/attachment.pgp>
[freenet-support] Global download queue logic?
On Thursday 10 January 2008 22:27, Victor Denisov wrote: > |> I can retrieve most pictures on the queue through Fproxy, and they > |> usually took no more than 10-15 seconds to show up. However, those same > |> files sit in the queue for more than 5 days (the node was up almost > |> 24x7, save for reboots and just a couple of hours of outage), with > |> various degrees of progression (mostly, 50-70%). Some hadn't been > |> touched at all, it seems (they're completely gray, with italicized 0% > |> progress). > | > | Possibly a bug - when you visit them in fproxy, the node should > immediately > | pass them along to the waiting clients. > > Is there anything I can do to help troubleshoot this problem? Also, I > feel there are two independent problems here: > > - files being retrieved by Fproxy not made available to other clients in > a reasonable time; > - files not being completely downloaded by the queue manager in about 5 > days, then successfully retrieved by Fproxy in a matter of seconds; > > Is there anything I can do to help troubleshoot this? > > Also, I think there's a definite lack of information on the queue page > (see below). > > |> Is that an expected behavior? How does the node choose what block of > |> what file to download next? Does it try local cache first? Could it be > |> that large files (with lots of blocks) choke small files? > | > | No, it should round-robin between them.. if it's tried them lots of > times and > | not got anywhere, or if they are at a lower priority, they may not be > | attempted for ages. > > Hmm. Interesting. All files were at "low" priority, set by default by > Thaw. Is that ok, or should I set default priority to be higher? > > To better understand how the queue fares, I think the following > information would be helpful: > > - average availability of each queue item (total number of blocks > retrieved divided by the total number of block retrieval attempts); > - total number of download attempts for the item; > - items which are being retrieved right now; > - timestamps related to the item (entered queue, first successful block, > last successful block, last retrieval attempt); > > Perhaps, in "simple" mode, the above can be summed into a generalized > "availability" metric (i.e., "good", "average", "poor", "unretrievable"). > > Is there a way to gather such information post mortem, from the log > files? Should I increase logging level to achieve this? > If not, perhaps I can try and see if I'll be able to understand how the > queue manager works, to add this functionality - where should I start > looking? We accept patches. We even give out SVN access reasonably easily. > > Regards, > Victor Denisov. -- 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/support/attachments/20080111/54f99220/attachment.pgp>
[freenet-support] Global download queue logic?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 |> I can retrieve most pictures on the queue through Fproxy, and they |> usually took no more than 10-15 seconds to show up. However, those same |> files sit in the queue for more than 5 days (the node was up almost |> 24x7, save for reboots and just a couple of hours of outage), with |> various degrees of progression (mostly, 50-70%). Some hadn't been |> touched at all, it seems (they're completely gray, with italicized 0% |> progress). | | Possibly a bug - when you visit them in fproxy, the node should immediately | pass them along to the waiting clients. Is there anything I can do to help troubleshoot this problem? Also, I feel there are two independent problems here: - - files being retrieved by Fproxy not made available to other clients in a reasonable time; - - files not being completely downloaded by the queue manager in about 5 days, then successfully retrieved by Fproxy in a matter of seconds; Is there anything I can do to help troubleshoot this? Also, I think there's a definite lack of information on the queue page (see below). |> Is that an expected behavior? How does the node choose what block of |> what file to download next? Does it try local cache first? Could it be |> that large files (with lots of blocks) choke small files? | | No, it should round-robin between them.. if it's tried them lots of times and | not got anywhere, or if they are at a lower priority, they may not be | attempted for ages. Hmm. Interesting. All files were at "low" priority, set by default by Thaw. Is that ok, or should I set default priority to be higher? To better understand how the queue fares, I think the following information would be helpful: - - average availability of each queue item (total number of blocks retrieved divided by the total number of block retrieval attempts); - - total number of download attempts for the item; - - items which are being retrieved right now; - - timestamps related to the item (entered queue, first successful block, last successful block, last retrieval attempt); Perhaps, in "simple" mode, the above can be summed into a generalized "availability" metric (i.e., "good", "average", "poor", "unretrievable"). Is there a way to gather such information post mortem, from the log files? Should I increase logging level to achieve this? If not, perhaps I can try and see if I'll be able to understand how the queue manager works, to add this functionality - where should I start looking? Regards, Victor Denisov. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHhpvXS81Mh9/iCDgRAne7AJ9Lm8knuARbE5BL++f6gqHuP6NslwCg1Ehp VupZ5O2OYe0GRL5HoisPJXY= =fanl -END PGP SIGNATURE-
