views:

49

answers:

4

I'm working on an application which interacts with hundreds of devices across a network. The type of work being committed requires a lot of the concurrent threads (mostly because each of them requires network interaction and does so separately, but for other reasons as well). At the moment, we're in the area of requiring about 20-30 threads per device being interacted with.

A simple calculation puts this at thousands of threads, even up to 10,000 threads. If we put aside the CPU penalty for thread-switching, etc., how many threads can Java 5 running on CentOS 64-bit handle? Is this just a matter of RAM or is there anything else we should consider?

Thanks!

+1  A: 

In such situation its always recomended to use Thread Pooling.

Thread pools address two different problems: they usually provide improved performance when executing large numbers of asynchronous tasks, due to reduced per-task invocation overhead, and they provide a means of bounding and managing the resources, including threads, consumed when executing a collection of tasks. Each ThreadPoolExecutor also maintains some basic statistics, such as the number of completed tasks.

ThreadPoolExecutor is class you should be using.

http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml

YoK
Actually, a thread pool is being used. This is the number of threads required concurrently because of the amount of Network I/O being done.
Yon
@Yon So do you mean you open multiple socket connections to Single device ? In that case you will also need connection Pooling for single device to limit number of sockets per device.usually number of socket limit is dependent upon number of inodes available with file system.
YoK
If you have 20-30 connections to a device, try use NIO for interacting with a device - that'll bring you down to 1 maybe 2 threads per device - and bring the thread count down to a managable level.
nos
I completely agree for usage of NIO.
YoK
We can't use NIO - this because the communication is handled by a third-party library which doesn't use NIO. Sadly, we don't have a better option than this third-party library at the moment.
Yon
A: 

I think up to 65k threads is OK with java, the only thing you need to consider is stack space - linux by default allocates 48k per thread/process as stack space, which is wasteful for java (which doesn't have stack-allocated objects, hence uses much less stack space). This will easily use 500 megs for 10k threads.

Tassos Bassoukos
A: 

If this is really an absolute requirement, you might wan't to have a look at a language that's specifically build to deal with this level of concurrent threads, such as erlang.

kasperjj
A: 

Like others are suggesting, you should use NIO. We had an app that used a lot (but much less than you are planning) of threads (e.g. 1,000 ) and it was already very inefficient. If you have to use THAT much threads, it's definitely time to consider the use of NIO.

For network, if your apps are using HTTP, one very easy tool would be Async-HTTP-client by 2 very famous author in this field.

If you use a different protocol, using the underlying implementation of Async-HTTP-client (netty) would be recommendable.

Enno Shioji
We can't use NIO - this because the communication is handled by a third-party library which doesn't use NIO. Sadly, we don't have a better option than this third-party library at the moment.
Yon