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

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