CODEWITHSUNDEEP
androidiphoneibm-mobilefirst
Berlin Brown
Berlin Brown

Reputation: 11734

How to change timeout value of the connect API?

We are getting the following errors in high volume from our Android and iPhone applications, especially UNRESPONSIVE_HOST and then REQUEST_TIMEOUT. And this seems to happen at the WL.Client.connect() initialization routine.

It is possible that the user may have a volatile Internet or Wifi connection. That is possible. But it seems there is something more systemic. What typically causes unresponsive host error? Why is a timeout different than a unresponsive host? What are the default timeouts? 10 seconds? Before those errors are thrown? Is there a way to change the timeout.

REQUEST_TIMEOUT / UNRESPONSIVE_HOST …

Response Error : The request timed out.
FATAL ERROR at Worklight Initialization: the service is currently not available. status code from server:-1
[https://www.app.com:443/app/apps/services/api/app-name/iphone/init] Host is not responsive.

Upvotes: 0

Views: 1305

Answers (1)

Idan Adar
Idan Adar

Reputation: 44516

According to the documentation the default global timeout value is 30 seconds for all requests originating from the JavaScript framework. It is governed by the timeout option in common\js\initOptions.js (if you do not see it, add it and provide a different value): http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.apiref.doc/html/refjavascript-client/html/WL.Client.html%23init

Instead of changing the global timeout value, you can also change specifically WL.Client.connect's timeout value by adding a timeout parameter to the options object you are using: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.apiref.doc/html/refjavascript-client/html/WL.Client.html%23init

WL.Client.connect({
    timeout: value-in-seconds,
    onSuccess: mySuccessCallback,
    onFailure: myFailureCallback
});

As for the "Why" - who knows. You could use some network sniffer to see what is happening in your network to see where the potential bottlenecks are, as well as compare the timestamps from the network sniffer to the timestamps in the server logs while running in trace mode to further the investigation.

Upvotes: 1

Related Questions