14-Apr-00 7:08:17 AM:Core.java:Normal:Node running on 49193 14-Apr-00 7:08:24 AM:ConnectionHandler.java#1:Normal:cc7c39cffa0d5785 - HandshakeRequest -> tcp/24.141.52.49:19114 14-Apr-00 7:08:24 AM:ConnectionHandler.java#1:Normal:cc7c39cffa0d5785 - HandshakeReply <- tcp/24.141.52.49:19114 Kludgy handshake handling worked. Src:tcp/24.141.52.49:19114 htl:1 depth:1 id:cc7c39cffa0d5785 type:Freenet.message.HandshakeReply 14-Apr-00 7:08:24 AM:ConnectionHandler.java#1:Normal:fc2a1fc78a3e62a9 - InsertRequest -> tcp/24.141.52.49:19114 14-Apr-00 7:08:24 AM:client/InsertClient:Normal:Waiting another 25 seconds for a response 14-Apr-00 7:08:41 AM:ConnectionHandler.java#1:Normal:fc2a1fc78a3e62a9 - InsertReply <- tcp/24.141.52.49:19114 14-Apr-00 7:08:41 AM:ConnectionHandler.java#1:Normal:fc2a1fc78a3e62a9 - DataInsert -> tcp/24.141.52.49:19114 14-Apr-00 7:08:47 AM:Conduit.java:Error:java.io.InterruptedIOException: send timed out
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? What do ya think? Paul > From: Oskar Sandberg <md98-osa at nada.kth.se> > Reply-To: freenet-dev at lists.sourceforge.net > Date: Fri, 14 Apr 2000 12:53:05 +0200 (MET DST) > To: freenet-dev at lists.sourceforge.net > Subject: Re: [Freenet-dev] Build 120 -- Mac bug. > > > But there shouldn't be a timeout at all, regardless of what happens. > Line 71 in ConnectionHandler.java sets the SoTimeout value back to 0, > which means no SoTimeout. It would really be a lot easier if you > would put exact logs (without Dcompile so we can see the line > numbers) with your bug reports. > > There is already an end of stream message, or every message can be > one if it sets the option KeepAlive to false. But you need to be able > to tell whether the stream dies unexpectedly as well, and nobody > could tell me how to do that without reading off it. > > Oskar Sandberg - mail/finger md98-osa at nada.kth.se > > - > > Crypto is a human right > > On Fri, 14 Apr 2000, Paul Kappler wrote: > >> This one took a while to hunt down..... >> >> There is a Timeout problem on my Macintosh >> c.setSoTimeout(100); in connection handler causes problems. It causes >> timeouts when most insert commands are given. I found that increasing the >> value to 1000 fixed the problem for client interaction with the localhost. >> However, in if the client tries to insert a file into another computer it >> often times out in large files unless there is an extremely large value > 2 >> min. >> >> The odd thing is...it seems that the the timeout exception does not occur in >> the code to which setSoTimeout refers...instead the timeout is thrown from >> the conduit when the file is transferring. The cause of the failure on the >> Mac may be a bug in the VM or OS. I think if you set SO_Timeout once it may >> be applying it to the socket for the rest of its life. This causes problems >> if there is normal network latency and/or computer slowness during a file >> transfer. >> >> I would argue that it would help everyone to set SO_Timeout to a larger >> value, or better yet try to think of a way to do this without busy >> waiting.(Reduce CPU usage) For example, add an end of stream message or >> message flag? >> >> Until we add such a message, any released mac version will need to have >> SO_Timeout increased at the of having extra threads sitting around. Could >> such a message be added? What do you think? >> >> >> >> Paul Kappler >> >>> From: Oskar Sandberg <md98-osa at nada.kth.se> >>> Reply-To: freenet-dev at lists.sourceforge.net >>> Date: Thu, 13 Apr 2000 21:07:54 +0200 >>> To: freenet-dev at lists.sourceforge.net >>> Subject: [Freenet-dev] Build 120 >> >>> >>> d) I caught a problem with a race condition in the ConnectionHandler that >>> causing it to hang after reading a trailing field. I think this may have >>> been >>> the reason for nodes picking up so many threads and connections. Hopefully >>> things will work better now. >>> >>> -- >>> >>> Oskar Sandberg >>> >> >> >> _______________________________________________ >> Freenet-dev mailing list >> Freenet-dev at lists.sourceforge.net >> http://lists.sourceforge.net/mailman/listinfo/freenet-dev >> > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
