androidiis-7.5microsoft-sync-framework

MS Syncframework 4 - no response after 5 minutes of server side processing


Background:

We have set up a syncronization on an old production server with MS SyncFrameWork 4 between several MS SQL databases and android devices. The initial sync always took the longest but that time is not an issue since it only occurs the very first time a device is used.


Server details:


Issue:

If the database on the server is large - and the initial sync takes more than 5 minutes to process on the server side - the android client doesn't seem to get a response from the server and runs in a timeout.

Depending on the load of the server the initial sync process on the server side takes 3 to 10 minutes. If the initial sync succeeds there are no problems afterwards.

When checking the logs and traces we cannot find any error. The IIS working process seems to complete the task with no error even if it takes more than 5 minutes. But if

    public Message ProcessRequestForMessage(Stream messageBody)

in class Microsoft.Synchronization.Services.SyncService needs more than 5 minutes to complete, the android client does not get a response. Even if it is within the specified socket timeout of 900 seconds.

On the Android device occurs a IOException: java.net.SocketTimeoutException: Read timed out Exception after 900 seconds.

Code on Android side for initialization of httpClient:

    HttpParams httpParameters = new BasicHttpParams();
    int timeout = 900 * 1000;
    HttpConnectionParams.setConnectionTimeout(httpParameters, 5000);
    HttpConnectionParams.setSoTimeout(httpParameters, timeout);
    DefaultHttpClient httpclient = new DefaultHttpClient(httpParameters);

Later use:

    HttpResponse response = httpclient.execute(request);

What we tried:

So my questions are:

Edit for clarity:


Solution

  • The answer to my question:

    The code on both client and server side is OK. The culprit was the NAT 'TCP-Aging'-Setting in our LANCOM router. https://www.lancom-systems.com/docs/LCOS/menu-reference/topics/2_8_9_1.html

    It was configured to 300 seconds => 5 minutes ... So our router silently cut off the connection after idling for 5 minutes ...

    I understand it's not best practice to keep an idle connection alive for so long, but since this rarely occurs in our use case, it's ok for us.

    The answer to this post brought me on the right track: Netty websocket client does not read new frames from server after 5 minutes of being idle