Generally starting and stopping threads in any server is not advisable, because threads are costly. If you have to do some background processing, it's better to use a thread pool so that a) your don't use kernel resources by starting/stopping threads and b) you don't overwhelm the system by starting too many threads. A thread pool is generally configured with a max limit on number of threads.
Remember that the resources on any system are finite. Logically, programmers tend to think of threads as something akin to a new worker. However, the computer cannot magically create more CPU, or add more memory or make the hard disk spin faster. By adding your own background threads, you are taking resources away from JBOSS. By starting too many threads, you start a feeding frenzy among the threads and cause the threads to fight with each other. Coming up with the right number of threads to start is not easy. It requires a lot of analysis, fine tuning and testing. It's very easy to start new threads , much difficult to do it properly
SO, I wouldn't say don't ever start your own threads. However, I will say don't start threads lightly.
posted 6 years ago
Thanks Jay for quick reply.
I have received one suggesstion to go with ThreadPool (Apache commons). I couldn't find any information, how to do it?
Could you please give me the some suggestions to achieve or some sample for Threadpool.
Apache Thread Pool has a very short and useful example right on their main page
Java's own ExecutorService will do a good job too. There is a sample on the APIDoc
Generally thread pools are built on a Publisher Consumer pattern. Java docs for both implementations are very good, but they assume that you are familiar with the Publisher COnsumer pattern. I would suggest that you read up on that pattern (if you haven't already) before you go into API docs.
The J2EE standard explicitly forbids request processors from spawning threads.
Request processors should do their work quickly and return a response. For things that cannot be done quickly, set up an independent process in the application startup context listener and use synchronized objects to communicate with it. You can do any threading you like in the context listener-spawned processor.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.