|
One of our customers is experiencing this failure on multiple remotes. The C partition runs out of space, with many MLSY* files found in C:WindowsTemp, and synchronization fails or hangs. The customer is not able to provide dbmlsync logs because they have turned logging off to save disk space. That said, I believe they have lots of free space on another partition on the affected machines. My main question is how to configure dbmlsync to use an alternate drive/folder for its temp files. Secondly, does the presence of 1.5 GB of MLSY* files indicate a problem? There can be a large volume of data to synchronize. All remotes and the consolidated are Windows 2008 Server 64-bit, running SQL Anywhere databases. Mobilink/SQLA version is 11.0.1.2506. Thanks, Bob Leviton |
|
The tmp environment variable can can be used to tell dbmlsync where to put its temporary files. The size of the temporary file generated will depend primarily on the size of the uploads and downloads being performed. Unless you are uploading/downloading very large amounts of data 1.5 GB seems like a very large temporary file. Normally, dbmlsync should delete its temporary file when it shuts down cleanly. If an instance of dbmlsync crashes, the temp files from the crashed instance should be deleted the next time dbmlsync runs. It is safe to manually delete the mlsy* tempfiles as long as dbmlsync is not running. We did recently fix a bug where the cleanup mechanism could fail if the satmp environment variable was set. This fix will be in the next EBF. You might want to ask your customer to unset satmp if they have it set. If none of this helps, can you ask your customer to take one of the affected systems, shut down dbmlsync cleanly and see if the tempfiles remain. If they do they are likely left over from a previous crashed instance. Delete the tempfiles. Run a sync and again shutdown dbmlsync cleanly. See if any new tempfiles appear. That will tell us if the problem has to do with cleaning up after crashed instances. It would also be helpful to know what environment variables they have set. Thanks for the quick reply, Dave. We will pass this on to the customer and I'll let you know if dbmlsync isn't cleaning up properly once it is up and running again.
(21 Nov '12, 12:01)
Bob Leviton
|
