Is you backup disk a slow spinning disk? If it is and your files are large it may just be taking forever to move the files back after migration. How big are your files?
You could test this by setting your default Backup to location on Drive D. Restart OttoFMS and then give it a try. OttoFMS will do it’s work on Drive D and it won’t have to copy the file from E: to D:
That is one thing that is different from Otto3. OttoFMS uses your backup drive to do the migrations. Otto3 did the migrations right in the DB drive.
The files I’m migrating are mainly interface files 50MB, 38MB, and 280MB. It’s a virtual server in Azure with premium-level SSD disks.
I restarted the server and did four migrations, adding a file after each migration, each larger than the last.
First migration 38MB
Second, added the 50MB
Third, added the 280MB
All were successful, which is great.
So I added one more file that was 200MB and the migration stalled after the source files were fetched. Here’s a screenshot after almost 40 minutes
Todd, I uninstalled Otto 3 on the two servers, and the test migrations are working well so far. I did have one migration fail after the files were successfully fetched:
parsing options - Local Admin API error: Fetch failed: Unauthorized code: 956 - Maximum number of Admin API sessions exceeded; Path: /fmi/admin/api/v2/user/auth
I’m trying the same deployment again and the second time I didn’t get the error and the deployment is progressing. Do I need to increase the number of Admins API sessions that are allowed? If so, how is that done?
You shouldn’t need to increase the number of sessions. But that does suggest that something else is going on with your admin server. OttoFMS should only use one session. So something is using up the other sessions.
If you want you can change the number of sessions allowed by editing this file in your FileMaker server directory.
My OttoFMS migrations are still having issues not starting or completing. I need to go back to using Otto V3 until I can get our FMS servers rebuilt. From the last meeting we had I think that’s the best route for now to resolve the instability.
Where can I download the latest copy of Otto V3? I tried going to my proof-geist account purchase history but I can’t find the download link. I need to reinstall it on my main dev server.
Sorry to keep bugging you guys. For the instabilities I’m seeing with OttoFMS/FM Admin tool, do you think it would be sufficient to do a clean install of FMS or is an entire server clean install?
There were some fixes included in OttoFMS version 4.5.0 which should help with your issues with the strange stalling behavior. Let me know if things start getting any better or worse!!
I’ve been testing OttoFMS 4.5.0 with the latest OttoDeploy version. My source server is running FMS 20.3.2 and my destination server is running 21.0.2. Both have clean installs of FMS.
With 4.5.0 I’m not seeing migrations that don’t start or stall after fetching anymore, which is great. I also used the new build feature to publish the clone files to the destination, and that is working great.
I’m still having the issue of files not opening after the migration. The migration completes but stops with the last message of “Starting to open files”. I can open the files manually with the admin console, but OttoFMS never completes and I end up having to restart the OttoFMS service to get it active again.
After I restarted OttoFMS, I created another build with 3 instead of 4 files and pushed it to the destination server and started the deployment. I tried to open the OttoFMS web app to see the progress and it wouldn’t load in Chrome. OttoFMS appeared to be frozen and I restarted it to see how far it got. The deployment log showed it only got as far as “Starting to close files”. I confirmed with the FMS admin tool that all files on the destination server were still open.
Any tips on why OttoFMS is having issues closing and opening files?
I’m glad that the migrations aren’t stalling after fetch anymore!! That is likely due to a fix we added that uses the fmsadmin command line tool instead of the admin api to list the databases.
When we close and open the files we are also using the admin api to run that process, its likely that your admin api is hanging somehow when we make those calls (the same way it was before). I’m not sure why this is happening, although I have had similar things happen on my local server. In my case restarting FileMaker entirely fixes the issue. It sounds like the admin api on this server just doesn’t like OttoFMS for some reason.
We can also take a look at doing the opening and closing of files through the command line in a future version.
I found out that I have to restart the FMS service after a migration so OttomFMS will reopen the files after the next migration. So something breaks after a migration that requires a restart of FMS. It’s consistent with my environment.
I’ve done a clean install of FMS on servers I’m testing but I haven’t done a clean OS install. I was hoping that the clean FMS install would help. How long is Otto 3 going to be supported? I don’t think we’ll be able to do a clean OS install of our production server for at least a couple of months. For now, I’m staying with Otto 3 for our production migrations.
