Re: [core-dev] HashTree.isCorrupt() returns a lot of false positives

Nice work.

Thanks
-greg
Quoting Gregorio Roper <[email protected]>:
> The problem was finally fixed by slowing down the download to the speed of
> the
> Verifying.
>
> I removed the ProcessingQueue from the VerifyingFile and I'm now doing all
> the
> writing and verifying in the downloader thread again (except for the
> verifying when a new HashTree has been set). It's a little blunt, I admit,
> but it has the considerable advantage of working even when you are
> downloading at speeds >> 1MB/s.
>
> And it prevents those nasty OutOfMemoryErrors that pop up when the
> ProcessingQueue is forced to hold several MBs of unwritten data.
>
> My, my, - it is late.
>
> mfg
> gregorio
>
> Am Dienstag, 5. Juli 2005 14:16 schrieb Gregorio Roper:
> > Since nobody here using a Windows machine could verify this problem, this
> > seems to be plattform specific.
> >
> > mfg
> > gregorio
> >
> > Am Dienstag, 5. Juli 2005 12:08 schrieb Gregorio Roper:
> > > When transferring files at speeds > 1MB/s ( a lot faster than we can
> > > verify them) I noticed that I would loose up to 50% of all chunks to
> > > corruption. If I however turned of the HashTree verifying, the sha1 would
> > > still match.
> > >
> > > This is possibly nothing LimeWire can directly influence. I have a hunch
> > > that one of Linux / Java / ReiserFS is actually responsible for what I am
> > > seeing because I can't find anything else that could cause a chunk to be
> > > verified correctly once and then not verified when I try the next time.
>
> --
> mfg
> gregorio roper
> _______________________________________________
> core-dev mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/core-dev
>



_______________________________________________
core-dev mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/core-dev