cancel
Showing results for 
Search instead for 
Did you mean: 

SUP2.1 whats happend while SYNC_STATE_RECEIVING_UPLOAD_ACK

Former Member
0 Kudos

Hallo,

we are create a native iOS-App with SUP2.1#3. The syncronisation (replication based) with the SUP works but sometimes it happens that the Callbackhandler give us the message SYNC_STATE_RECEIVING_UPLOAD_ACK back and that fore a time of 2 minutes. You can see the log here:

2013-01-10 09:41:53.496 SM4R sales BF[SUPCallbackHandler.m:77] Synchronization response

2013-01-10 09:41:53.496 SM4R sales BF[SUPCallbackHandler.m:78] =================================================

2013-01-10 09:41:53.496 SM4R sales BF[SUPCallbackHandler.m:81] group = default

2013-01-10 09:41:53.497 SM4R sales BF[SUPCallbackHandler.m:83] =================================================

2013-01-10 09:41:53.497 SM4R sales BF[SUPCallbackHandler.m:86] context: 1, (null)

2013-01-10 09:41:53.497 SM4R sales BF[SUPCallbackHandler.m:110] =================================================

2013-01-10 09:41:53.539 SM4R sales BF[SUPConnectionManager.m:401] SYNC_STATE_STARTING

2013-01-10 09:41:53.540 SM4R sales BF[SUPConnectionManager.m:404] SYNC_STATE_CONNECTING

2013-01-10 09:41:53.575 SM4R sales BF[SUPConnectionManager.m:407] SYNC_STATE_SENDING_HEADER

2013-01-10 09:41:53.579 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.579 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.580 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.580 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.580 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.581 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.581 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.581 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.581 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.582 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.582 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.582 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.583 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.583 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.583 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.584 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.584 SM4R sales BF[SUPConnectionManager.m:413] SYNC_STATE_SENDING_DATA

2013-01-10 09:41:53.584 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.585 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.585 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.585 SM4R sales BF[SUPConnectionManager.m:410] SYNC_STATE_SENDING_TABLE

2013-01-10 09:41:53.586 SM4R sales BF[SUPConnectionManager.m:413] SYNC_STATE_SENDING_DATA

2013-01-10 09:41:53.586 SM4R sales BF[SUPConnectionManager.m:416] SYNC_STATE_FINISHING_UPLOAD

2013-01-10 09:41:53.602 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

2013-01-10 09:41:54.703 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

2013-01-10 09:41:55.706 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

2013-01-10 09:41:56.709 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

2013-01-10 09:41:57.712 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

...

2013-01-10 09:43:07.016 SM4R sales BF[SUPConnectionManager.m:419] SYNC_STATE_RECEIVING_UPLOAD_ACK

2013-01-10 09:43:07.332 SM4R sales BF[SUPConnectionManager.m:422] SYNC_STATE_RECEIVING_TABLE

It happens not every time we sync with the SUP. Sometimes the sync is very fast (20 sec) and sometime it needs 2 minutes because of the SYNC_STATE_RECEIVING_UPLOAD_ACK.

What happens in the SUP while the SYNC_STATE_RECEIVING_UPLOAD_ACK?

Did we something wrong in our synchronization implementation?

Thanks,

André


Accepted Solutions (1)

Accepted Solutions (1)

former_member184221
Contributor
0 Kudos

The mobilink sync sequence is:

UL_SYNC_STATE_STARTING No synchronization actions have yet been taken.

UL_SYNC_STATE_CONNECTING The synchronization stream has been built, but not yet opened.

UL_SYNC_STATE_SENDING_HEADER The synchronization stream has been opened, and the header is about to be sent.

UL_SYNC_STATE_SENDING_TABLE A table is being sent.

UL_SYNC_STATE_SENDING_DATA Schema information or data is being sent.

UL_SYNC_STATE_FINISHING_UPLOAD The upload stage is completed and a commit is being carried out.

UL_SYNC_STATE_RECEIVING_UPLOAD_ACK An acknowledgement that the upload is complete is being received.

UL_SYNC_STATE_RECEIVING_TABLE A table is being received.

UL_SYNC_STATE_RECEIVING_DATA Schema information or data is being received.

UL_SYNC_STATE_COMMITTING_DOWNLOAD The download stage is completed and a commit is being carried out.

UL_SYNC_STATE_SENDING_DOWNLOAD_ACK An acknowledgement that download is complete is being sent.

UL_SYNC_STATE_DISCONNECTING The synchronization stream is about to be closed.

UL_SYNC_STATE_DONE Synchronization has completed successfully.

UL_SYNC_STATE_ERROR Synchronization has completed, but with an error.

UL_SYNC_STATE_ROLLING_BACK_DOWNLOAD An error occurred during download and the download is being rolled back.

Therefore UL_SYNC_STATE_RECEIVING_UPLOAD_ACK means that data has been sent from iOS to the SUP server and the SUP server is processing that data. When SUP finishes it sends an acknowledgement back to iOS that the upload is complete is received.

Answers (0)