• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dispatcher Threads and Synchronous notification

 
Sameer Amte
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We are writing a real-time application using Java on Windows. The application will receive data from Sockets (one per logged on user) and on receipt of data it will transmit data to registered listeners.

I am inclined to use a dispatcher thread i.e., whenever data is received, it is dispatched on a separate thread. As data is updated at a very rapid rate, a separate dispatcher thread eliminates the possibility of loss of data while data is being sent to registered listeners.

In the Dispatcher threads, I have two options:
1) Use an object lock and wait() till data is received, and once data is received call notiffy() and the dispatcher thread will do the needful.
2) Let the Dispatcher thread run continuously i.e., something like
while (continueRunning) and update an instance variable of the dispatcher thread when data is received.

A third option independent of Dispatcher threads is the using synchronous notification i.e., notify the registered listeners on the same thread which received data.

When I measured the performance on the above approaches, I found that the third option i.e., synchronous notification is fastest, option 1 is second and option 2 is slowest.

The data must be sent to the user as fast as possible as it is a real-time financial application.
In option 1 there is a risk that it may not always be very fast due to uncertainties in thread scheduling. Option 3 is risky as it may lead to loss of data if it takes too long to notify registered listeners.

Option 2 seems the safest but is the slowest. The performance gets worse witn more users logged on.
Can anyone share any thoughts on possible design alternatives?

Thanks
Sameer
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you looked at thread pooling in JDK 5? (On older JDKs look for Doug Lea's concurrent package or the Apache Commons threadpool.) These will run some controlled number of threads to do the sending. You can tune the number to take best advantage of any latency in sending the messages. It also uses a queue that will send all message - no loss unless you run out of memory - in the proper order.

The idea is that you put commands to be executed into a queue and some number of threads pulls them out of the queue and executes them. Your logic might look like:

All the thread magic is done by the pooler. Someplace in the guts of the pooler is a Runnable that pulls commands from the queue and calls run(). In JDK5 look up Executors and BlockingQueue for an introduction.
[ May 16, 2005: Message edited by: Stan James ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!