Invalid sync sequence ID for remote ID 'X'

[Former Member]

Hello experts,

I've faced this issue for a long time and I hope you guys could help me with this.

Sometimes when the sync is cancelled in the app an error of upload occurs, with the "invalid sync sequence ID" description in the server.

We've been using the SQLAnywhere 16 2127 and UltraliteJ for Android. The sync is canceled using the 'syncProgress' callback from 'SyncObserver' class.

Looking for evidences in the server log, I've noticed that the transaction of the canceled sync is commited, but after a bit of time a log of 'connection drop' is logged.

This error is a little bit hard to reproduce, but it affects hundred of users every week in my company.

After that, I'm only able to sync again with this user if I start a new sync with a new database.

Any suggestions of what could be happening?

I. 2015-08-26 11:06:49. <1084> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-26 11:06:49. <1084> The current synchronization is using a connection with connection ID 'SPID 262'
I. 2015-08-26 11:06:49. <1084> The authenticate_parameters script returned 1000
I. 2015-08-26 11:06:49. <1084> COMMIT Transaction: Authenticate user
I. 2015-08-26 11:06:49. <1084> COMMIT Transaction: Begin synchronization
I. 2015-08-26 11:06:49. <1084> COMMIT Transaction: Prepare for download
I. 2015-08-26 11:06:50. <1084> Sending the download to the remote database
I. 2015-08-26 11:06:50. <1084> COMMIT Transaction: Download
I. 2015-08-26 11:06:57. <1084> COMMIT Transaction: End synchronization
I. 2015-08-26 11:10:54. <1085> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-26 11:10:54. <1085> The current synchronization is using a connection with connection ID 'SPID 262'
I. 2015-08-26 11:10:54. <1085> The authenticate_parameters script returned 1000
I. 2015-08-26 11:10:54. <1085> COMMIT Transaction: Authenticate user
I. 2015-08-26 11:10:54. <1085> The sync sequence ID in the consolidated database: 66e705a64bc911e58000d4b26ffaac50; the remote previous sequence ID: ac77d1964bc811e58000d4b26ffaac50, and the current sequence ID: f8e572bc4bc911e580009bbc92b92a77
E. 2015-08-26 11:10:54. <1085> [-10400] Invalid sync sequence ID for remote ID '2'
I. 2015-08-26 11:10:54. <1085> Synchronization failed
E. 2015-08-26 11:10:59. <1084> [-10279] Connection was dropped due to lack of network activity
I. 2015-08-26 11:10:59. <1084> Synchronization complete

A new log with verbosity -vp

I. 2015-08-27 16:05:16. <38> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-27 16:05:16. <38> The current synchronization is using a connection with connection ID 'SPID 366'
I. 2015-08-27 16:05:16. <38> The authenticate_parameters script returned 1000
I. 2015-08-27 16:05:16. <38> COMMIT Transaction: Authenticate user
I. 2015-08-27 16:05:16. <38> Publication #1: ul_default_pub, subscription id: 1, last download time: 2015-08-27 16:05:06.727000
I. 2015-08-27 16:05:16. <38> The sync sequence ID in the consolidated database: 3c4236b04cbc11e58000c12fcb6170e4; the remote previous sequence ID: 3c4236b04cbc11e58000c12fcb6170e4, and the current sequence ID: 41d955e04cbc11e58000c12fcb6170e4
I. 2015-08-27 16:05:16. <38> Last upload time for subscription id 1: 2015-08-27 15:41:13.180000
I. 2015-08-27 16:05:16. <38> Generation number for publication 'ul_default_pub' is 1
I. 2015-08-27 16:05:16. <38> COMMIT Transaction: Begin synchronization
I. 2015-08-27 16:05:17. <38> COMMIT Transaction: Prepare for download
I. 2015-08-27 16:05:17. <38> Next last download timestamp fetched from the consolidated database is "2015-08-27 16:05:16.297000"
I. 2015-08-27 16:05:18. <38> Sending the download to the remote database
I. 2015-08-27 16:05:18. <38> COMMIT Transaction: Download
I. 2015-08-27 16:05:24. <38> COMMIT Transaction: End synchronization
I. 2015-08-27 16:06:13. <39> Request from "UL 16.0.2087" for: remote ID: 1009, user name: 17, version: XXX
I. 2015-08-27 16:06:13. <39> The current synchronization is using a connection with connection ID 'SPID 366'
I. 2015-08-27 16:06:13. <39> The authenticate_parameters script returned 1000
I. 2015-08-27 16:06:13. <39> COMMIT Transaction: Authenticate user
I. 2015-08-27 16:06:13. <39> Publication #1: ul_default_pub, subscription id: 1, last download time: 2015-08-27 16:04:35.817000
I. 2015-08-27 16:06:13. <39> The sync sequence ID in the consolidated database: 874340d9d4404fc995874938ed708bc5; the remote previous sequence ID: 874340d9d4404fc995874938ed708bc5, and the current sequence ID: 137635d70da644e089e8e42c3ab092cb
I. 2015-08-27 16:06:13. <40> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-27 16:06:13. <40> The current synchronization is using a connection with connection ID 'SPID 357'
I. 2015-08-27 16:06:13. <40> The authenticate_parameters script returned 1000
I. 2015-08-27 16:06:13. <40> COMMIT Transaction: Authenticate user
I. 2015-08-27 16:06:13. <40> Publication #1: ul_default_pub, subscription id: 1, last download time: 2015-08-27 16:05:06.727000
I. 2015-08-27 16:06:13. <40> The sync sequence ID in the consolidated database: 41d955e04cbc11e58000c12fcb6170e4; the remote previous sequence ID: 3c4236b04cbc11e58000c12fcb6170e4, and the current sequence ID: 64255a684cbc11e58000d4570e72fa59
E. 2015-08-27 16:06:13. <40> [-10400] Invalid sync sequence ID for remote ID '2'
I. 2015-08-27 16:06:14. <40> Synchronization failed

A new log with download/upload scenario:

I. 2015-07-31 05:44:16. <1361> Request from "UL 16.0.2087" for: remote ID: 190, user name: 99, version: XXX
I. 2015-07-31 05:44:16. <1361> The current synchronization is using a connection with connection ID 'SPID 110'
I. 2015-07-31 05:44:16. <1361> The authenticate_parameters script returned 1000
I. 2015-07-31 05:44:16. <1361> COMMIT Transaction: Authenticate user
I. 2015-07-31 05:44:16. <1361> COMMIT Transaction: Begin synchronization
I. 2015-07-31 05:44:16. <1361> COMMIT Transaction: Upload
I. 2015-07-31 05:44:17. <1361> COMMIT Transaction: Prepare for download
I. 2015-07-31 05:44:28. <1361> Sending the download to the remote database
I. 2015-07-31 05:44:30. <1361> COMMIT Transaction: Download
I. 2015-07-31 05:44:31. <1362> Request from "UL 16.0.2087" for: remote ID: 190, user name: 99, version: XXX
E. 2015-07-31 05:44:31. <1362> [-10341] The remote database identified by remote ID '190' may already be synchronizing: unable to lock that remote ID
I. 2015-07-31 05:44:32. <1363> Request from "UL 16.0.2087" for: remote ID: 190, user name: 99, version: XXX
E. 2015-07-31 05:44:32. <1363> [-10341] The remote database identified by remote ID '190' may already be synchronizing: unable to lock that remote ID
I. 2015-07-31 05:44:33. <1363> The current synchronization is using a connection with connection ID 'SPID 112'
I. 2015-07-31 05:44:33. <1363> The authenticate_parameters script returned 1000
I. 2015-07-31 05:44:33. <1363> COMMIT Transaction: Authenticate user
E. 2015-07-31 05:44:33. <1363> [-10341] The remote database identified by remote ID '190' may already be synchronizing: unable to lock that remote ID
I. 2015-07-31 05:44:33. <1363> Synchronization failed
I. 2015-07-31 05:44:37. <1361> COMMIT Transaction: End synchronization
I. 2015-07-31 05:45:25. <1364> Request from "UL 16.0.2087" for: remote ID: 190, user name: 99, version: XXX
I. 2015-07-31 05:45:25. <1364> The current synchronization is using a connection with connection ID 'SPID 110'
I. 2015-07-31 05:45:25. <1364> The authenticate_parameters script returned 1000
I. 2015-07-31 05:45:25. <1364> COMMIT Transaction: Authenticate user
I. 2015-07-31 05:45:25. <1364> The sync sequence ID in the consolidated database: e41b0e0add35460091ca651ce0ee2633; the remote previous sequence ID: 25acf6af47234c1192f7203343b5e93e, and the current sequence ID: 1c20ad4023d44353a7b32d021c698c74
E. 2015-07-31 05:45:25. <1364> [-10400] Invalid sync sequence ID for remote ID '190'
I. 2015-07-31 05:45:26. <1364> Synchronization failed
E. 2015-07-31 05:48:26. <1361> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-31 05:48:26. <1361> Synchronization complete

And a very complex scenario which I couldn't figure out what could be happening? Maybe a simultaneos sync in the same device?

I. 2015-07-29 08:07:32. <1112> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:07:46. <1113> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:07:46. <1113> The current synchronization is using a connection with connection ID 'SPID 91'
I. 2015-07-29 08:07:46. <1113> The authenticate_parameters script returned 1000
I. 2015-07-29 08:07:46. <1113> COMMIT Transaction: Authenticate user
I. 2015-07-29 08:07:46. <1113> COMMIT Transaction: Begin synchronization
I. 2015-07-29 08:07:46. <1113> COMMIT Transaction: Upload
I. 2015-07-29 08:07:48. <1113> COMMIT Transaction: Prepare for download
I. 2015-07-29 08:07:58. <1113> Sending the download to the remote database
I. 2015-07-29 08:08:00. <1113> COMMIT Transaction: Download
I. 2015-07-29 08:08:08. <1113> COMMIT Transaction: End synchronization
I. 2015-07-29 08:08:12. <1114> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:08:12. <1114> The current synchronization is using a connection with connection ID 'SPID 91'
I. 2015-07-29 08:08:12. <1114> The authenticate_parameters script returned 1000
I. 2015-07-29 08:08:12. <1114> COMMIT Transaction: Authenticate user
I. 2015-07-29 08:08:12. <1114> COMMIT Transaction: Begin synchronization
I. 2015-07-29 08:08:12. <1114> COMMIT Transaction: Upload
I. 2015-07-29 08:08:13. <1114> COMMIT Transaction: Prepare for download
I. 2015-07-29 08:08:21. <1115> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:08:21. <1115> The current synchronization is using a connection with connection ID 'SPID 82'
I. 2015-07-29 08:08:21. <1115> The authenticate_parameters script returned 1000
I. 2015-07-29 08:08:21. <1115> COMMIT Transaction: Authenticate user
E. 2015-07-29 08:08:21. <1115> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:08:21. <1115> Synchronization failed
I. 2015-07-29 08:08:22. <1114> Sending the download to the remote database
I. 2015-07-29 08:08:25. <1114> COMMIT Transaction: Download
I. 2015-07-29 08:08:33. <1114> COMMIT Transaction: End synchronization
I. 2015-07-29 08:08:40. <1116> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:08:40. <1116> The current synchronization is using a connection with connection ID 'SPID 91'
I. 2015-07-29 08:08:40. <1116> The authenticate_parameters script returned 1000
I. 2015-07-29 08:08:40. <1116> COMMIT Transaction: Authenticate user
I. 2015-07-29 08:08:41. <1116> COMMIT Transaction: Begin synchronization
I. 2015-07-29 08:08:41. <1116> COMMIT Transaction: Upload
I. 2015-07-29 08:08:42. <1116> COMMIT Transaction: Prepare for download
I. 2015-07-29 08:08:48. <1117> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:08:48. <1117> The current synchronization is using a connection with connection ID 'SPID 82'
I. 2015-07-29 08:08:48. <1117> The authenticate_parameters script returned 1000
I. 2015-07-29 08:08:48. <1117> COMMIT Transaction: Authenticate user
E. 2015-07-29 08:08:48. <1117> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:08:48. <1117> Synchronization failed
I. 2015-07-29 08:08:52. <1116> Sending the download to the remote database
I. 2015-07-29 08:08:54. <1116> COMMIT Transaction: Download
I. 2015-07-29 08:09:02. <1116> COMMIT Transaction: End synchronization
I. 2015-07-29 08:09:13. <1118> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:09:13. <1118> The current synchronization is using a connection with connection ID 'SPID 91'
I. 2015-07-29 08:09:13. <1118> The authenticate_parameters script returned 1000
I. 2015-07-29 08:09:13. <1118> COMMIT Transaction: Authenticate user
I. 2015-07-29 08:09:13. <1118> COMMIT Transaction: Begin synchronization
I. 2015-07-29 08:09:13. <1118> COMMIT Transaction: Upload
I. 2015-07-29 08:09:15. <1118> COMMIT Transaction: Prepare for download
I. 2015-07-29 08:09:20. <1119> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:09:20. <1119> The current synchronization is using a connection with connection ID 'SPID 82'
I. 2015-07-29 08:09:20. <1119> The authenticate_parameters script returned 1000
I. 2015-07-29 08:09:20. <1119> COMMIT Transaction: Authenticate user
E. 2015-07-29 08:09:20. <1119> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:09:20. <1119> Synchronization failed
I. 2015-07-29 08:09:25. <1118> Sending the download to the remote database
I. 2015-07-29 08:09:27. <1118> COMMIT Transaction: Download
I. 2015-07-29 08:09:27. <1120> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:09:27. <1120> The current synchronization is using a connection with connection ID 'SPID 82'
I. 2015-07-29 08:09:27. <1120> The authenticate_parameters script returned 1000
I. 2015-07-29 08:09:27. <1120> COMMIT Transaction: Authenticate user
E. 2015-07-29 08:09:27. <1120> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:09:33. <1121> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
E. 2015-07-29 08:09:33. <1121> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:09:33. <1121> The current synchronization is using a connection with connection ID 'SPID 82'
I. 2015-07-29 08:09:33. <1121> The authenticate_parameters script returned 1000
I. 2015-07-29 08:09:33. <1121> COMMIT Transaction: Authenticate user
E. 2015-07-29 08:09:33. <1121> [-10341] The remote database identified by remote ID '170' may already be synchronizing: unable to lock that remote ID
I. 2015-07-29 08:09:35. <1118> COMMIT Transaction: End synchronization
I. 2015-07-29 08:09:39. <1122> Request from "UL 16.0.2087" for: remote ID: 170, user name: 11, version: XXX
I. 2015-07-29 08:09:39. <1122> The sync sequence ID in the consolidated database: 8064c8e9c74d496daacfc651456dbece; the remote previous sequence ID: 3a1fe564a0eb4d0b808709e078925e3b, and the current sequence ID: 7f42f25b36854bacb328cacb822bd6fc
E. 2015-07-29 08:09:39. <1122> [-10400] Invalid sync sequence ID for remote ID '170'
I. 2015-07-29 08:09:39. <1122> Synchronization failed
E. 2015-07-29 08:11:36. <1112> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:11:36. <1112> Synchronization complete
E. 2015-07-29 08:12:00. <1113> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:12:00. <1113> Synchronization complete
E. 2015-07-29 08:12:20. <1114> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:12:20. <1114> Synchronization complete
E. 2015-07-29 08:12:47. <1116> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:12:47. <1116> Synchronization complete
E. 2015-07-29 08:13:18. <1118> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:13:18. <1118> Synchronization complete
E. 2015-07-29 08:13:32. <1120> [-10279] Connection was dropped due to lack of network activity
I. 2015-07-29 08:13:32. <1120> Synchronization failed

[Former Member]

I don't see a COMMIT for upload. Does your application set the Download Only synchronization parameter?

[Former Member]

We're investigating if there is a potential problem specific to cancelling download-only synchronizations. As an experiment or potential workaround, you could try disabling the Download Only sync parameter in your Android application. (If there are any changes on the remote to downloaded tables, you may also need to define ignored upload_insert and upload_update scripts.)

[Former Member]

There is some scenarios (not in general) where the download-only can be used. But, unfortunatelly, we cannot disable that to avoid data inconsistent (not allowed upload of data which may colide with others). I'll include this scenario in my tests. Tks.

[Former Member]

EDIT: The sequence ID error has happened again in the production servers in the last week, as shown in the third log of my question. A little brief of one of the POSSIBLE user-case scenario (not reproduced!): the user is syncing, then the application is closed, which closes the app process too. Then (and whenever the app process is killed) our sync engine is reinitialized, which may start a new sync immediatly (if the previous one failed). Analysing the logs, it seems the first connection is lost (the process was killed, then the connection became orphan). And when a new sync is started, the Ultralite accepts it without finishing the orphan connection, which leads to the sequence ID error. Could you check the code about this scenario? Please, take in consideration that the process is killed and restarted. Maybe (and makes sense, due the other comments about the sync id and process relation) this can be the root of all the problems.

[Former Member]

What is this connection ID (SPID)? Is it a server-side or client-side information? And what can be happening so that the log has this information of same SPID for different syncs?

[Former Member]

EDIT 2: Added a very complex scenario in the 4th log

[Former Member]

The connection ID identifies which MobiLink database connection is being used out of the MobiLink server's pool of database connections to the consolidated database, as returned from consolidated database.

[Former Member]

The third log shows 3 concurrent syncs! The two things that make me uncomfortable are:
1. Killing the app with every sync cancellation.
2. Retrying sync after less time than the timeout time.

[Former Member]

Maybe the sync is not being canceled, because the process can be killed if the user swype the app from the "recent apps" grid. Perhaps it can be a issue? About the retry, maybe we can implement a mechanism to wait the minimum time from Mobilink at the sync engine startup, but we cannot ignore the user's request, at a button click, for example. That is the way this workaround couldn't be implemented.

[Former Member]

How have you concluded about the concurrent syncs? When a sync is finished? There is a gap between the "End synchronization" message and the sync end that I could not understand.

[Former Member]

The "COMMIT Transaction: End synchronization" message indicates that sync has finished with it's consolidated database connection. However the ML server worker thread from that sync still has a network connection to the remote, and is trying to send the download. Sync 1361 doesn't end till the network timeout 229 seconds later (238s after starting to send download).

If you want the network timeout to be shorter, use SyncParms.setLivenessTimeout.

If you set that to 30 seconds (the minimum recommended) and have your app wait 30 seconds on startup before enabling the sync function, then at least cancelled/killed syncs could complete before new sync requests from the same remote ID.

[Former Member]

In case you weren't aware of it, the MobiLink Performance whitepaper provides an overview of what happens during a synchronization. The description on pages 3-6 of MobiLink 12 Performance applies to version 16 and 17.

[Former Member]

We have already set this timeout in the Production server and avoided the sync engine start until this time (30s) is reached. However we cannot ignore the explicity user request. How should we proceed? Is there any other workaround? It is safe to assume that this is a ML issue or we are doing something wrong in the client side?

[Former Member]

I didn't know this documentation. Tks a lot 😃

[Former Member]

Since your log showed network timeout taking the 238s and the default for Android is 240s, I assumed you were using the default.

Are those logs not from production? If not, why did you stop using -vp verbosity?

This problem could be happening if Android returns success when UltraLite commits, before writing to persistent storage is completed, and the killing of the app prevents persisting of the commit.

If the app has been cleared from memory by user clearing it away, why not show a busy animation and not enable the Sync button for 30s on initial startup?

(My Android phone has at least one app that takes a minute to start up after clearing from memory.)

[Former Member]

We have a dozen of environments using ML 16. And almost all of them is facing this sequence ID error. The verbosity that I've turned on was in another environment (changing production configurations is not so simple, involves service unavailability and other headaches). I can wait the 30s (the app startup takes 5secs only) but let's agree that this is not the best solution for the user POV. All I'd like to know is if someone is going to investigate this problem and treat it like a bug. If so, we can wait for a better solution.

[chris_keating]

We are going to treat this as a bug but we will need to be able to reproduce it or gather sufficient logging information to understand the cause.

[Former Member]

If your app takes 5 seconds to startup, why is there only 1 second between sync requests 1362 and 1363?

I still suspect duplicate remote IDs, since that fits the symptoms. When other customers have reported this problem, that has ultimately been determined to be the cause.

You said that remote IDs are assigned from a sequence in the consolidated. Please detail how that gets back to the remote device before that device's first MobiLink synchronization occurs.

A possible experiment would be to try using default remote IDs, and see if the problem still happens. (If you want a non-GUID identifier for each remote device, then use the synchronization user instead of the remote ID).

[Former Member]

We assign the remote id during the device provision (first app startup in the device), performing the first authentication, creating the remote id (identity SQLServer column) and assigning to the database. So, a pair of user-device is strict related with only one database and vice-versa. There is no way in which duplicated remote ids perform syncs because our sync logic relies on it. Our product do allow the provision of two or more devices for the same user, however each pair of user/device has a different remote id configuration.

In a very simplified representation of our model we have: Entity: mobileDB Properties: idMobileDB (identity), idUser (get from login), deviceIdentifier (get from the device serial number)

All the sequence IDs seems to be related with some connection loss. The reason why the sync starts after 1 sec is explained in the use-case at the beggining of this comment thread (just after the process is killed, the sync engine is automatically initialized again - just the service, not the UI -, which may start another sync immediatly without user interaction).

For the same reason I've talked in the first part of this comment, we cannot change the way the remote ids are assigned (changing back to its default) because we use the remote id within the user id to make relations between entities during the sync download/upload (different data may be downloaded depending on which device an user is syncing or two devices of the same user performing data download). The only scenario in which two mobile DBs can sync at the same time is two device related with the same user containing the same serial number. And I've already checked it and it is not the case.

I'll work on a reproduction as I've made with the download-only scenario. Then, I let you know. Meanwhile, I hope you good luck with some insight about this issue =p

Tks, in advance.

[Former Member]

I was puzzled by 1363 starting 1 second after 1362 because you said a few comments ago that your sync engine waits 30 seconds before retrying, but now you say the sync engine retries right away.

[Former Member]

I've implemented this waiting in one production environment, but after the log retrieving. I have no logs after this change yet. As soon as I have it I let you know.

[Former Member]

A quick update: in the production environment where the sync is restarted after 1 sec an iOS client is executing the sync. I'll check with the iOS team about any potential bug in which concurrent syncs could be performed.

[Former Member]

I've reproduced an scenario which leads to this issue (and I hope all the others derives from this one, for the sake of simplicity =p)

Steps to reproduce (using an Android device with UltraliteJ 16 2127):

1) Synchronize the client 2) As soon as the message "COMMIT Transaction: Download" is logged on the Mobilink log, close the application 3) Start the application again the synchronize the client. The error will occurs.

Note that the first synchronization hangs on the connection until the timeout of this connection is reached.

I've tried different sync parameters, even enabling/disabling the download ack, but without success.

Can I consider this issue as a bug?

I. 2015-08-27 16:50:40. <435> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-27 16:50:40. <435> The current synchronization is using a connection with connection ID 'SPID 357'
I. 2015-08-27 16:50:40. <435> The authenticate_parameters script returned 1000
I. 2015-08-27 16:50:40. <435> COMMIT Transaction: Authenticate user
I. 2015-08-27 16:50:40. <435> Publication #1: ul_default_pub, subscription id: 1, last download time: 2015-08-27 16:50:23.517000
I. 2015-08-27 16:50:40. <435> The sync sequence ID in the consolidated database: 8fbe74104cc211e58000a93d68080ea7; the remote previous sequence ID: 8fbe74104cc211e58000a93d68080ea7, and the current sequence ID: 992957904cc211e58000a93d68080ea7
I. 2015-08-27 16:50:40. <435> Last upload time for subscription id 1: 2015-08-27 15:41:13.180000
I. 2015-08-27 16:50:40. <435> Generation number for publication 'ul_default_pub' is 1
I. 2015-08-27 16:50:40. <435> COMMIT Transaction: Begin synchronization
I. 2015-08-27 16:50:40. <435> COMMIT Transaction: Prepare for download
I. 2015-08-27 16:50:40. <435> Next last download timestamp fetched from the consolidated database is "2015-08-27 16:50:39.337000"
I. 2015-08-27 16:50:41. <435> Sending the download to the remote database
I. 2015-08-27 16:50:41. <435> COMMIT Transaction: Download
I. 2015-08-27 16:50:47. <435> COMMIT Transaction: End synchronization
I. 2015-08-27 16:51:13. <436> Request from "UL 16.0.2127" for: remote ID: 2, user name: 24, version: XXX
I. 2015-08-27 16:51:13. <436> The current synchronization is using a connection with connection ID 'SPID 357'
I. 2015-08-27 16:51:13. <436> The authenticate_parameters script returned 1000
I. 2015-08-27 16:51:13. <436> COMMIT Transaction: Authenticate user
I. 2015-08-27 16:51:13. <436> Publication #1: ul_default_pub, subscription id: 1, last download time: 2015-08-27 16:50:23.517000
I. 2015-08-27 16:51:13. <436> The sync sequence ID in the consolidated database: 992957904cc211e58000a93d68080ea7; the remote previous sequence ID: 8fbe74104cc211e58000a93d68080ea7, and the current sequence ID: ad024bd24cc211e58000e6d39f5d0b49
E. 2015-08-27 16:51:13. <436> [-10400] Invalid sync sequence ID for remote ID '2'
I. 2015-08-27 16:51:13. <436> Synchronization failed
E. 2015-08-27 16:54:48. <435> [-10279] Connection was dropped due to lack of network activity
I. 2015-08-27 16:54:48. <435> Synchronization complete

[Former Member]

As I feared, for a download-only sync killing the app before UltraLite has finished a sync may leave the UltraLite database in a bad state.

As a workaround, try disabling the Download Only sync parameter in your Android application.

To avoid any changes from remotes being applied to the consolidated database, for each synchronized table define upload_insert and upload_update scripts as '--{ml_ignore}'. That will prevent any changes from the remotes, equivalent to using download-only syncs.

[Former Member]

We are not using the download-only parameter. In this case, the Ultralite is skipping the upload because there is no data to upload. So, this workaround is not valid for us. Any other possible workaround?

[Former Member]

Another developer double checked the MobiLink server source code, and you would have upload commit messages in the log if your app is doing bidirectional syncs. Look for calls to SyncParms.setDownloadOnly (and maybe call that with false).

BTW, instead of recreating a remote after the problem hits, you should be able to get that remote syncing again by using the ml_reset_sync_state stored procedure.

[Former Member]

Sorry Graham, you were right. In my reproduction I was using the download-only configuration. With download/upload syncs I couldn't reproduce this issue. I've already known this procedure to reset the sync state, tks. We've been using it for months. This sequence ID issue could be reproduced more frequently in old versions of Mobilink. Subsequentials canceled syncs could lead to this issue. But we've got rid of a part of these issues (about canceled/restarted syncs) after migrating to the 2127 patch. We've still some users dealing with this sequence ID error, as reported in other questions, like the following one. I hope you guys have a better luck looking into this =] http://scn.sap.com/message/15859094#15859094

[Former Member]

Graham, the sequence ID error has happened again with a dozen of users in the last week. All the users had performed download/upload operations, instead of the download-only scenario that I've reproduced. Could you check the third code of my question to analyze it? I couldn't reproduce this scenario, but checking the logs, it seems the Ultralite is accepting a new sync request before finishing the last operation (that failed with connectivity issues).