TXDataClient Timeout on iOS

Hi,

I'm using a TXDataClient to invoke service operations, is there a way to set a timeout to get response under iOS, I have done some testing and if server is not available it waits for aprox. 1 minute before exception. Is the a way to shorten this time?

thanks in advance,

Omar Zelaya

You can use OnSendingRequest event to configure the requests sent by TXDataClient, including the timeout:






 XDataClient.HttpClient.OnSendingRequest := procedure(Req: THttpRequest)
    begin
      Req.Timeout := 10000; // 10 seconds
    end;

Wagner R. Landgraf2016-11-18 13:00:27

Hi Wagner,

Does this time also includes the response timeout or this is just connenct time out?

Thanks in advance,

Omar Zelaya

It includes the response timeout.

Is there a way to set connect, send and receive timeouts separately(Like TNetHTTPClient component).

I have a situation where call to a server method can take up 10 minutes to complete. The problem here is that right now with Req.Timeout set to 10 minutes, if the server is down, it will still wait 10 minutes to throw exception that there is no response from server and the poblem here is actually a connection problem.

Is there a way to avoid this?

Thanks in advance,

Omar Zelaya

An idea for you. If you have server requests that take a really long time (like 10 minutes), it might be an idea to have a second server endpoint that the client can invoke to monitor the long-running process more frequently, particularly if there is some way to tell how far along the server process is in its work.

For example, in the long-running server process, it could post a value to a shared resource of some kind indicating where it is in its work - like number of records processed or something like that, or even that it is "working for 90s, working for 120s" or some other "I'm working" progress message, along with a unique key provided by the client when the long-running server process was first invoked.

The client could then periodically (say, every 10s) call the second endpoint with the same key to retrieve the current progress message from that shared resource, and then update the client UI with that message or some other derived indication that the long-running server process is still running.

2 Likes

I'd follow @AndrewSimard suggestion. A 10 minute timeout is really big.