On Friday 03 July 2009 22:45:40 sashee wrote:
> >
> > - if (fr.isFinished()) {
> > + if (fr.isFinished() || fr.hasData() || fr.failed != null) {
> >
> > Is it possible for fr.isFinished to be false when fr.hasData is true or
> > fr.failed is non-null? (I'm not saying take it out, but is isFinished()
> > buggy or am I missing something?)
>
> It solved most of the stalled at 100% bugs for me, so I suspect the
> finished has some bugs.
>
> >
> > If you think the code is working, you should post a jar somewhere and ask
> > for wider testing on devl.
> >
> > Blocks seems to get reset to 0 / 0 after a while at 100%, any ideas why?
>
> I didn't experienced it yet. Will test further.
>
> >
> > "ETA: -9s" is probably not what we want. :)
>
> It happens when the start of the file progresses fast, then slows
> down, eg if it's in the store. Well, it should stop at 0:)
>
> > And I did get one page to stall. It was in the datastore and loaded
> > instantly when I clicked on the url and pressed enter, but until that point
> > it went nearly 3 minutes without progress, showing 0 / 1 blocks and
> > updating only the time counter.
> >
> > The URL was this, but I doubt it's a problem with the page.
> > http://127.0.0.1:8888/freenet:u...@mjbn3mnx5j5xoa-osoccjtwrvtwj5r52wn4xtkw64yq,NYAzL61qMPrAYC8B7Anpwx8h7CPYzBnpJIZNVgnR1rU,AQACAAE/Chaosradio/43/ChaosradioExpress/index.html
>
> Will investigate it too. Don't think it is page specific though.
>
> By the way, I noticed something interesting. At FProxyFetchTracker 's
> run() method, if I'm not mistaking, it cancels all cancellable
> fetches. If it is, then listening for an already removed Progress
> object makes no event. Is this the way it should work?Well, it shouldn't be cancellable if there are listeners ... is it? This was put in to garbage collect requests which are no longer being polled for; the javascript code makes it obsolete, but in the case where the javascript isn't working we still need it. > > > I had a different problem with another page, a file stalled close to the > > end, showing no new blocks, no failures, but when I reloaded it showed a > > MIME type warning page instantly. I'm not sure what's going on there, it > > might be some wierd interaction with the FProxy fetch code. Nothing obvious > > in the logs (NPEs etc). > > > > Arguably we should show the mime type warning as soon as we know the mime > > type, but it may be best to keep the current behaviour for now. > > Need to think about this one. > > > If a request is being answered from the datastore, is it possible that the > > events from that one request could overwhelm the events from the other > > requests, and thus that they might not show progress when there was > > progress? You might want to throttle events on the node side so we don't > > send more than 1 per 100ms from each request, or something? > > No, it is fixed now. If an element already generated an event, it > won't generate another one till the client grabs the first one. Every > notification needs 10-30ms to deliver, and the connection sharing > checks 100ms and has a bucket of 10messages. So it is not possible to > lose an event. Ok.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
