singe thread per connection

[Praki]

I need to implement the telnet using single thread for one telnet
connection. I saw one of the usage of this telnetd with four threads
for single connection. I need to open arround minimum of 500 telnet
connections. so it will not be good to have 500*4 threads. is there
any way in which i can create telnet connection with single thread for
single connection. When i say

InputStream is =new BufferedInputStream(process.getInputStream());
InputStreamReader read=new InputStreamReader(is);
BufferedReader input = new BufferedReader(read);
try {
int c;
while (0 != (c = is.read())) {
shellIo.write((char)c);
}
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
the read gets blocked here. and also if say in the read from the
client it goes blocked, so is there any way that i can do it using
single thread

thanks in advance
k.p

 

[Neil Coffey]

For that matter, I'm not convinced it would be good to have 500 threads.

It's not a great design for the purpose, but purely in terms of
numbers of threads, you'd probably get away with it on a modern OS.
(If you're running Windoze, check perfmon--
you'll quite possibly find you have hundreds of threads running just
with your box "ticking over".)

Not just sure what limits people reach nowadays with one-thread-per-
connection. But I seem to recall that typical UNIX-based web servers
used to fall over at about 400, but that was due to buggy process
scheduling rather than a problem with the connection count per se.
So you may even be all right with 500. Obviously, I'm NOT repeat NOT
advocating this as an example of good program design. You really
should look at an alternative such as NIO (see the thread from a
couple of weeks ago on somebody needing a NIO client app -- I posted
a skeleton). But if it's going to be time-consuming for you to
learn another IO framework, you might just try doing it the nasty
way. (Actually, I'd be sort of interested to know if it works.)

By the way, not really a Java problem, but you should check if the
system you're using imposes any artificial limits on numbers of
outgoing connections.

Oh and I can't see why 4 threads per telnet connection either. Perhaps
somebody was feeling particularly masochistic the day they wrote it...

Neil

 

[Neil Coffey]

On 32-bit Windows, the theoretical maximum number of threads per process
is about 2000, with the practical maximum somewhat lower, and
performance suffering significantly before that. Unix/Linux would be
different...threads are much lighter-weight constructs on those OSs.

Hmm that's interesting -- I wasn't aware of this 2000 limit. FWIW, in a
quick test I can start up about 5,600 threads in XP before I get a
"Cannot start new native thread" error, but I'd concede that's more or
less a limit within the order you say. Although it's a bit bonkers
to want so many threads, it's also kind of disappointing that you
absolutelty can't. I guess Windows uses a bit more memory than you'd
think for each thread control/environment block.

I'm also introgued by another thing: if I understand you correctly,
you're saying that there's a performance difference between having
X threads all from one process and having X threads distributed
across various processes. I thought that the Windows scheduler at least
was agnostic as to which process a thread was from: it just scheduled at
the thread level. The Thread Scheduling chapter in "Microsoft Windows
Internals" (4th ed), for example, describes a dispatcher database
consisting of the list of *threads* ready to run at each priority
level. I suppose that threads distributed over different OS processes
are maybe more likely to have different priority levels (since their
processes are set different base priorities), but other than that,
do you know of any reason for a performance difference for X threads
in a process vs X threads across the whole system?

Of course, I'm not aware of any requirement that a Java thread be
implemented exactly as an OS thread. So OS limitations may or may not
apply in Java.

In principle, there's no obligation for 1 Java thread = 1 native thread.
In practice, I think practically all JVMs use native threads if they're
available. Sun's VM certainly used to have an option for "green
threads" (threads emulated within Java). But assuming it's still even
available, I suspect that maintaining and improving the green threads
model hasn't exactly been a priority for Sun, and suspect it's
essentially not used very much. Oother VMs (e.g. I suspect Acorn's
VM for RISC OS) have been forced to implement "green" threads due to
lack of thread support from the OS.

But my comment wasn't directed at the question of whether one would "get
away with it". I was commenting on what would be a _good_ approach. I
have the impression you agree with me on that point.

Oh yes, definitely. I was just thinking that "opening 500 simultaneous
telnet connections" sounded suspiciously like "need to knock something
up to interface with some legacy system for internal use" rather
than "need to spend a long time developing a well-designed app for
end users". NIO tends to require an investment in time when you first
start using it (though if you need performance, it pays off).

Neil

 

[Neil Coffey]

Is that in Java? The limit comes from the size of the stack allocated
for a thread (1MB by default) and the maximum virtual address space for
a process (2GB).

Ah, Java sets a default stack size of 256K, though you can configure
as a JVM parameter (and from Java 5 onwards you can override in the
Thread constructor). Yes, now I do the calculation, that means my 5,600
threads need about 1.4Gb just for their stack space. Yerk!

It's possible that Java's NIO classes use this mechanism on Windows
(known as "I/O Completion Ports"). I don't really know.

NIO uses the plain old select() function. To use I/O completion ports
you have to write native code yourself -- though I guess somebody's
released a library to do this by now. (And yes, you can get
a severalfold reduction in CPU usage compared to using NIO by doing
this.) However, if I remember my figures correctly NIO can still service
a couple of thousand connections in a few % of CPU usage on what's
nowadays a fairly average machine. So OP, if you're still listening,
NIO should be good enough for your 500 telnet connections.

Neil

 

[Arne Vajhøj]

Ah, Java sets a default stack size of 256K, though you can configure
as a JVM parameter (and from Java 5 onwards you can override in the
Thread constructor). Yes, now I do the calculation, that means my 5,600
threads need about 1.4Gb just for their stack space. Yerk!

The command line parameter is -Xss.

Since some Java server apps uses a lot of threads, then the SUN default
of 256 KB for 32 bit Windows seems fine. A very server focused JVM
as JRockit uses 64 KB as default on 32 bit Windows !

Arne

 

[Neil Coffey]

Since some Java server apps uses a lot of threads, then the SUN default
of 256 KB for 32 bit Windows seems fine. A very server focused JVM
as JRockit uses 64 KB as default on 32 bit Windows !

Interesting-- I was thinking 256K sounded slightly overkill as
a default (given that in principle objects are passed by reference--
although I understand that in reality they aren't in certain
JIT-compiled cases).

The Windows default of 1MB sounds proposterous (aah once upon a time
not very long ago, that was the amount of RAM in the entire
machine...!), but I'm supposing that Microsoft know something I
don't about stack usage of code from their C/C++ compiler...

Neil

 

[Corneil]

I need to implement the telnet using single thread for one telnet
connection. I saw one of the usage of this telnetd with four threads
for single connection. I need to open arround minimum of 500 telnet
connections. so it will not be good to have 500*4 threads. is there
any way in which i can create telnet connection with single thread for
single connection. When i say

InputStream is =new BufferedInputStream(process.getInputStream());
InputStreamReader read=new InputStreamReader(is);
BufferedReader input = new BufferedReader(read);
try {
int c;
while (0 != (c = is.read())) {
shellIo.write((char)c);}
} catch (IOException e) {

// TODO Auto-generated catch block
e.printStackTrace();}

the read gets blocked here. and also if say in the read from the
client it goes blocked, so is there any way that i can do it using
single thread

thanks in advance
k.p

You should look at articles on non-blocking sockets.
i.e: http://www.onjava.com/pub/a/onjava/2002/09/04/nio.html

 

[Arne Vajhøj]

Interesting-- I was thinking 256K sounded slightly overkill as
a default (given that in principle objects are passed by reference--
although I understand that in reality they aren't in certain
JIT-compiled cases).

You could argue that people that need so many threads that it is
important is much more likely to know how to change it than
the beginner with a bad design that run out of stack.

The Windows default of 1MB sounds proposterous (aah once upon a time
not very long ago, that was the amount of RAM in the entire
machine...!), but I'm supposing that Microsoft know something I
don't about stack usage of code from their C/C++ compiler...

Well - in C/C++ you can have quite large objects on the stack.

Arne