uSync freezing when importing on Staging Site
# help-with-umbraco
s
I'm using uSync with an Umbraco 13 site. I manually deploy updates to Staging and Production. The process I follow is a full export on my local copy > copy uSync folder to staging site > run report to check changes are being picked up > run health check to pick up any errors > In the back office of my staging site I do a full import. At this point the back office disappears. I restart the site but it hasn't imported my document type changes. I've tried exporting to file, exporting Settings and exporting Content. When importing the same thing usually happens although I'm more successful with Content imports. Any ideas as to why I can't import on my staging site? https://cdn.discordapp.com/attachments/1314603573027274752/1314603573291778068/Import.png?ex=67545f7c&is=67530dfc&hm=269719956f71bc0c333416e98a1d67c6b1a3a0a3cdb3dbbfd10a5943cada62f9& https://cdn.discordapp.com/attachments/1314603573027274752/1314603573681590362/backoffice.png?ex=67545f7c&is=67530dfc&hm=b6832b5009026caed61982f92e3c600ddcd29d931b2e82276dddd533fda9bbe5&
k
Hi, What DB is the site using ? - we do have an open issue on Umbraco v15 - but i think its just with SqLite DBs (and i am not sure if its also a v13 thing - it might be) -
(a full import shouldn't be needed, uSync checks for changes, the diffrence is a 'normal' import will hit the DB less and do less un-needed saves).
(the issue we have with v15 , is a core umbraco thing, something is triggered when the doctypes are updated, and this can cause a lock somewhere, and the import hangs, just like you see,, its loggted with the core team, but it does seem to be a SQLite thing)
It might be worth checking if you have any custom code working on Noitifications (e.g Saved/Saving notifications) these fire during the import and they can fire very quickly - so a lock or potential lock in a notification could also cause something
s
We use SQL and no custom code on Notifications. Can I clarify how a full import vs a normal import is done in the back office?
k
A normal import compares the on disk XML with XML generated from the elements in the database, so if the XML matches there are no writes done to the DB, this makes the normal sync be much faster and less of an impact on the DB. A full import will perform the "import" code regardless, even then this doesn't always result in DB writes because properties are checked to see if they are dirty. This too reduces writes but more do happen because some properties will become dirty (especially properties that are collections) even if they do t "change". None of this should really matter though, because the changes all go through umbracos services (uSync doesn't write directly to the database in anyway). And while you never rule anything out we have done lots to make sure uSync isn't locking anything when all this goes on. However other things do happen in the core when things are updated, for example if you update a document type then internal umbraco events fire and content using that document type can be updated , so if say you change/remove a property used on 1000s of pages that single change can result in Umbraco updating 1000s of pages on a site as part of a document type "save" and that can take a while and look like a hang. Equally the examine indexes will get triggered and that too could take a while (although I think it can happen on background threads).
s
Hi Kevin. we’ve resolved the issue. We encountered some server-related challenges that caused a bottleneck, but that’s now sorted, and uSync is running smoothly 👍
k
Great to hear, if you can/want to share any specific details drop me a line kevin@jumoo.co.uk it can only help us if others have the same, or maybe we can mitigate bits in code
s
I emailed you yesterday with some details.
12 Views