HttpConnection blocking ALL MIDlet threads?

Question

Hi there,
Geez, I am pretty depressed as I seem to be too incompetent to implement the most basic HttpConnection use case. My MIDlet needs to issue a single HTTP POST request during the complete MIDlet lifetime. Pretty basic, one should think. I spawn a main thread for the MIDlet, from the main thread I spawn a thread for the HTTP connection. However, once the connection thread blocks, the main thread seems to block, too. Let me give you some minimal code that reproduces this behaviour.
Here's the MIDlet. It simply creates the main thread in startApp().
import javax.microedition.midlet.MIDlet;
public class Connection extends MIDlet
     protected void destroyApp(boolean force)
     protected void pauseApp()
     protected void startApp()
          System.out.println("Starting main thread");
          new Thread(new MainThread()).start();
}Here's the main thread. It just creates the connection thread and then either sleep()s for 5000 ms or wait()s for 5000 ms. It also measures how long the sleep() or wait() actually took. The idea is to go back to the user after the timeout and tell him/her, sorry, it did not work out. That's enough for me. I don't even have to shut down the connection thread.
public class MainThread implements Runnable
     private synchronized void waitFor5000ms()
          try
               wait(5000);
          catch (InterruptedException ex)
               ex.printStackTrace();
     private void sleepFor5000ms()
          try
               Thread.sleep(5000);
          catch (InterruptedException ex)
               ex.printStackTrace();
     public void run()
          System.out.println("Main thread method entered, now starting HTTP thread");
          new Thread(new HttpThread()).start();
          System.out.println("HTTP thread started, now waiting for 5000 ms");
          long startTime = System.currentTimeMillis();
          if (true)
               waitFor5000ms();
          else
               sleepFor5000ms();
          long duration = System.currentTimeMillis() - startTime;
          System.out.println("Waited for 5000 ms, which took us " + duration + " ms");
}And here's the code for the connection thread. For the sake of brevity it only contains the statements that are required to reproduce the problem. I am deliberately using an IP address that does not exist in my test network to see how my code behaves under this error condition.
import java.io.IOException;
import java.io.OutputStream;
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
import javax.microedition.io.StreamConnection;
public class HttpThread implements Runnable
     public void run()
          try
               System.out.println("Connection thread method entered, now opening connection");
               StreamConnection streamConnection = (HttpConnection)Connector.open("http://192.168.123.234/blah.html");
               System.out.println("Connection opened, now setting request method");               
               ((HttpConnection)streamConnection).setRequestMethod(HttpConnection.POST);
               System.out.println("Request method set, now opening output stream");
               OutputStream out = streamConnection.openOutputStream();
               System.out.println("Opened output stream, now writing byte");
               out.write(0);
               System.out.println("Wrote byte, now flushing output stream");
               out.flush();
          catch (IOException ex)
               ex.printStackTrace();
}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 take about 5000 ms, but more than 20000 ms. The main thread seems to only continue executing once out.flush() returns. Bizarre. Here's the output 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.DefaultColorPhone44
Running with locale: English_United States.1252
Running in the maximum security domain
Starting main thread
Main thread method entered, now starting HTTP thread
HTTP thread started, now waiting for 5000 ms
Connection thread method entered, now opening connection
Connection opened, now setting request method
Request method set, now opening output stream
Opened output stream, now writing byte
Wrote byte, now flushing output stream
javax.microedition.io.ConnectionNotFoundException: TCP open
     at com.sun.midp.io.j2me.socket.Protocol.connect(+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.connect(+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.flush(+11)
     at HttpThread.run(+76)
Waited for 5000 ms, which took us 21000 ms
Execution completed.
3423649 bytecodes executed
354 thread switches
1669 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

Answer 1

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 subject.
I was just a bit surprised that this wasn't discussed anywhere. Everywhere I read "Run your networking code in a separate thread!" and nobody seemed to have run into problems with this approach, which left me a little confused. So, it is good to hear that you've also experience this problem.
Thomas