[I've resubscribed, for now, to answer actual technical questions raised. I'll see where this goes....]
On Thu, 3 Jul 2003, Tracy R Reed wrote: : > Sounds like broken code. While NIO can improve performance, it's certainly : > not "critical" from the perspective of my long-running nodes. My nodes' : > load rarely went above 50%. : : How does Java normally handle dozens or hundreds of simultaneous : connections? Java itself doesn't, without NIO. However: : Running potentially hundreds of threads at once does not yield good : performance either. Canned response: "You use Linux, don't you?" Yes, I recognize that threads aren't the most efficient way to do these things -- and that it's deadly *on Linux* because LinuxThreads sucks rocks. That pre-NPTL pthreads system on Linux, used by JDK 1.3.1 and later (there's no NPTL release of the JDK yet), uses clone(2) to create threads, essentially creating a heavyweight process for every thread. (JDK 1.3.0 and earlier for Linux offered the old green_threads as an alternative, specifically because of this concern, and it manages to multiplex thousands of threads in userland on Linux amazingly well. 8-) : The general consensus seems to be that most nodes are overloaded (mine : usually was before NIO) and reject connections and that is the cause of : our routing woes. What do you consider to be the proper way to solve this : problem? NIO is fine, if an alternative is at least selectable that uses classical I/O in some fashion where it would be usable. It's even possible to retrofit NIO code to use the bulkier multiple-threads method, insofar that implementation of a SelectableChannel requires creation of a backing thread for a classical java.io stream or stream pair. "It would have been nice" if the network I/O parts of Fred were abstracted through an interface of some sort rather than rewritten altogether. That would have allowed config-based selection of the backing implementation. : > points). These apps do rather intensive network I/O without NIO, and yet : > I've experienced zero "broken" I/O problems in this codebase. : : Intensive network I/O can mean a number of things. Do they do hundreds of : simultaneous connections? How? 500 at a time is not abnormal for a couple of these apps, as they serve up (non-SQL) database information. And yes, that means 500 or more threads at a time, which is not as much of a problem on that host platform (Solaris). We recently moved to NIO on these applications (originally for mmap() ability on disk-based I/O), and "we could do that" because we weren't actually committed to multiplatform support. The performance improvements on the converted network code are nominal, not quite awe-inspiring. Anyway, I don't know that all this matters enough to go fork off yet another branch of Fred (the Italian folks already have one), and maybe, once GCJ support is good enough, I can just use a GCJ-compiled Linux binary under binary emulation. I'll just stick to the SSL tunnels for now and get out of the way of Progress. -- -- Todd Vierling <[EMAIL PROTECTED]> _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
