CODEWITHSUNDEEP
ibm-mobilefirst
vishal_g
vishal_g

Reputation: 3921

IBM Worklight 6.1 - How to handle timeouts in slower networks?

We have built an application using Worklight 6.1 for iOS5,iOS6 & IOS7, and it's working perfectly fine.

However, when we are trying to use app in 2G network and try to call an adapter procedure it is not even connecting to the server. Every time we are getting a time out and after trying 10-15 times, it will get connect to server and give response back.

When we use same app on other good network or 3G, it works perfectly fine with no issue.

This is the log which we se in Xcode Organizer console while using 2G network:

Jan 17 16:50:53 My-iPad Sec Sec[292] <Warning>: WLRequestBuilder.initWithRootUrl else_url: https://domain.com:443/MyApp/apps/services/api/MyApp/ipad/0/query
Jan 17 16:50:55 My-iPad Sec Sec[292] <Warning>: LSHelperClient: Session started with polling: NO
Jan 17 16:50:59 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:50:59 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLRequest requestFailed:]:338::Status code='0' error='The request timed out'
Jan 17 16:50:59 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:50:59 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:50:59 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLClient onInvokeProcedureFailure:userInfo:]:696::response string=''
Jan 17 16:50:59 My-iPad kernel[0] <Debug>: AppleAP3GDL::handleInterrupt2 FIFO is Empty
Jan 17 16:51:08 My-iPad Sec Sec[292] <Warning>: WLRequestBuilder.initWithRootUrl else_url: https://domain.com:443/MyApp/apps/services/api/MyApp/ipad/0/query
Jan 17 16:51:14 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:14 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLRequest requestFailed:]:338::Status code='0' error='The request timed out'
Jan 17 16:51:14 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:14 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:14 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLClient onInvokeProcedureFailure:userInfo:]:696::response string=''
Jan 17 16:51:17 My-iPad Sec Sec[292] <Warning>: WLRequestBuilder.initWithRootUrl else_url: https://domain.com:443/MyApp/apps/services/api/MyApp/ipad/0/query
Jan 17 16:51:23 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:23 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLRequest requestFailed:]:338::Status code='0' error='The request timed out'
Jan 17 16:51:23 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:23 My-iPad Sec Sec[292] <Warning>: Incorrect NSStringEncoding value 0x0000 detected. Assuming NSASCIIStringEncoding. Will stop this compatiblity mapping behavior in the near future.
Jan 17 16:51:23 My-iPad Sec Sec[292] <Warning>: [ERROR] Worklight: -[WLClient onInvokeProcedureFailure:userInfo:]:696::response string=''
Jan 17 16:51:33 My-iPad Sec Sec[292] <Warning>: WLRequestBuilder.initWithRootUrl else_url: https://domain.com:443/MyApp/apps/services/api/MyApp/ipad/0/query
Jan 17 16:51:40 My-iPad Sec Sec[292] <Warning>: DeviceAuthManager:getWorklightUniqueDeviceId --> returning UUID from the keychain
Jan 17 16:51:40 My-iPad Sec Sec[292] <Warning>: WLRequestBuilder.initWithRootUrl else_url: https://domain.com:443/MyApp/apps/services/api/MyApp/ipad/0/query

Let me know what will be the issue and what else we can do for it. Our backend API is very fast, within millisecond we are getting response.

What we did on procedure side :

var timeout = 600000;
var invocationOptions = {
  onSuccess: LoginSuccess,
  onFailure: LoginFail,
  timeout: timeout
};

And in Adapter XML file :

<procedure name="Authentication" requestTimeoutInSeconds="600000"/>

And we have tried this experiment with HTTP and HTTPS both and having the same issue(getting time out).

When we launch app we are getting wlclient init success.

Upvotes: 0

Views: 797

Answers (2)

Anton
Anton

Reputation: 3166

Do not set high timeouts in adapter XML file. 600.000 seconds timeout means that a thread that is used to connect to a backend will wait for 166.6 hours before timing out, this can easily kill your server functionality:)

Usually you want your adapter<->backend timeout to be the highest value you allow in app<->adapter connectivity. E.g. if max timeout you use in your app is 60 seconds - this is the value to use in adapter<->backend segment as well.

Now, regarding app<->adapter segment. AFAIR default timeout is 30 seconds. This is usually enough for 2G networks as well. However in some cases this might be a bit low. You can use getNetworkInfo() API (http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.apiref.doc%2Fhtml%2Frefjavascript-client%2Fhtml%2FWL.Device.html) to detect whether you're on WIFI/Mobile and 3g/2g etc. Once you're on a slow network - increase your timeouts. If you're on a fast network - there's no reasons to keep users waiting too long, reduce your timeouts.

Upvotes: 1

Idan Adar
Idan Adar

Reputation: 44516

It's great that your backend is very fast, but that's an internal system.

When using 3G or WiFi, speeds are typically fast.
When using 2G or less, speeds are typically much slower.

Did you try increasing the timeout values in your WL.Client.invokeProcedure as well as adapter procedure?

These will allow for the client and/or server to wait longer for a response. This should help in cases where the network speed is very slow.

See these questions:

Upvotes: 0

Related Questions