My application downloads a jpeg from a server and then displays the image on the screen. While running on the simulator it will run in a continuous loop, downloading new images and displaying them on the screen. After the data for each image is received my SocketConnection and InputStreamReader are both closed using the close() command. The application will run merrily along forever on the simulator, but when I load it on the device (7130c) after about 5-6 images are loaded I get the dreaded Max IO Connections exception. I tried making the thread sleep for 4 seconds after closing the connections but that doesn't seem to work.

I can't understand why this exception would be thrown on the actual device and not the simulator. I'm on a BES but using the deviceside=true flag in my connection string.

I had this EXACT problem. I solved it in the end by only ever using one connection object throughout the whole application!

Hmm, I wasn't hoping to hear that.

So, how did you go about using the one connection object throughout? Did you have it connect in a separate thread and then after the thread exited just have the new thread use the same connection over? Or, did you have the thread loop continuously waiting for a command?

I'm curious to know how you did it. I'm new when it comes to sockets and java programming so I'm still learning. Sockets are much easier to work with in VB

I created a class called ConnectionManager that is basically a wrapper around a connection object. Anytime anything wants to make a connection they get the object from the ConnectionManager. If the connection ever times out you can just call ConnectionManager.reset() to reset the object.

I created a class called ConnectionManager that is basically a wrapper around a connection object. Anytime anything wants to make a connection they get the object from the ConnectionManager. If the connection ever times out you can just call ConnectionManager.reset() to reset the object.

BB devices have a (very) small number of connexions allowed.
If connections are not closed properly (stream first then socket) these connexion stay alive ...
By the way, it look like there is a delay on the efficient close of a connection. (That 's why you 're already using the sleep).

If you re closing properly your socket perhaps you just want to replay the connection when getting a "max connection open" Or perhaps you just want to keep your connection open ...

I wound up using bdowling's class and building upon it to check for network coverage and the radio being enabled. In my app I decided to create two ConnectionManager classes (one for writing to the stream and one for reading from it) so that I wouldn't have to worry about the two threads accessing the class at the same time. My first app had only one socket thread but I decided two would be even better. Having two threads instead of one uses up a second socket connection but makes my life easier. So far, it seems to work great.

I just wish I knew why my original arrangement worked perfect on the simulator but blew up on the device.

Well, I'm reviving this thread because I found that removing the deviceside=true flag from my connector string seems to have resolved the problem I was having of non-closing threads. My server application now logs that the socket closed, previously the socket was held open. I'm on Cingular w/a BES but I believe the deviceside=true bypasses the BES? I thought it was possible now to do sockets over WAP with the newer OS's? Is there a config I need to make on my blackberry or maybe a setting? I'll do some searching and see if I can turn anything up.