There is no good reason to not have a finite SoTimeout, so setting it to 5 minutes or so should not be a problem. In fact, make it a config option.
Just make sure that it really only does what is says and cuts off waits - we certainly don't want the socket going down because of a few minutes of inactivity. Oskar Sandberg - mail/finger md98-osa at nada.kth.se - Crypto is a human right On Fri, 14 Apr 2000, Paul Kappler wrote: > 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 > _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
