[MUD-Dev] Re: OT: Java multithreading performance

["Jon A. Lambert" <jlsysinc#ix,netcom.com>]

On 18 May 98, Ben Greear wrote:
> On Mon, 18 May 1998, Chris Gray wrote:
> 
> > [Vadim Tkachenko:]
> > 
> > :I have the logging routine implemented in such a way that it accepts the
> > :messages and prints... well, makes them available to the final logging
> > :device, in the thread runninh with background priority. When I ran this
> > :est, I had to disable all that stuff because the log was becoming silent
> > :after some number of threads (don't remember the exact number, though).
> > 
> > Understood. Determining what the absolute number of threads it can support
> > is academically interesting, but not real useful. Determining the number
> > of MUD-server-like threads that it can support is more useful. Your
> > result is closer to that. So, if a server design in Java intends to use
> > a thread per client, and each client should have an open socket, then at
> > least on Linux, the socket-per-process limit is likely to be reached before
> > any inherent Java limit. Of course, there is still the CPU power limit,
> 
> The socket limit has me worried.  I can't think of a clean way to get
> around this in Java.  I suppose I could do a 
> 
> System.??("java AnotherServerBackEnd")
> 
>  but that seems messy at best.
> Anyone got around this, or know of a project which has tried?
> 

What socket limits?  Isn't this dependent on the TCP/IP stack you are 
using more so than Java?  For my implementation, 32767 is the 
maximum number of sockets I can open per process.  I can assure you 
that this limit is well above any practical thresholds as all 
hardcoded limitations should be.  :)

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--

-- 
MUD-Dev: Advancing an unrealised future.