> Because we tried it before, and if we increase the default threadlimit > everyone gets OutOfMemoryException's.
So, we increase the memory allocation in the JVM - that has to be a better solution than running two JVMs irrespective of any other argument. > Only if we move BOTH the node AND fproxy to nio. I don't think the > latter is terribly important. And we will still use threads. Moving the > WHOLE node to nio would be a mammoth task for very little gain, or so > Oskar told me once. We would just move the important bits. What is left > will occupy much less threads than the current situation, but will still > occupy threads, and therefore compete for resources with Fproxy. Well, on the one hand you imply that this issue isn't important enough to make Fproxy use nio, but on the other hand you imply that it is important enough to move Fproxy into a separate JVM and use up even more of our user's system resources. Which is it? > > The computer as a whole would have less resources, since it would have two VMs > > running. Resource management within the Freenet VM is just a question of doing > > things right. > > How much less? Can you quantify it somehow? Hard to say, but even an empty JVM, doing absolutely nothing takes up 4MB on Windows. > This > underlines the point that the node and the clients have very little in > common, that they should be separated in order to make freenet more > modular and to make it easier to create alternate node implementations, > over and above any immediate material benefits. Freenet can be made more modular without running FProxy in a different VM by default. > Because it can take a really long time to restart fred on a large > datastore, and there isn't much I can do about it beyond what we have > now (the index files - but the index files have to checkpoint, which > means locking the datastore while cloning the hashtable...). Yes, but why would anyone want to restart Fproxy? > > True, but we don't need to run Fproxy in a separate VM just to expose > > everything via FCP. The original intent was to have both a FCP sockets > > interface (as we do), and a parallel FCP Java API (as we don't really) which > > could allow plugins to run in Fred's JVM. > > Separating them forces the issue. So we impose an additional system resource burden on our users just because we don't have the discipline to write modular code? > > If the API which FProxy uses to talk to the node parallels FCP then this > > will be the case anyway. > > No it won't. Why not? > An alternate node implementation would have to implement > shitloads of stuff, for example FEC. We could put FEC, for example, into > a middle layer of "high level FCP", provided by the fproxy process. Again, this modularity can be achieved with good design and a-little discipline, we don't need to put them in separate JVMs just to force ourselves to write modular code. > > They wouldn't need to run the FProxy plugin either. > > Please explain what if anything you mean by plugins. I am interested in > the idea of third party plugins to implement specific services such as a > NIM2email gateway... I define a plugin as a dynamically loaded module which talks to Fred via a standardized API, and which runs in the same JVM as Fred. By providing a stand-alone implementation of this API which talks to Fred via FCP, such modules can easily run in Fred's JVM, or as stand-alone modules. > > We could create a package which didn't include the FProxy plugin if we wanted > > too. > > It would be a complete kludge. And one piece of software requiring two JVM instances wouldn't be?! > * Usage of threads. This would be fixed by NIO, but only if we apply NIO > to both fproxy and the node. It would be mitigated significantly by > separating the fproxy VM from the node VM, not in terms of the number > of actual threads used on the machine but in terms of the ridiculously > crude resource usage indicators Java forces us to use (the thread > limit). If, by "mitigate", you mean "move the problem somewhere else rather than fixing it" - then yes it probably would. Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://locut.us/ Personal Homepage http://locut.us/ian/ _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
