Has anyone experienced this error that we have been seeing? Beginning around last December, we began receiving errors in our A5XbasicErrorStackLog.txt “The client is no longer connected.” We are using IIS server for Alpha and MariaDB for our database. We currently use Alpha 5647, but it appears the problem began with 5487. We use PhoneGap 8.0, and the tablets that run our app are on Android 7.1.
I reached out to Sewlyn and he did confirm that a change was made to the IIS server in build 5321 in which if the server detects that the client (i.e. the browser) has "gone away" (i.e. stopped listening for a response), then a message is sent to the Xbasic processor to stop processing.
We also got help from Terry Smith, who stated that “A lost connection can be deliberate with a user cancelling a request by clicking the browser's cancel button. Or a lost connection can be due network connectivity being lost and not recoverable. Unfortunately, Application Server for IIS does not know the difference. It only knows that IIS has marked the client as no longer connected.”
However, I am pretty sure this is not the cause of our error. When I install the app for our user, everything syncs fine for a week or so. Then he begins getting alerts that the AJAX callback is failing (using the saveListEdits command). After he begins having problems, then every sync will result in the AJAX callback fail and an error “The client is no longer connected” in the log. It doesn’t really seem related to network issues or the user somehow canceling the sync. I then must clear all the data for the app and have the user log in again, in which case he is able to sync fine again for another week or so and then will begin with the same problem again.
Other info that might be helpful is that the list that is having trouble syncing has children and grandchildren. It also should be noted that they all have auto increment integers as the primary key. When the order is created the auto increment value is usually blank until we sync, in which the database will give it the correct Primary Key value. When we begin having trouble syncing, it appears that the AJAX callback fails and the list stays dirty and the primary key is not retrieved. However, what is really strange is that the data is written to our database. If the user tries to sync again, the same data is sent (which makes sense because it is still dirty), which usually results in duplicate information being synced. Eventually though, not all of the user’s orders will sync (perhaps the data to send becomes too large).
Back when we first began having trouble last December, I the thing I did to get it to work was to publish in an older version of Alpha (5221), then opened the 5221 client, recalculated my controls, and did an Instant Update in Phone Gap, changing my AJAX URL to the one just published with version 5221. After doing this, all orders synced fine just as they always have. However, going back to 5221 at this point may not be possible as Alpha has introduced new features in the newer releases that our app currently uses. But this leads me to believe that something was introduced in 5321 that is causing our problem.
I would like to formulate a test case to send to Alpha to demonstrate the problem, although it is difficult for me to reproduce exactly what cause the problem to begin happening in the first place. I was wondering if anyone else has a similar problem, or at least could point me in the right direction as to things I could try to try to solve the problem. Thank you.
Code:
========================================================== INFO: Tue Apr 30 09:49:10 2019 Client is no longer connected (Cancelation token). Processing started at 2019-04-30T14:48:20.5088847Z UTC Disconnect detected at 2019-04-30T14:49:10.4777268Z UTC Duration 00:00:49.9688421 Request Method: POST Request: /mSales5_1_5647_Prod/MSALES5_MAIN_UX.a5wcmp?__virtualPage=__a5RunDialog.a5w&__dialogFilename=MSALES5_MAIN_UX&__alias=DLG1&__unsaved=no ========================================================== Tue Apr 30 09:49:11 2019 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ========================================================== Tue Apr 30 09:49:11 2019 Thread: t0 Request URI: /mSales5_1_5647_Prod/MSALES5_MAIN_UX.a5wcmp?__virtualPage=__a5RunDialog.a5w&__dialogFilename=MSALES5_MAIN_UX&__alias=DLG1&__unsaved=no (from 166.137.126.107) Script: /mSales5_1_5647_Prod/__a5RunDialog.a5w Line: 183 x_out = a5_ajax_dialog2(tmpl) Script:a5_sql_nested_query_to_json_document() line:1386 A5W: The client is no longer connected. Execution Stack: 0#183 x_out = a5_ajax_dialog2(tmpl) ==========================================================
We also got help from Terry Smith, who stated that “A lost connection can be deliberate with a user cancelling a request by clicking the browser's cancel button. Or a lost connection can be due network connectivity being lost and not recoverable. Unfortunately, Application Server for IIS does not know the difference. It only knows that IIS has marked the client as no longer connected.”
However, I am pretty sure this is not the cause of our error. When I install the app for our user, everything syncs fine for a week or so. Then he begins getting alerts that the AJAX callback is failing (using the saveListEdits command). After he begins having problems, then every sync will result in the AJAX callback fail and an error “The client is no longer connected” in the log. It doesn’t really seem related to network issues or the user somehow canceling the sync. I then must clear all the data for the app and have the user log in again, in which case he is able to sync fine again for another week or so and then will begin with the same problem again.
Other info that might be helpful is that the list that is having trouble syncing has children and grandchildren. It also should be noted that they all have auto increment integers as the primary key. When the order is created the auto increment value is usually blank until we sync, in which the database will give it the correct Primary Key value. When we begin having trouble syncing, it appears that the AJAX callback fails and the list stays dirty and the primary key is not retrieved. However, what is really strange is that the data is written to our database. If the user tries to sync again, the same data is sent (which makes sense because it is still dirty), which usually results in duplicate information being synced. Eventually though, not all of the user’s orders will sync (perhaps the data to send becomes too large).
Back when we first began having trouble last December, I the thing I did to get it to work was to publish in an older version of Alpha (5221), then opened the 5221 client, recalculated my controls, and did an Instant Update in Phone Gap, changing my AJAX URL to the one just published with version 5221. After doing this, all orders synced fine just as they always have. However, going back to 5221 at this point may not be possible as Alpha has introduced new features in the newer releases that our app currently uses. But this leads me to believe that something was introduced in 5321 that is causing our problem.
I would like to formulate a test case to send to Alpha to demonstrate the problem, although it is difficult for me to reproduce exactly what cause the problem to begin happening in the first place. I was wondering if anyone else has a similar problem, or at least could point me in the right direction as to things I could try to try to solve the problem. Thank you.
Comment