How many simultaneous concurrent threads can a S60 5th edition device handle? Is there any reading material or technical info about this on the wiki?
How many simultaneous concurrent threads can a S60 5th edition device handle? Is there any reading material or technical info about this on the wiki?
I have no specific information for that platform. However, JSR 185 (JTWI) and 248 (MSA) both require devices to support a minimum of 10 simultaneous threads.
I recommend keeping the number of threads to a minimum. Threads might not be scheduled in quite the way you expect, and it can be quite easy for threads to become starved of execution time if other threads are running continuously.
Graham.
How many simultaneous threads do you expect? What is the frequency of incoming requests, and how long does it take to service one request?
I will do all these tests, at the moment I don't have much figures with me.
Actually the server will be servicing each REQUEST in its own thread.
For testing purposes I am just checking with one client and a server.
The Flash client(running on phone) is just sending a message at using loadVars() to the J2ME server the server just echo the message back to the FL client.
The server has also a local FL GUI that keeps polling(@1sec intervals)to this server and keeps updating its GUI.
This setup is causing me problems as not all the messages from the client seem to reach the server.
I am still debugging this issue.
I did a just did a test and the local call form the FL ui to the j2me http server using http://127.0.0.1:xxxx/
is a whopping 1060milliseconds.
This time is right form the time FL issues a request and it receives a response. A round trip.
Was wondering why a simple HTTP request on the same phone is taking such a long time.
And I was polling every 1sec, may be that's why it was causing some missing messages. Now I have set the poll time to 10sec.
But I want to get to the root of why a local http request/response across platforms takes so long.
Will keep updating as I do more tests.
My first guess is that you might be losing requests if the Java app is not sitting in an acceptAndOpen() call when the connection arrives.
You don't necessarily need to dispatch a new thread every time. A common approach in servers is to place incoming requests in a queue, and have a fixed size pool of "worker" threads, which take requests from the queue. This limits the maximum load on the server at any one time. In your case, you might be able to function quite happily with a single worker thread.
Graham.
Ah well, 1060ms per request, one request per 1000ms, a queue would expand until you hit some limit... Always wise to limit queue sizes, did I mention that?![]()
Sure... but if you don't pass the opened connection onto another thread, you're waiting 1060ms before you go back to acceptAndOpen(). Requests should queue in the OS, but for how long I have no idea.
Yes, once the connection is accepted, you will need to handle it "promptly" before the client gives up (times-out). How long that will be depends on the client.
What you need to ensure is that you don't end up with dozens and dozens of threads all alive at the same time.
Here is a VERY interesting observation:
I carried out the same test on 2 phones and results are SHOCKING
Nokia E51 (S60 3rd ed FP1 and FL player 2.0)
Req/resp round trip time ~ 50 milliSeconds
Nokia 5800XM (S60 5th ed and FL player 3.1)
Req/resp round trip time ~ 1100 milliSeconds
Req/resp is from FL to J2ME and back on the same phone.
And to shock you even more as soon a request arrives in the 5800XM the UI hangs up while this is not the case in the E51.
I had heard several posts on XMLSocket issues in FL3.x but this is even occurring in HTTP requests.
Awaiting your comments.
I'm as in the dark as you are. Hard to know if this is a J2ME issue, a Flash issue, or an operating system issue, since all three are different.
Can you measure the time taken inside the J2ME app?
I am suspecting an issue in FL3.1 player(I'm not 100% sure though) because I have read many articles around the web about a bug in the Flash lite 3.x player when you use a XMLSocket connection, that's the first place that I shifted to implementing a J2ME HTTP server to serve FL, but it turns out that even that has a problem.
But I can't quite understand one thing, there are many commercial apps that use the combination of FL + HTTP server like Kunerilite, SWF2Go etc, why aren't they facing the same problem, they may be using a native Symbian C++ HTTP server.
I can't say if its a problem of J2ME + FL combination.
What do you want me to test in the J2ME server?
I just wondered how long the J2ME code was taking from the acceptAndOpen() call returning, to completing the response. So, how much of that 1060ms is taken up running the Java. Unless the Java is doing something very time consuming, then the delay is out of your control (from a Java point of view). If the Java code is taking a long time, then that might be something we can fix.
I'm afraid I know nothing about Flash Lite. I see you've also asked about this in the FL discussion board, so hopefully you'll get some more help there.
Okay here are the test results:
I measured the time from when the acceptAndOpen() turns a new thread for a request till that thread dies.
And it shows
E51 - 5ms
5800XM - 5ms
Any other tests, that I could do to verify why this is happening?
I will hang around in the Flash thread also and see what replies I get.
Last edited by KevinBoyd; 2010-01-11 at 01:15.