I had written a CRON scheduler for the blackberry for one of my clients. This CRON scheduler was failing seemingly randomly where the thread that checks the schedules would just die. In order to make sure a task is launched exactly when it should, I would spin off a thread and execute that code. You can see where this is going right? It worked just fine under my development tests. When it went to QA, it would fail. After tracing it down, it was failing on the line:
thread.start();
After finding the exact line of code where it was crashing, I surrounded this line of code with a try/catch on Throwable with this code:
System.out.println(“Error: ” + exc.getClass().toString() + ” = ” + exc.getMessage());
The output from this was:
Error: class net.rim.vm.TooManyThreadsError = null
Which of course led me to my problem. Now there is no mention of a limitation in the Blackberry documentation telling me how many threads I can have. In hind sight, I should have know given that even in desktop apps you should use threads sparingly. These threads I created were supposed to be very short lived. They spin up, do their action and then go away. In my testing that’s exactly what was happening but I wasn’t stressing the system with lots of tasks. Consequently under real-world use, trying to start that last thread was killing the thread that created it.
I can’t simply use the ThreadPool class provided in java.util.concurrent because that is not available in J2ME/JME. I just created my own based on an article written by IBM about Thread pools and work queues. I had to use Vector instead of a linked list (didn’t feel like writing my own but I should because removing an element from a vector is expensive and I have to do it every time I pop an element out). Worked like a champ!
Post a Comment