On Thu, Oct 18, 2001 at 03:20:42PM -0400, Gianni Johansson wrote: > On Thursday 18 October 2001 08:04, you wrote: < > > > As I said, I don't see the point in this. The CP value already gives a > > "rest", it just does to ramdonly rather than absolutely, but it averages > > out. > > > Averaging out isn't good enough. Transient routing failures -- caused by > target nodes hitting their thread/connection limit -- are very common. You > need to recover from them as soon as possible. If you have one node ref that > just stopped working and the rest haven't worked for days, it makes sense to > retry the one that was working as soon as reasonably possible (i.e after the > rest interval expires). Otherwise the network will collapse under heavy > stress a la 0.3.
But that is what the CP does. The one that just failed recently will have a greater CP than those that have been broken for a long time - therefore it will get checked sooner. Perhaps the decay needs to be tuned, but the math here is already correct. > Just to clarify, my change increases the timeout interval with each > successive failure, so if the refs have been retried and failed and none's > timeout interval has expired, the request will RNF. Which is what decaying the CP already does. <> > The perfect is not the enemy of the good. > > Rember this code should almost never run. It's purpose is to allow the node > to bootstrap into the network with a small set of potentially crappy noderefs > and/or to recover after it has been overloaded --i.e. routed so many requests > that all of it's node refs are no longer responding. > > As you have pointed out the previous implementation was just wrong. I think > my modifications are an improvement. The correct thing to do is keep it simple and consistent. Use the CP and only the CP. If you run out of refs always go to RouteNotFound. Unnecessary complication IS the enemy of the good. <> > > I agree, that seems wrong. I think that it should rather be > > > > tm = new ThreadPool(tg, node.maximumThreads >> 1, node.maximumThreads, 5); > > > > though "5" seems awefully arbitrary. I'm quite sure the intention was to > > have maximumThreads maximum, and half as many in the pool by default, so > > this is probably simply a mistake. > > > I'm not sure I am following you. Well, I'm not entirely sure how the ThreadPool works, but I thought that the pool number was the number of threads that were always kept alive (except I guess "minPool" would be a better name for that I guess), the maxThreads number was the maximum that could ever be alive, and I don't see the need to enqueue any jobs at all (there is no sense in leaving jobs hanging we don't have threads for, all new Threads except connections come from the Ticker). It seems logical to me that we keep an active pool of about half the allowable threads - why would we only keep 5? <> > > > I will not comment on the practice of using shift operators instead > > > of division... > > > > If somebody doesn't know what a bit shift does, they are better off > > learning now. > There is no accounting for taste. I think that you should make simple things > simple so that the people who read your code can concentrate on the things > that are truly complicated. There is no accounting for one's definition of simple either... <> -- Oskar Sandberg oskar at freenetproject.org _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
