Mobilink Communication Error -1305 in Ultralite on iPad During Synchronization

[Former Member]

Hi All, I am developing an iPad application. My dev environment set up is like

1. SQL Server 2008 as consolidated database.
2. SQLAnywhere 12.0.1 EBF 3605 as Mobilink Server.
   
3. Ultralite DB as client database on iPad. libulrt.a form 12.0.1 EBF 3577
   

I have implemented the synchronization model successfully. I have three different publications to synchronize. All are working fine. But if somehow any synchronization failed due to any issue either WIFI connectivity or if already have an open connection from Sybase Central tool. After this failure synchronization won't success for that particular ml-remote-id, no matter how many times i try. I am getting this errors:

Sync failed: -1305 (MOBILINK_COMMUNICATIONS_ERROR) %1:8 %2:7 %3:0

If i try again by changing ml-remote-id same publication will run successfully.
I am stuck with this issue. Please help.

[regdomaratzki]

Can you please add "-v+" to the MobiLink start line, and then post the Mobilink Server log with this high verbosity that includes :

1) The last successfull synchornization

2) The failed synchronization that causes the problem

3) The next synchronization that also fails

4) A successfull synchronization after changing the remote-id

Thanks, Reg

[Former Member]

Hi Reg Domaratzki,
Thanks for your valuable support and time. I have pasted the Server log after enabling -v+ option in mobilink start up script. You can find the log file Here.

[Former Member]

You can only have one sync running at a time for each remote. MobiLink will detect multiple concurrent syncs and will display the following error as seen in the log you posted,

E. 2012-04-19 16:24:17. <7> [-10344] The remote database identified by remote ID '893' is already synchronizing: orphaned UltraLite synchronization detected

MobiLink will try to clean up the scenario and return errors for the syncs it cancels. Concurrent syncs can be caused by the network connectivity disruption that you describe.

Would you be initiating multiple concurrent syncs from your application?

If you wait for more than 240 seconds (default client timeout) before you retry your sync, does it still fail?

The Sybase Central connection to which you refer, is that to your consolidated database?

Could you also post the command line you use to start MobiLink?

[Former Member]

Hi Bill,
I am not initiating concurrent sync.
I have tried syncing it after 4 min also that is also resulting to failure.
Yes the Sybase Central is my consolidated database.
My mobilink service initialization command is: -c "dsn=IRISIPAD;uid=IPADSYNC;pwd=tcs#1234" -vcns -o "C:IRISIPADlog.txt" -zu+ -cm 512m I was using this command. I replaced the -vcns option with -v+ as asked by Reg to generate the Log file.

[Former Member]

It looks like the log file has been truncated. Please post the full MobiLink server log file or the part that contains the previous syncs for remote ID 893 prior to sync <7>. Thanks.

[former_SQLA_member1694876]

Hi Gandalf,

Have you resolved this issue? It looks like we are waiting for a more complete log from you in order to proceed.

[Former Member]

Sorry Guys, i was on leave for few days.
No this problem is still there. I am uploading the complete Log file this time. From here you can get the information starting from the successful sync for a remote id and then failure and again subsequent failures for that id. Log file is Here
You can have this info for ml_remote_id = 705 & 707
Thanks in advance for all your support.

[Former Member]

Thanks you for posting the MobiLink server logging file. We have taken a look at the logging file and found you have had completed the first four successful syncs for remote ID 705 and then on the fifth one, the MobiLink server found a mismatch offset and abort the sync. The problem is why there is a mismatch offset for ID 705.

Unfortunately, we still cannot find the source for this problem, because the logging file does not contain any progress offset. Adding MobiLink server logging verbosity, -vep would be helpful. Could you please regenerate a MobiLink server logging file with the MobiLink server command line options, -vep?

It looks like remote ID 705 contains multiple publications. Could you please tell us how many publications remote ID 705 has and what publications you have used for each of the first five syncs (the first four successful syncs plus the fifth unsuccessful sync)?

Thanks

[Former Member]

Hopefully, you did not run the fifth sync for remote ID 705 with a backup database. If you backed up the remote database after the third sync and then run the sync with backup database on the fifth sync, this problem can happen. If this is what you wanted and if you are sure it won't lose data, you can reset the sync state for the remote ID in the consolidated database before the fifth sync, then you should not have this problem. To reset the sync state for a given remote ID, you can run the stored procedure named ml_reset_sync_state.

[Former Member]

Thanks for the support.
My sync model is having 3 publications. 1) Pub1 2) Pub2 3) Pub3.
The very first Sync attempt run all 3 publications sequentially. The next 3 syncs are using Pub1 & Pub3.

The fifth Sync which you saw failing is trying to run all publications as i deleted the project folder from IPAD simulator,as it is a requirement to run all pub if running for first time. but this is just an incident as i have tested this delete project kind of thing many times and this doesn't result to sync failure.

[Former Member]

No i am not taking backup of remote DB. The worst thing i am doing is Deleting the App sandbox so that there is no DB file present already, and i can start the Sync sequence again for same ml_remote_id.

[Former Member]

The ML server keeps a progress marker (or offset) for each remote ID and publication (in the ML system tables). So when you wipe the remote database and use the same remote ID, you get an error. You should either clear the remote ID (so a new one is generated) or use the ml_reset_sync_state stored procedure in the consolidated.

It's best to reset the remote ID when when you reset the remote database, which is why we now recommend using the ML user or an authentication parameter for data partitioning instead of using the remote ID.

[Former Member]

Should have said "when you wipe the remote database and use the same remote ID, you might get an error." See comments to answers.

[Former Member · Accepted solution]

Hi Guys, Thanks a lot to all, especially to Yufei. This got solved too.
I just ran the ml_reset_sync_state SP on server for remote id = 705 and it worked. But here is an observation i would like to share: 1. As Graham mentioned that after wiping the DB file you need to reset the remote id otherwise it will lead to Sync failure, but i have tested this many times and sync will run successfully with same remote id even if i am deleting it from the App Sandbox.

[Former Member · Accepted solution]

Thanks. Your observation is right, because the MobiLink server will always accept the initial sync after the remote database is rebuilt.

[Former Member · Accepted solution]

@Yufei: Thanks for reminding me that special handling of initial syncs had been added in an earlier version (I think it was version 10)!

@Gandalf: You probably saw the problem only after an initial sync failed after sending its upload, eg. because of a network error. In that case, the next sync could check the progress, so my advice still holds unless you can be certain that the first sync after remote reset won't fail.

[former_SQLA_member1694876]

Here's another point which may not apply but is still important 🙂

As of iOS 5.0.1, you should set the "do not backup" attribute on the database file (see Technical Q&A QA1719).

You should also specify the temp_dir connection parameter with the path to the app's tmp directory (use NSTemporaryDirectory()), so UltraLite's temporary file is not placed in the Documents directory. (By default, the temp file goes beside the database file.)

[former_SQLA_member1694876]

I'm not sure this totally fits, but I'll offer it anyway. When you first synchronize an UltraLite database it automatically takes on a unique remote-id (it generates a UUID to do this, and stores it in the database). The server relies on each remote database having a unique remote-id. If you copy a synchronized database, and subsequently continue synchronizing both copies, the uniqueness requirement will not be met and you will likely encounter errors. (The server log should clearly diagnose this issue.) So, the rule is if you copy a database you must clear the copy's remote-id before synchronizing it. This is done by executing 'SET OPTION ml_remote_id='.

[Former Member]

I am setting the ml_remote_id before synchronizing first time. I am not trying to sync this database copy from any other system. So ml_remote_id uniqueness is preserved. Problem starts after first sync failures.

[Former Member]

The uniqueness requirement is not just for a given point in time; there should only be one "sync progress" (or offset) for a remote ID. If you are wiping the remote DB file, and want to re-use a previously used remote ID, you have run the ml_reset_sync_state stored procedure in the consolidated database. Instead, you should not re-use a remote ID when a remote database is recreated - it's a different database after all.

[Former Member]

As Yufei has clarified, the MobiLink server automatically resets the progress for a previously-used remote ID if it's the first sync since the remote database was created. However if that first sync fails after sending its upload and before the MobiLink server commits its automatic progress reset, the next sync from that remote will fail.

[Former Member]

Update: In looking back, many holes in the progress checking logic have been filled over the years, so your problem should not be common. I suspect that it may be a case that only happens when using UltraLite remotes with multiple publications that have differing offsets, and following a failed initial sync with a re-used remote ID.

It's best to leave the remote ID alone. If you have been using it for data partitioning or business logic, instead use either the MobiLink user or an authentication parameter.