02-23-2010 08:25 AM
We have an application based on HttpPushDemo, where the server sends several bulks of information to the client, using multiple "push" operations.
At some point, the "read" operation on the client teminates with an IOException, saying "Local connection timed out after ~ 120000". (we use RIM Push API, if it makes a difference)
Note that it is after some reads from the stream completed successfully, so it is not an issue of bad address.
1. Is the timeout on the device or on the BES?
2. Is there a way to increase it?
03-02-2010 03:17 PM
This should answer your question.
How To - Control the connection timeout for TCP connections through the BlackBerry MDS Connection Service
03-03-2010 03:35 AM
Thanks for the link.
Hiwever, this document refers to a device that connects to a server. In our case - the device listens to connections, and the server is the one that performs the connect (like in the original HTTP Push demo program)
03-22-2010 09:57 AM
I need to see your code to know exactly what the issue is, but I guess you are not using a StreamConnectionNotifier on the clinet side.
In the push demo, it looks like this:
// Open the connection once (or re-open after an IOException), so we don't end up
// in a race condition, where a push is lost if it comes in before the connection
// is open again. We open the url with a parameter that indicates that we should
// always use MDS when attempting to connect.
_notify = (StreamConnectionNotifier)Connector.open(URL + ";deviceside=false");
// NOTE: the following will block until data is received.
stream = _notify.acceptAndOpen();
InputStream input = stream.openInputStream();
The idea is that the StreamConnectionNotifier doesn't open a connection, but actualy acts as a server, waiting for a push to come in. That way there is nothing to close with a timeout.
Hope what I said is understood and helpful.
03-25-2010 05:30 AM
The code (which is based on the HTTP Push Demo) is doing exactly as you describe.
We usually see the problem when several connections are opened in parallel to the device (each one with its own stream and input stream, and running in its own thread). We create the thread after we open the InputStream, and let it read the data until reaching an "end of data". When reached, the InputStream and connection are closed, and the thread terminates.