> From: Oskar Sandberg <md98-osa at nada.kth.se> > Reply-To: freenet-dev at lists.sourceforge.net > Date: Mon, 24 Apr 2000 00:48:34 +0200 > To: freenet-dev at lists.sourceforge.net > Subject: Re: [Freenet-dev] Build 120 -- Mac bug. > > On Fri, 14 Apr 2000, Paul Kappler wrote: > <snip> >> You are correct line 71 SHOULD setSoTimeout back to zero. It seems it does >> not. If comment out line 71 the problem disappears. Its very repeatable >> but only on a mac. This is why I thought it might be a JVM bug. >> >> If a stream dies won't it throw an exception from the read or write within >> the message handlers or conduit? It would if we set a long SO_Timeout. >> Maybe 5 min? > > I see now that you misunderstood me when I said to change this. I meant to > change that the second time the SoTimeOut is set it is set to something like > 10 > minutes (rather then 0 which the mac seemed to choke on), it still needs to be > short for that loop. > > I did it this way now, does that reintroduce this bug on the Mac?
Yup, I can't insert large files to servers that are not "near me" again. It seems the Mac only acknowledges the first setSoTimeout. I get the same error as before. I need to wonder why we don't just setSoTimeout to Core.connectionTimeout. It would fix the problem save a little CPU. Maybe by some command option to fix this problem. You said there is no way to tell if a stream dies except by reading it. I don't think you would know if the stream dies any later if you had the full connection timeout for soTimeout. I think a dead connection ought to return -1 when the computer knows its dead. Does this deserve a timeout testing program and along with some yanking cables out of the switch? So much for the platform independence of this aspect of Java. :) Paul Note: Node does not compile right now without some exception hacking. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
