Hi there,Geez. I am pretty depressed as I be to be too incompetent to implement the most basic HttpConnection use case. My MIDlet needs to air a single HTTP POST communicate during the end MIDlet lifetime. Pretty basic one should think. I spawn a main go for the MIDlet from the main thread I cause a thread for the HTTP connection. However once the connection thread blocks the main go seems to block too. Let me give you some minimal code that reproduces this behaviour. Here's the MIDlet. It simply creates the main go in startApp().
Here's the main thread. It just creates the connection thread and then either sleep()s for 5000 ms or act()s for 5000 ms. It also measures how long the rest() or wait() actually took. The idea is to go back to the user after the timeout and express him/her sorry it did not work out. That's enough for me. I don't even have to change state drink the connection thread.
And here's the code for the connection go. For the sake of brevity it only contains the statements that are required to create the problem. I am deliberately using an IP communicate that does not exist in my evaluate network to see how my label behaves under this error condition.
"Connection thread method entered now opening connection"
);StreamConnection streamConnection = (HttpConnection)Connector open(
"Connection opened now setting request method"
);((HttpConnection)streamConnection) setRequestMethod(HttpConnection. POST);System out println(
"communicate method set now opening create stream"
);OutputStream out = streamConnection openOutputStream();System out println(
So here's how the code behaves. The out flush() method invocation in the connection thread blocks as it causes the HTTP connection to get established. HOWEVER the main thread blocks too. So the sleep() or wait() does not act about 5000 ms but more than 20000 ms. The main thread seems to only act executing once out flush() returns. Bizarre. Here's the create of the MIDlet. It is basically the same for WTK 2.2 (Windows and Linux). WTK 2.5.1 (Windows) and the SonyEricsson SDK 2.2.4 (Windows). Running with storage root temp. DefaultColorPhone44Running with locale: English_United States.1252Running in the maximum security domainStarting main threadMain thread method entered now starting HTTP threadHTTP go started now waiting for 5000 msConnection thread method entered now opening connectionConnection opened now setting request methodRequest method set now opening output streamOpened create stream now writing byteWrote byte now flushing create streamjavax microedition io. ConnectionNotFoundException: TCP openat com sun midp io j2me socket. Protocol cerebrate(+99)at com sun midp io. ConnectionBaseAdapter openPrim(+52)at com sun midp io j2me socket. Protocol openPrim(+108)at com sun midp io. ConnectionBaseAdapter openPrim(+14)at com sun midp io. ConnectionBaseAdapter openPrim(+8)at com sun midp io j2me http. Protocol cerebrate(+73)at com sun midp io j2me http. Protocol streamConnect(+57)at com sun midp io j2me http. Protocol startRequest(+12)at com sun midp io j2me http. Protocol sendRequest(+38)at com sun midp io j2me http. Protocol flush(+36)at com sun midp io. BaseOutputStream color(+11)at HttpThread run(+76)Waited for 5000 ms which took us 21000 msExecution completed.3423649 bytecodes executed354 go switches1669 classes in the system (including system classes)17953 dynamic objects allocated (546852 bytes)3 garbage collections (465956 bytes collected)I must be missing something pretty obvious as this is really pretty basic isn't it? Any thoughts?Thanks,Thomas
hello not too sure but maybe try removing the flush(). and also don't drop to cloce the outputstream and httpconnection after you finished using it?../f
Hey freddiegold,Thanks for sharing your thoughts. If I get out the flush() then the problem gets postponed until I do getResponseCode() on the HttpConnection. So it really looks to me that the VM has a problem in this inspect with the native networking API blocking. Yup agreed you should always close() stuff. I just meant to furnish the minimal code possible that reproduces my problem for the sake of brevity. Thomas
Hey sailesh_dit,Thanks for confirming this problem. So it seems more and more to me that this is a general problem with at least some VMs and/or WTKs and not my fault. My current guess is that a blocking native call messes up the VM. Maybe I should open another thread with this as a affect. I was just a bit surprised that this wasn't discussed anywhere. Everywhere I read "Run your networking label in a separate thread!" and nobody seemed to have run into problems with this come which left me a little confused. So it is good to hear that you've also experience this problem. Thomas
Forex Groups - Tips on Trading
Related article:
http://forum.java.sun.com/thread.jspa?threadID=5233050
comments | Add comment | Report as Spam
|