Sometimes I hear of remote-users that have mobilink synchronizations that take for hours. These users have a remote database and the mobilink synchronization timeout is set to infinite.
Our IT department usually cancels such a synchronization that takes hours, removes the remote database an regenerates the remote database with a new sync....
I managed to get a copy of one of those remote databases and have run it on my own machine with a succesvol synchronization within a minute.
Now, I believe that mobilink just cancels a synchronization if there is a connection problem... Am I mistaken? and should I always have a short timeout?
Reason why we have a infinity timeout is because sometimes querying our consolidated database takes 10 to 20 minutes...And we don't want to cancel the sync because the consolidated database is still gathering data...
Thanks for the help !!
asked 07 Dec '16, 07:14
The timeout parameter you are pointing to is not a timeout applied to active synchronizations (which is something that happens between the DBMLSync process and the MLSrv12 processes). This timeout is an API feature that applies to delay in the conversation that happens between your .Net application and the DBMLSync.exe process this method launches.
The StartServer method launches dbmlsync in, so called, 'server mode' and that will wait for new syncs to be initiated by the application. The timeout setting applies to the delay in that initiation of that sync, so that will have no interaction with, contribution to, or impact on the MobiLink server process, or your consolidated database or any synchronizations that are in progress.
P.S. My links are to the DCX web site. You may find that site easier to navigate than the older style, more static Infocenter 'Sybooks' one.
When you interrogate your DBSC_Event structure what do you see for the
members for the events around you long pauses?
I am suspicious these pauses will be occurring around your upload and download phases (depending upon what data changes are involved) and that could be normal (which could be due to the size of your syncs, performance at your MobiLink server, and possibly network efficiency).
If I am correct about that you will need to investigate this from the MobiLink server side more than the client application side. The API your are using will tell you only so much about performance; only that part known/understood by the dbmlsync process.
If your application hides failed syncs and retries then you could get failed syncs due to networking issues like the ones you mention but the user would not see failure just 'apparent hangs'.
Normally I see (and usually only hear about) sync errors when there is networking issues like the ones you are raising. There is a possibility that the level of transmission issues happens below a certain threshold and does not bubble up through the stack as connection failures. In those cases I would expect to see a lot of keep-alive retransmissions, maybe some degree of packet fragmentation and smaller window sizes due to congestion ... if you could actually measure the wireless traffic.
Mobile networks can be fraught with difficulties ... due to things like congested cells, delays during hand-offs, fall backs to slower bands, collisions, bandwidth limitations and (temporary/transitory) out-of-coverage scenarios and these will tend to be carrier-specific. Usually these will be restricted to certain 'routes'/hotspots, localize to certain times of days and may be localized to some badly maintained towers. If you can track on those kinds of things better, you might be able to identify the specific 'patterns' you have with these hangs.
From the MobiLink server side I would look for long times spent in these 'phases':
as reported with the -vm switch and in the MobiLink Profiler if you are using that. If you don't see large times for these (esp. if the number of rows is small) then you may NOT be looking at a networking issue
answered 08 Dec '16, 12:15
Nick Elson S...