I'm having the same error with uSync after upgrading from Umbraco 7.3.8 to Umbraco 7.4.3. Does anyone have a solution for this? I already upgraded to uSync 3.1.4.740.
going to have a go now. I suspect there is some 'guid'ness things - in 7.3.x i think member types have guids but they are always 0000-000.....
usync upgrade obviously isn't liking it. I am going to have a look.
for now, you can turn of membertypes syncing if you don;t need it. (set <HandlerConfig Name="uSync: MemberTypeHandler" Enabled="false" /> in the usyncbackoffice.config )
there are a couple of other minor fixes in that dll, (changing .net versions down to 4.5 and a vorto property mapper), but they shouldn't affect you once i have done some testing i will package this up into a release.
I upgraded from Umbraco 7.3.8 to Umbraco 7.4.3 and I upgraded uSync from 3.0.3 to 3.1.4.740 and uSync.Core from 5.1.0 to 5.3.5.740.
I am now updating our QA environement with this upgrade, but the upgrade takes a very long time. It's already taking 1 hour and is still running. In the logs I see the following for all doctypes:
2016-07-27 08:03:04,605 [P7196/D18/T25] INFO jumps.umbraco.usync.uSync - Saving C:\Data\inetpub\Project.Web\uSync\\DocumentType\\Data\Mail\CompanyUserMail\def.config
2016-07-27 08:10:16,201 [P7196/D18/T25] INFO jumps.umbraco.usync.uSync - Saving C:\Data\inetpub\Project.Web\uSync\\DocumentType\\Data\Mail\CompanyUserMail\def.config
2016-07-27 08:10:16,201 [P7196/D18/T25] INFO jumps.umbraco.usync.helpers.XmlDoc - Archived [C:\Data\inetpub\Project.Web\uSync\\DocumentType\Data\Mail\CompanyUserMail\def.config] to [C:\Data\inetpub\Project.Web\uSync.archive\\DocumentType\Data\Mail\CompanyUserMail\def_270716_081016.config]
It never took so long before. Is this just once because I upgraded?
hi that looks like you still have one of the old usync dlls in the site,. jumps.umbraco.usync.usync is the v2x dll. i would just remove any jumps.umbraco.* or jumps.usync.* dlls from the site.
We're using uSync on Azure and we have a master server which runs Umbraco and multiple frontend servers. In the logs of the frontend server I also see that uSync runs.
That doesn't need to happen because everything has been updated of course. by the master. They use the same database. Is there somehow a way to detect if an import already run on the database? Currently the frontend seems very slow as long as the import is running.
if you can build it into the process you could use the usync.once and usync.stop files.
placing an file called usync.once in the usync folder (usync\data on new versions) will cause usync to only do one import.
once the import is complete usync renames this file to usync.stop. On every other startup/import it will look for a usync.stop file and if it finds it then it won't run.
so if you create a usync.once when you move files to the server, (and delete any usync.stop file) it should only do the import once.
Thanks for the tip. For now I just going to disable import at startup. A lot of times we update our QA and there are no backoffice changes. So it's better to run the import manually from the backoffice when it's required.
If I enable import on startup I get the following errors in the log:
1
2016-08-02 00:06:40,817 [P8572/D28/T47] ERROR Umbraco.Core.CoreBootManager - An error occurred running OnApplicationStarted for handler Jumoo.uSync.BackOffice.uSyncApplicationEventHandler
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
2
2016-08-02 00:06:40,817 [P8572/D28/T47] ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
at Umbraco.Core.EnumerableExtensions.ForEach[TItem](IEnumerable`1 items, Action`1 action)
at Umbraco.Core.CoreBootManager.Complete(Action`1 afterComplete)
at Umbraco.Web.WebBootManager.Complete(Action`1 afterComplete)
at Umbraco.Core.UmbracoApplicationBase.StartApplication(Object sender, EventArgs e)
3
2016-08-02 00:10:57,592 [P8572/D29/T47] ERROR Umbraco.Core.Persistence.UmbracoDatabase - Database exception occurred
System.Data.SqlClient.SqlException (0x80131904): Transaction (Process ID 115) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Umbraco.Core.Persistence.PetaPocoCommandExtensions.<>c__DisplayClass1.<ExecuteNonQueryWithRetry>b__0()
at Umbraco.Core.Persistence.FaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func)
at Umbraco.Core.Persistence.Database.Execute(String sql, Object[] args)
ClientConnectionId:14d51d07-d570-4573-aab2-e6613b9c1da6
Error Number:1205,State:51,Class:13
ClientConnectionId before routing:34c6ad6f-c2bb-4484-807a-73fd7dd5673c
Routing Destination:newheroes-qa.database.secure.windows.net,1433
4
2016-08-02 00:10:57,592 [P8572/D29/T47] ERROR Umbraco.Core.CoreBootManager - An error occurred running OnApplicationStarted for handler Jumoo.uSync.BackOffice.uSyncApplicationEventHandler
System.Data.SqlClient.SqlException (0x80131904): Transaction (Process ID 115) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
ClientConnectionId:14d51d07-d570-4573-aab2-e6613b9c1da6
Error Number:1205,State:51,Class:13
ClientConnectionId before routing:34c6ad6f-c2bb-4484-807a-73fd7dd5673c
Routing Destination:newheroes-qa.database.secure.windows.net,1433
After this the website keeps restarting. When I disable import on startup and try to run the import from the dashboard I get an unknown error without anything in the logs.
My config files in \uSync\data are pretty old from older versions of uSync (all v3) which might contain errors. I'm thinking about regenerating all the files with the latest version, but I don't want to lose any content.
Hmm I regenerated all the uSync files, but a lot of keys are different. Probably because we once copied the prod db back to dev to have all the live content. Not sure what happens if I do the import.
from 7.3 - > 7.4 then the way usync links to many things has changed (mainly because the core api of umbraco started letting us track by guids)
Previously it was all alias and named based and now it actively sets the keys, on the target sites.
What 'should' happen is that uSync will look by key, not find the elements then look by alias, find them and set their keys to match those on the import, Then any subsequent imports it will all be key based, so things like renames work much better.
Having said that I would test this on a non-live version of the site first.
Hmm interesting. I was thinking about generating the uSync files on our qa since those keys now still match. But maybe I should just generate all the files on dev and move those to qa to see what happens.
So if move my language doctype config file from dev to qa and the keys don't match they should after the import? Let's try :-).
The import worked and everything on the qa is now the same as the dev. Even the keys are the same :-).
I am running the code on both master and slave server. For now it's fine for me that it runs twice. However on the master everything worked and I see all the import actions without errors.
On the slave I still get this error:
2016-08-02 15:12:30,227 [P7016/D122/T27] ERROR Umbraco.Core.CoreBootManager - An error occurred running OnApplicationStarted for handler Jumoo.uSync.BackOffice.uSyncApplicationEventHandler
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
2016-08-02 15:12:30,243 [P7016/D122/T27] ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
at Umbraco.Core.EnumerableExtensions.ForEach[TItem](IEnumerable`1 items, Action`1 action)
at Umbraco.Core.CoreBootManager.Complete(Action`1 afterComplete)
at Umbraco.Web.WebBootManager.Complete(Action`1 afterComplete)
at Umbraco.Core.UmbracoApplicationBase.StartApplication(Object sender, EventArgs e)
Any idea why that would still happen? Guess for now I should still disable the import and manually run it on the qa master.
2016-08-02 15:10:18,491 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.uSyncApplicationEventHandler - Initializing uSync 73
2016-08-02 15:10:18,504 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.uSyncApplicationEventHandler - Firing up uSync
2016-08-02 15:10:18,629 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.uSyncBackOfficeContext - Loading up Sync Handlers : 8
2016-08-02 15:10:18,862 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.uSyncApplicationEventHandler - Running Full uSync Import
2016-08-02 15:10:18,894 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Running Import: DataType
2016-08-02 15:10:18,909 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:18,925 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:18,940 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:18,972 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:18,987 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,019 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,034 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,050 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,065 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,097 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,112 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,128 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,159 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,190 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,213 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,228 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:19,259 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Handlers.DataTypeHandler - Deleting datatype: SEO Checker
2016-08-02 15:10:19,993 [P7016/D121/T15] INFO Umbraco.Core.PluginManager - Starting resolution types of umbraco.interfaces.ICacheRefresher
2016-08-02 15:10:20,103 [P7016/D121/T15] INFO Umbraco.Core.PluginManager - Completed resolution of types of umbraco.interfaces.ICacheRefresher, found 0 (took 117ms)
2016-08-02 15:10:20,763 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IDataTypeDefinition
2016-08-02 15:10:59,594 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Handler Import Complete: 402 Items 20 changes 0 failures
2016-08-02 15:10:59,594 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Running Import: Template
2016-08-02 15:10:59,594 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.ITemplate
2016-08-02 15:10:59,719 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.ITemplate
2016-08-02 15:10:59,719 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.ITemplate
2016-08-02 15:11:00,211 [P7016/D121/T15] WARN Jumoo.uSync.Core.Serializers.TemplateSerializer - Cannot find underling template file, so we cannot create the template
2016-08-02 15:11:00,211 [P7016/D121/T15] WARN Jumoo.uSync.Core.Serializers.TemplateSerializer - Can't get a template path?
2016-08-02 15:11:01,091 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Handler Import Complete: 52 Items 4 changes 0 failures
2016-08-02 15:11:01,091 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Running Import: DocumentType
2016-08-02 15:11:01,091 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:01,750 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:01,813 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:01,844 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:01,907 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:01,969 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,033 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,094 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,157 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,204 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,266 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,329 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,409 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,469 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,534 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,813 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,860 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,922 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:02,969 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,032 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,094 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,141 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,204 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,251 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,313 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:03,360 [P7016/D121/T15] INFO Jumoo.uSync.BackOffice.Logging - Processing a Delete: Umbraco.Core.Models.IContentType
2016-08-02 15:11:14,536 [P7016/D121/T15] ERROR Umbraco.Core.CoreBootManager - An error occurred running OnApplicationStarted for handler Jumoo.uSync.BackOffice.uSyncApplicationEventHandler
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
2016-08-02 15:11:14,552 [P7016/D121/T15] ERROR Umbraco.Core.UmbracoApplicationBase - An unhandled exception occurred
System.NullReferenceException: Object reference not set to an instance of an object.
at Jumoo.uSync.BackOffice.uSyncApplicationEventHandler.Setup()
at Umbraco.Core.ApplicationEventHandler.OnApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
at Umbraco.Core.CoreBootManager.<Complete>b__a(IApplicationEventHandler x)
at Umbraco.Core.EnumerableExtensions.ForEach[TItem](IEnumerable`1 items, Action`1 action)
at Umbraco.Core.CoreBootManager.Complete(Action`1 afterComplete)
at Umbraco.Web.WebBootManager.Complete(Action`1 afterComplete)
at Umbraco.Core.UmbracoApplicationBase.StartApplication(Object sender, EventArgs e)
2016-08-02 15:11:30,295 [P7016/D122/T27] INFO Umbraco.Core.CoreBootManager - Umbraco 7.4.3 application starting on RD0003FF69AE61
That's it :-D. Somehow on the slave there is still a uSyncActions.config which is not on the master. Will figure out why, but this must be the problem. Will continue tomorrow. Thanks!
I was thinking about removing the uSyncActions.config file, but it might return in the future if I have more actions. So it might be better to just make the file empty. Is only having the ArrayOfSyncAction open and close element enough?
There was a problem where files we're not removed from the slave. Even after removing the uSyncActions.config file I got the same exception but probably related to another old file. Now that the slave is cleaned up everything works :-).
Nuget Upgrade 7.3.7 to 7.4 errors
Just upgraded a 7.3.7 site to 7.4. When the install ran and I clicked continue I got a YSOD in the popup window:-
I restarted and the site appears to run ok.
Craig
Exactly the same thing happened with me, but the site runs okay
I had this issue too. For me the site didn't work afterwards - got the same error on front-end pages too.
I believe the error might have been a uSync problem as I removed the uSync folder and my site then started ok.
Hi there,
I've just run into the same issue - everything works fine if I exclude the following file:
uSync/data/MemberType/def.config
But this doesn't seem like a "Good Idea" (tm) - any suggestions?
Cheers
Pete
Sorry I marked this post as the answer by accident. Cannot undo it.
I'm having the same error with uSync after upgrading from Umbraco 7.3.8 to Umbraco 7.4.3. Does anyone have a solution for this? I already upgraded to uSync 3.1.4.740.
Jeroen
Hi,
going to have a go now. I suspect there is some 'guid'ness things - in 7.3.x i think member types have guids but they are always 0000-000.....
usync upgrade obviously isn't liking it. I am going to have a look.
for now, you can turn of membertypes syncing if you don;t need it. (set
<HandlerConfig Name="uSync: MemberTypeHandler" Enabled="false" />in the usyncbackoffice.config )but i will see if i can fix this in the code.
The error I'm having is also about member types so it's probably related. Disable member types is a good workaround for now. Thanks!
Jeroen
cool,
If you do need it. there is a fix for this on github now :
you could just take jumoo.usync.core.dll from here: https://github.com/KevinJump/uSync/tree/Dev-v7_4/umbPackage/uSync.Core
there are a couple of other minor fixes in that dll, (changing .net versions down to 4.5 and a vorto property mapper), but they shouldn't affect you once i have done some testing i will package this up into a release.
I upgraded from Umbraco 7.3.8 to Umbraco 7.4.3 and I upgraded uSync from 3.0.3 to 3.1.4.740 and uSync.Core from 5.1.0 to 5.3.5.740.
I am now updating our QA environement with this upgrade, but the upgrade takes a very long time. It's already taking 1 hour and is still running. In the logs I see the following for all doctypes:
It never took so long before. Is this just once because I upgraded?
Jeroen
hi that looks like you still have one of the old usync dlls in the site,.
jumps.umbraco.usync.usyncis the v2x dll. i would just remove anyjumps.umbraco.*orjumps.usync.*dlls from the site.Yup you're right. Somehow on the QA that file was still there. It wasn't on the dev.
Jeroen
We're using uSync on Azure and we have a master server which runs Umbraco and multiple frontend servers. In the logs of the frontend server I also see that uSync runs.
That doesn't need to happen because everything has been updated of course. by the master. They use the same database. Is there somehow a way to detect if an import already run on the database? Currently the frontend seems very slow as long as the import is running.
Jeroen
if you can build it into the process you could use the usync.once and usync.stop files.
placing an file called usync.once in the usync folder (usync\data on new versions) will cause usync to only do one import.
once the import is complete usync renames this file to usync.stop. On every other startup/import it will look for a usync.stop file and if it finds it then it won't run.
so if you create a usync.once when you move files to the server, (and delete any usync.stop file) it should only do the import once.
Kevin
Thanks for the tip. For now I just going to disable import at startup. A lot of times we update our QA and there are no backoffice changes. So it's better to run the import manually from the backoffice when it's required.
Jeroen
I've upgraded to uSync 3.1.5.740.
If I enable import on startup I get the following errors in the log:
1
2
3
4
After this the website keeps restarting. When I disable import on startup and try to run the import from the dashboard I get an unknown error without anything in the logs.
My config files in \uSync\data are pretty old from older versions of uSync (all v3) which might contain errors. I'm thinking about regenerating all the files with the latest version, but I don't want to lose any content.
Jeroen
humm : (
I would say regenerate the usync/data folder (just rename the existing on to keep it fist!)
if you want/can - send me a zip copy of the existing data folder and i will see if i can work out whats happening ?
Kevin
Hmm I regenerated all the uSync files, but a lot of keys are different. Probably because we once copied the prod db back to dev to have all the live content. Not sure what happens if I do the import.
Jeroen
from 7.3 - > 7.4 then the way usync links to many things has changed (mainly because the core api of umbraco started letting us track by guids)
Previously it was all alias and named based and now it actively sets the keys, on the target sites.
What 'should' happen is that uSync will look by key, not find the elements then look by alias, find them and set their keys to match those on the import, Then any subsequent imports it will all be key based, so things like renames work much better.
Having said that I would test this on a non-live version of the site first.
Hehe yup I am testing this on our qa.
Simple example maybe.
Local Language doctype has key: 7AF3F872-3C7E-8D79-8CBA-4C69E08BA17A
On qa and prod it has this key: B92A870A-7FA6-413B-91DA-2740BFEF4B6B
I can see in github that the doctyp config file changed the key from the qa/prod key to the dev key.
So after regenerating the files the keys don't match. Looks like somehow all the keys are different on qa and dev.
Some newer doctypes do have the same key.
Jeroen
In theory after a full sync of the new files the keys in the DB should be the same as those on Dev.
It's only later versions of Umbraco 7.4+ where setting the key on lots the properties and nodes actually worked and get back into the db.
Even then:
everything else should match by key, and if it can't find it match by alias (and then set key)
Hmm interesting. I was thinking about generating the uSync files on our qa since those keys now still match. But maybe I should just generate all the files on dev and move those to qa to see what happens.
So if move my language doctype config file from dev to qa and the keys don't match they should after the import? Let's try :-).
Jeroen
The import worked and everything on the qa is now the same as the dev. Even the keys are the same :-).
I am running the code on both master and slave server. For now it's fine for me that it runs twice. However on the master everything worked and I see all the import actions without errors.
On the slave I still get this error:
Any idea why that would still happen? Guess for now I should still disable the import and manually run it on the qa master.
Jeroen
yeah that error is a bit generic :(
I haven't worked out why, it's the end of stack, so something is wrong inside usync but only the end is getting displayed.
is their any usync logging around the error in the logs (just to get an idea which bit was getting synced when it happened)
Here is the full qa slave log:
Jeroen
And here is the log for the qa master which did work:
Jeroen
the first one is doing a lot of deletes,
is there a usyncactions.config file in usync one folder and not in the other?
That's it :-D. Somehow on the slave there is still a uSyncActions.config which is not on the master. Will figure out why, but this must be the problem. Will continue tomorrow. Thanks!
Jeroen
OK,
I am still a bit worried that it YSODed though :(
Will go through the code see if i can work out how and why that happened
K
I was thinking about removing the uSyncActions.config file, but it might return in the future if I have more actions. So it might be better to just make the file empty. Is only having the ArrayOfSyncAction open and close element enough?
Jeroen
i would just delete the file, uSync will recreate it if it's needed.
Problem is that I deleted the file and somehow it's still on the qa slave. So I prefer to have it in my source control as an empty file.
Jeroen
There was a problem where files we're not removed from the slave. Even after removing the uSyncActions.config file I got the same exception but probably related to another old file. Now that the slave is cleaned up everything works :-).
Jeroen
is working on a reply...