Problem with Pushlet (and/or Thread Competition?)

Question

Hi all,
Once again, I'm in over my head and have approximately four hours to dig myself out.
I have a client-server application. One the client side is an Applet that runs Java 3D and has a JavaPushletClient / JavaPushletClientListener pair (from Pushlet Framework). All of the code is executed on either the AWT Event DIspatching Thread, the Java 3D InputDeviceScheduler thread, and the JavaPushletClient thread (none of the code on the latter is mine, it's part of the Pushlet Framework).
On the ServerSide, I have subclasses Pushet and Postlet of the Pushlet Framework.
I have one client sending information to the Server (via HTTP Get Request). This is occuring on the Java 3D InputDeviceScheduling thread. It sends information to the server roughly every 35 ms (This was not predetermined - it cannot be. This was measured). The Server is recieving these messages and sending them to the Publisher at the same rate (every 35 ms, again by measuring). When the information is published to other clients, it appears that the pushlet client waits 200 ms, reacts to all of the messages (roughly 6 in 200 ms) that have accumulated at once, and waits another 200 ms.
This system is intended to display real time information at a rate of no worse than 50 ms (this is for animation purposes, roughly 20 fps).
I can't figure out where this problem is coming from, or why. I have read through the Pushlet source code, and it indicates that everything should really be continuous.
Here's what I think MIGHT be happening:
the PushletClientLoop is sort of like this:
while (true) {
          message = objectInputStream.readObject();
          theListener.event(message);
}I wondered if it was possible that when it attempts to read an object, it blocks because one is not available, and transfers processing to another thread, and does not recieve processing time for another 200 ms.
If that is the case, (given that all the other code is scheduled by Java 3D and the AWT Event Dispatching thread), how can I make sure that this JavaPushletClient thread gets processing time at least every 50 ms.
OR, I could be way off. This problem could be caused by something else altogether. Any ideas?
At any rate, I really need help here. This is my final day on this project, and the presedent of our company wants to see the results next Tuesday. AND, (because my company is part of the Canadian Gov't), it's possible that the Prime Minister of Canada will be present for the Demo Tuesday. So I really need this to work. Lots of Dukes up for grabs on this one!
- Adam

Answer 1

Here's what I think MIGHT be happening: ......
I wondered if it was possible that when it attempts to read an object, it
blocks because one is not available, and transfers processing to another
thread, and does not recieve processing time for another 200 ms.yes, objectInputStream.readObject(); will block the thread until there is:
a) an object to read or
b) the stream is closed and an exception is thrown.
The JavaPushletClient doesn't run in the event dispatch thread. It runs in it's own thread. I'm sure of that, I've used it before. Unless you are doing something wrong, but I'm not sure how, cuz you just use the JavaPushletClient class and have your own listener class. That doesn't mean it's no the event dispatch thread, though.
Pushlets send probe messages frequently, although every 35 ms, I dont' know if it's that frequent (if that's what you mean).
You could update the priority of the thread in the JavaPushletClient. But exact scheduling of threads in Java is tricky. I'm not sure there's a way to guaranty what you want. Up the priority, and see what happens.
It's very well possible that other threads are doing stuff for 200 ms and not giving up control. Likely I'd say. Although if it's consistently 200 ms, that sounds weird.
It maybe doesn't matter, though, that it runs every 50 ms, cuz you're UI display isn't likely to be that responsive anyway.