Limit the number of Threads
We have an application has one queue sending message to 3 java apps, each java app needs to call one xml server and receive response back from it synchronously.
>app_1 --> Xml application (only handles 4 java threads)
Queue -->app_2 --> Xml Server (only handles 4 java threads)
>app_3 --> Xml Server (only handles 4 java threads)
But the XML server needs to limit Java Threads to 4 each, so only max of 12 java threads can be running at the same time, others have to wait.
I was wondering what could be the best solution. Should I use singleton pattern to only allow 4 instances of app on each XML server.
BTW, app is installed on the same machine hosting XML server.
Any suggestions will be appreciated ! Thanks
(a) why?(b) See java.util.concurrent. All kinds of thread-pools in there, with low and high limits, everything you could want.
ejpa at 2007-7-14 21:41:14 >
I'm not at all clear on the structure here. By "sending messages" do you mean RMI invocations? It sounds like you have multiple VM's running. It is unclear where the limit of 4 threads comes from.
Assuming it is RMI and you want to impose the limit of four active threads then a simple solution would be to use a java.util.concurrent Semaphore to limit access to four threads at a time:
Semaphore sem = new Semaphore(4);
// code that needs constraining to four active threads:
sem.acquire();
try {
// do what ever
}
finally {
sem.release();
}
If you are creating the threads that accept the "messages" then limit the number of threads you use. As ejp stated look at j.u.c and ThreadPoolExecutor.
Thanks for the reply, I will make it clear about the structure,
app is picking up the message from a IBM MQ Queue then based on the message to make a RMI call to XML server program. The third party XML server program has a limitation of handling only 4 java threads at a time. Therefore, we need to limit the number of Java Threads / RMI calls to the XML server, other threads have to wait.
After the RMI call, XML Server program will send back the result xml to app1,app2 and app3, which in turn put those messages on another response Queue.
-->app_1 -->RMI call--> Xml Server (4 java threads at a time)
MQ Queue -->app_2 -->RMI call--> Xml Server (4 java threads at a time)
-->app_3 -->RMI call--> Xml Server (4 java threads at a time)
I guess I can use a thread-pool like configuration on my app side. Any more suggestions are welcome.
Thanks
Simple put each message into a BlockingQueue (I usually use the ArrayBlockingQueue) and then have 4 thread each in its own loop just to get a message from the queue and handle it.
Received RMIMessage gets put into queue
BlockingQueue<SomeMessage> blockingQueue = new ArrayBlockingQueue<SomeMessage>(10);
for(;;) {
//retrieve rmiMessage.
blockingQueue.put(rmiMessage);
}
Also create 4 threads to read and process each message.
new Thread(new Worker(), "RMI Worker 1").start();
new Thread(new Worker(), "RMI Worker 2").start();
new Thread(new Worker(), "RMI Worker 3").start();
new Thread(new Worker(), "RMI Worker 4").start();
Workers:
class Worker implements Runnable {
public void run() {
for(;;) {
try {
SomeMessage rmiMessage = blockingQueue.take();
processRmiMessage(rmiMessage);
} catch (Throwable th) {
th.printStackTrace();
}
}
}
}
> The third party XML server program
> has a limitation of handling only 4 java threads at a
> time. Therefore, we need to limit the number of Java
> Threads / RMI calls to the XML server, other threads
> have to wait.
I'm curious about this. Such limitations are quite difficult to achieve with RMI - are you sure? Secondly, are you sure you have to do anything at the client to observe the limit? - maybe the queue will naturally form at the RMI server product and you don't have to do anything? What actually happens if you do 5 calls simultaneously? Do you get an exception or does one of them just wait? If the latter, you don't have to do anything.
ejpa at 2007-7-14 21:41:14 >
Thanks for all the replies.
I was also curious about this requirement at first but the Tech Design is written this way, saying that over 4 threads with cause exception maybe crash the server program. So my app should limit the number of thread to do ensure that. I am not sure who wrote that server program, it is stated this way, a litte weird.
Thanks for the help, I will give it a try.
Just realized we can have to use JDK1.4.2 yet, so the BlockingQueue cannot work. I guess I will need to simulate the BlockingQueue.
> I am not sure who wrote> that server program, it is stated this way, a litte> weird.Completely wierd, and utter trash if it's a product.Have you tested it with > 4 threads?
ejpa at 2007-7-14 21:41:14 >
> Just realized we can have to use JDK1.4.2 yet, so the> BlockingQueue cannot work. I guess I will need to> simulate the BlockingQueue.For pre 1.5 take a look at http://dcl.mathcs.emory.edu/util/backport-util-concurrent/
[deleted, accidental repeat of information already given]Message was edited by: sorabain
