03-03-2009 07:58 AM
A queue of requests serviced by a HTTP processing Thread is how I would process this sort of requirement, unless performance or other considerations meant you had to use a different model. In one situation I use two threads, one for small requests and other for large (slow) requests - which means that the small requests can get through while a large request is receiving or sending data.
Using one of the RIM collections, a queue is easy to create in persistent store so that it will survive device reboot.
Note that most RIM supplied collections (e.g. Vector) are NOT Thread safe, so you should do some sort of synchronization to make sure that your adds and deletes don't mess up the collection.
03-03-2009 08:01 AM
You probably only need one or two connections at a time so you can queue up requests in
one or two objects that serialize asynchronous requests. Also note that your Runnable is not Thread,
sometimes these do get confused.
09-14-2011 08:51 AM
My program consists of many MainScreens that each makes two http requests - two to get images and another is a POST method.
I am also using a Please Wait Screen, which:
1. Shows a series of animated bitmaps when a http request is made.
2. Pops when http request is complete.
To use the the Please Wait Screen, my http connection class extends Thread. So whenever a MainScreen is pushed, three threads are created. After several pushes (about 15 to 18), Eclipse's console shows these messages:
as the line VM:THDRr=too_many_threads suggests, I believe too many threads are created.
Further attempts to push new screen will generate VM:TMTPv=64 message on Console.
In your post you mentioned that it is possible to use a single Thread to process many HTTP requests; in your opinion, is it doable for my situation? I'd greatly appreciate if you could tell me how it should be structured.
Thanks in advance
09-14-2011 02:18 PM
Regarding the "problem" of the multiple Threads for each screen, instead of having 2 Threads per screen why not have one that does both downloads, one after the other.
But this http processing should terminate and the Threads should be killed, so even though you are using more Threads than perhaps you need, these Threads should be terminating and so not contributing to the total.
I'm guessing you have another problem.
Are you pushing your MainScreens using pushModal. This will tie up a Thread and not free it until you pop the Screen. So as you get further down the hierarchy, you will have more Threads tied up managing the modal screens.
If you are not doing this, then I strongly suspect a problem with your Thread processing not terminating. You can check the active Thread count, (Thread.activeCount()). Monitor this, and check which of your Threads is not terminating. You do not have to dereference a Thread, and dereferencing it does not terminate it. Each Thread has to run to the end of its run() method to terminate. So if you note that the active count is going up, and you don't know why, put 'start and stop debugging statements in all your Threads, one at the start of the run(), one at the end, and see which ones start and don't end.
09-16-2011 03:18 AM
You are right, the problem is not with caused by http threads, its the timer and timer task. Added these codes solved my problem.
_GetDataThread = null;
loadingTimer = null;
loadingTask = null;