On Friday 23 February 2001 14:54, Chris wrote:
> On Fri, 23 Feb 2001, Chris Anderson wrote:
> > Kirk, are you using binary or source distro? I could get you a version
> > of proxy that runs in a separate jvm if you want to try it.
>
> Well, anyway...
>
> In ProxyServer.java, right before sc = new SimplifiedClient(params), add
> the lines:
>
> 57a58,60
>
> > listenPort = params.getint("listenPort", defaultListenPort);
> > params.setParam("listenPort", "0");
> > Core.init(params);
>
> then java Freenet.contrib.fproxy.ProxyServer <stdargs> will work.
I did this. fred looks like it is behaving fine on its own. I guess to be
sure you would have to run it for a long time....
There's a bad bug in MapFile though. Namely, every call to MapFile.get()
creates a new SimplfiedClient instance. That instance in turn creates a
ClientCore (actually its base class CLI does) which starts listening on a
socket. The problem is that the ClientCore is never released, so it just
keeps on listening.
The symptom you see if you run fproxy in it's own JVM and watch it with
netstat is a new listening connection open FOR EVERY SINGLE MSK READ.
I would expect that the SimplifiedClient / ClientCore instances would
eventually be garbage collected, but they don't seem to go
away. At least not over the period of serveral minutes that I monitored
netstat.
I added a hack to plaster over this problem and retested both scenarios,
i.e. with fproxy in the same JVM and in a different JVM. In both cases it
seemed to fix the thread leakage problem. I'm a bit fuzzy on why this makes
any difference when fproxy runs in the same JVM as fred but the problem does
indeed go away...
Note that the other bug of threads being leaked on security filter
exceptions that I reported earlier today is still there.
Diffs for my quick fix are attached. It is gross, but no worse than the
busted code that's there now.
With this hack and the security filter turned off (the default right?) the
system might just be stable enough to release (after a couple days of
shakeout testing of course). It would be a good thing to get the ThreadPool
patch released to see if it brings the network back to life....
Thoughts?
-- gj
--
Web page inside Freenet:
freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapfile.quickfix.patch
Type: text/x-java
Size: 777 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20010223/169e8e16/attachment.java>
