Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-26918] The timeout property is not working on HTTPClient

GitHub Issuen/a
TypeBug
PriorityNone
StatusResolved
ResolutionInvalid
Resolution Date2019-03-26T18:13:33.000+0000
Affected Version/sn/a
Fix Version/sn/a
Componentsn/a
Labelsn/a
ReporterRakhi Mitro
AssigneeRakhi Mitro
Created2019-03-22T08:53:35.000+0000
Updated2019-03-26T18:13:33.000+0000

Description

The enterprise customer experiences the following issue: the timeout value is not working properly for them. Meaning like, even if they are not getting response within 60000, the service call is not getting terminated. This is happening especially under low networks. The customer said that he don't see a benefit of giving timeout in the service call. They noticed the issue mainly in Android, but issue is there in ios as well. *Test case:*




var win = Ti.UI.createWindow();

var url = "http://www.google.com";
 
var client = Ti.Network.createHTTPClient({
 
    onload : function(e) {
 
        Ti.API.info("Received text: " + this.responseText);
 
        alert('success');
 
    },
 
    onerror : function(e) {
 
        Ti.API.debug(e.error);
 
        alert('error');
 
    },
 
    timeout : 60000
 
});
 
 
 
client.open("GET", url);
 
client.send();


Note: We tested this issue on my end using the slow internet of the mobile with latest SDK 8.0.0.GA and it's working fine on this network( android 8 device). Steps that I have followed: 1. Create a new project via studio 2. Added the app.js fine on my new project 3. Change the mobile network to slow. I have used a mobile internet which has hotspot facility.The mobile is kept to some distance from laptop and the other device which I use for app build. 4. Run the application and its working fine. Test output:
[INFO]  Received text: <!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="bn"><head><meta co
ntent="text/html; charset=UTF-8" http-equiv="Content-Type"><meta content="/images/branding/googleg/1x/googleg_standard
_color_128dp.png" itemprop="image"><title>Google</title><script nonce="6V9xhs8v1+JSqnT1utq+iQ==">(function(){window.go
ogle={kEI:'dp2UXKuyBtPgrQGtmIfwAw',kEXPI:'0,1353746,58,1957,1021,1402,698,527,730,224,528,228,751,68,30,1227,1895,70,3
36,178,350,448,2333800,329543,1294,12383,4855,32692,15247,867,7505,4658,5281,7640,3600,369,3314,1263,4242,2442,5367,57
5,835,284,2,1306,2432,1361,4323,4967,774,2253,1589,1256,3047,2,1751,214,2595,3602,668,536,514,1808,1397,81,7,474,17,62
0,29,2373,7931,1288,2,4007,796,1220,38,363,557,682,36,35,120,1217,1364,484,47,1080,2082,610,44,1558,1503,2,631,2562,2,
4,2,670,44,2187,1557,404,156,354,124,2608,632,1138,626,25,439,655,21,39,278,57,198,2,130,396,783,1153,128,386,138,781,
369,1027,287,704,208,548,50,41,7,398,23,78,322,376,2,278,233,21,82,456,53,193,405,10,170,6,85,211,378,386,67,140,95,78
,54,311,24,459,334,564,166,7,257,147,612,15,9,4,354,216,373,48,325,381,2,126,117,10,2,473,1,2,64,57,5,459,115,347,25,2
82,173,4,42,4,478,12,103,467,14,88,85,71,574,140,62,90,1,264,160,181,124,12,130,5951368,13,2541,255,5997581,2799950,4,
1572,549,333,444,1,2,80,1,900,575,17,304,1,8,1,2,2132,1,1,1,1,1,414,1,748,141,59,726,3,7,563,1,1191,96,32,23,3,

Comments

  1. Joshua Quick 2019-03-22

    This is not a bug. The given timeout is applied when it fails to connect to the end point or if response data is not being received anymore. So, as long as data is being received (regardless of how slow it is), the timeout won't be applied. The timeout time is reset internally every time data is being received. Now, if downloaded data suddenly *stopped* being received, then yes the timeout will correctly be applied. Let me give you another example. Let's say you want to download a huge 1 GB file via HTTP GET. In this case, it doesn't make sense for the timeout to be applied to an active download because odds are a file that large won't download within the 1 minute default timeout time. Also note that the timeout behavior is how it works natively on all platforms in C/C++, Java, .NET, etc. This is not the behavior dictated by Titanium. You would see the exact same behavior would coding native apps as well. I recommend that you assign a callback to the [HTTPClient.ondatastream](https://docs.appcelerator.com/platform/latest/#!/api/Titanium.Network.HTTPClient-property-ondatastream) property. This provides download progress. For example, the below code will show download progress via a ProgressBar.
       var url = "https://github.com/appcelerator-modules/ti.admob/releases/download/ios-2.2.0/ti.admob-iphone-2.2.0.zip";
       var downloadFilePath = Ti.Filesystem.applicationDataDirectory + "downloaded.zip";
       
       var window = Ti.UI.createWindow();
       var button = Ti.UI.createButton({ title: "Download" });
       var progressBar = Ti.UI.createProgressBar({
       	min: 0,
       	max: 100,
       	bottom: "40dp",
       	left: "5dp",
       	right: "5dp",
       });
       button.addEventListener("click", function(e) {
       	var startTime = new Date();
       	var httpClient = Ti.Network.createHTTPClient({
       		ondatastream: function(e) {
       			progressBar.value = e.progress * 100;
       		},
       		onload: function(e) {
       			var duration =  (new Date()) - startTime;
       			Ti.API.info("@@@ onload() duration: " + duration + "ms");
       			alert("Download Time: " + duration + "ms");
       			progressBar.value = 100;
       			button.enabled = true;
       		},
       		onerror: function(e) {
       			Ti.API.info("@@@ onerror()");
       			alert("Download Failed");
       			button.enabled = true;
       		},
       //		timeout: 5000,
       	});
       	progressBar.value = 0;
       	button.enabled = false;
       	httpClient.open("GET", url);
       	httpClient.setRequestHeader("Accept-Encoding", "identity");
       	httpClient.file = downloadFilePath;
       	httpClient.send();
       });
       window.add(button);
       window.add(progressBar);
       window.open();
       
  2. Eric Merriman 2019-03-22

    Hello, closing based on engineering comment. Please reopen if you feel it is required.
  3. Alan Hutton 2019-03-26

    Hello, closing based on engineering comment. Please reopen if you feel it is required.

JSON Source