On Sat, Feb 08, 2003 at 10:26:00PM +0000, Matthew Toseland wrote: > Suggestion: a priority for 0.5.2, along with probabilistic caching, > should be to separate Fproxy/mainport/etc from Fred, to run in two > separate VMs. > > Pro: > * The thread-limit - each HTTP connection costs a connection, and we > cannot afford them, because we can't use as many threads in a single > VM as we want to. To get reasonable performance from Fproxy, I set my > browser to use _a lot_ of connections. Each one uses a node-side > thread. Splitfile requests are even worse. And FEC decodes run in the > Fred VM. More threads means more connections, which means better > ability to handle load, connections are kept open longer, hop time > goes down. > * In general, Fproxy etc wouldn't interfere with Fred's resources > * Possible to restart Fproxy without restarting Fred > * Easier to implement alternate interfaces such as a browser plugin if > _everything_ is exposed by FCP. > * Easier to make alternate implementations of the node. Or make radical > changes to Fred without making corresponding changes to Fproxy - for > example, the long-heralded nio. > * People who only use third party FCP clients don't need to run the > Fproxy VM at all. > * Possible to create a package with only the node, and a package with > only Fproxy, if wanted. > * Considerably easier to run the client side on a different machine to > the server side.
And .. ease of debugging, currently with a few small hacks fred runs with GCJ pre-3.3 at least for a while. FCP (frost) works, status web pages works, but fetching thorugh fproxy doesn't work. After a while (between 15 min and a few hours) lockups occures, probably some threads go into deadlock. Tracing things like these is easier if the functions is separated into more than one process/JVM. With fewer functions running concurrently in the same JVM the overview of what goes on and goes wrong should be easier. > > Difficulties: > * We need to move perturbHTL somewhere where it can be used by both the > node (to perturb HTLs of individual FCP messages) > * We need a Main class for running the default servlets etc. > * We need to separate out the two configs. > * We need to expose everything that the servlets have access to over > FCP. > * We need to ensure that BOTH VMs are started on startup by default, by > both the Windows and Unix installers. > * Upgrading from the current system to a system with two VMs needs to be > as automated as possible. > > * Probably more... > > Comments? The plugin architecture should be keeped which gives more code to maintain. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
