|
Hi, 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 !! |
|
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. HTH 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. Thank you for the clarification and the interresting links. I am reading them now. After the sync command my code checks GetEvent in a loop as long as it equals DBSC_GETEVENT_OK. If it's not ok, then shutdownserver, waitforservershutdown, disconnect and fini is called.... This seems to work when testing... So I'm a bit confused on what could cause these a long wait during synchronization.... PS. What is also not clear to me is what happens when the connection to mobilink disappears... (for example because the remote loses their wifi connection) FYI=> here is the sync code that I use: https://dl.dropboxusercontent.com/u/3246050/mobisync.txt
(08 Dec '16, 02:57)
vdcey
|
|
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. Thanks for your response. Unfortunately I currently can't reproduce the long pauses since this happens occasionally... But if I understand you correctly... the sync should not be "just stuck" but in a paused status... I have thought of the 3 possibilities that you are mentioning and I suspected that there are network problems and the sync either doesn't stop when the network drops away or doesn't continue when the network connection returns... Is this something that is possible?..... size of the sync is relatively small, load on the mobilink server is from time to time high but never for more than an hour... the users are always on the road and network connection is limited.... Before the sync starts, I always check for a working connection though...
(08 Dec '16, 10:19)
vdcey
|
|
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 |