ScheduledThreadPoolExecutor stops working

[DamZ]

Hi everybody,

I'm developping a real time sport game (flash client /w custom Java extensions) and I am encountering a problem that prevents me from going further.

Before that, I would like to say that I am more a Flash Developer than a Java one, and there could be obviouses java developping tips that I am unaware of despite my differents googling on this.

I am using a few ScheduledThreadPoolExecutor as timers for different purposes:
* countdown (just sending message to clients from time to time with a timestamp)
* physic engine steps (custom engine calculating the position of the players and sending it to them)
* game rules (managed by the Drools rules management system Library)

My problem is : sometimes, for some reason I ignore, one of those ScheduledThreadPoolExecutor completely stops executing without triggering any exception at all.

Having read the java 1.5 manual, I already know that if an exception is caught, the current thread handled by the executor stops working, and the fowoling scheduled threads are just canceled.

I know this thread could not stop prematurely for no reason, but it's quite difficult for me to debug if I don't know where the error is triggered, especially when the system is
just working fine for 5 minutes long.

What I wanted to know is:
* has anyone encountered the same problem as me and has found a way to debug its code accurately?
* has this something to do with my jdk (thing that I think is impossible 'cause I downloaded mine like 2 months ago...)
* should I use a different class than ScheduledThreadPoolExecutor as a timer than could help me debugging my application?

Thanks in advance for your replies.

[Lapo]

Is your code, executing in the Scheduler, catching possible exceptions?
One simple way to make sure that no exception escapes is to surround your code with:

Code: Select all

try
{
   // Your code...
}
catch(Throwable t)
{
   // log the problem
}

Of course you can use finer grained catch clauses in order to trap specific problems and let all the others end up in the generic Throwable category.
This should at lease guarantee that no error escapes the Thread that is executing the code.