November Happy Hour will be moved to Thursday December 5th.
AI OnAI Off
DXP deployment and model sync not done?
Yep. We have had similar problems and are eager to hear what could cause such issues. Additional restart for the site after deployment usually has resolved the problem.
Aug 02, 2021 16:57
Firstly I'd query the tblContentType database table and observe the version that's been registered for your content type. It can be viewed in the ModelType field:
If the version is incorrect against what you've deployed, then you know the model sync is failing.
Couple of things to consider/check:
- Does the website in your slot use the same database as live? If so - check your logs for any SQL query issues during model synchronization. If the database is under heavy usage, it's worth checking for any specific table locks that may have been in place when the synchronization operation is taking place.
- When updating your AssemblyInfo version - make sure that specifically, the Major, Minor or Build number is incremented. The revision number is not recognised by the model sync operation.
[assembly: AssemblyVersion("1.2.3.4")] // the "4" value is not recognised - Does it happen on other environments?
Aug 02, 2021 18:58
Diep Nguyen
- Aug 11, 2021 2:28
Hi Jay
1. Slots are using the same DB. No heavy usage at all
2. It might an issue but the issue happens with new properties also. I think missing new properties is not related to versioning
3. it happens if the site is using multiple servers with load balancing and the same db
Below is the error on the instance which does not show the new property
"EPiServer.Framework.Initialization.InitializationEngine : Initialize action failed for 'Initialize on class EPiServer.Initialization.Internal.ModelSyncInitialization, EPiServer, Version=11.20.4.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7'
System.Data.SqlClient.SqlException (0x80131904): Cannot insert duplicate key row in object 'dbo.tblPropertyDefinition' with unique index 'IDX_tblPropertyDefinition_ContentTypeAndName'.
It seems all instances tried to update new property into the DB instead just one could do and the other should fetch content from DB
1. Slots are using the same DB. No heavy usage at all
2. It might an issue but the issue happens with new properties also. I think missing new properties is not related to versioning
3. it happens if the site is using multiple servers with load balancing and the same db
Below is the error on the instance which does not show the new property
"EPiServer.Framework.Initialization.InitializationEngine : Initialize action failed for 'Initialize on class EPiServer.Initialization.Internal.ModelSyncInitialization, EPiServer, Version=11.20.4.0, Culture=neutral, PublicKeyToken=8fe83dea738b45b7'
System.Data.SqlClient.SqlException (0x80131904): Cannot insert duplicate key row in object 'dbo.tblPropertyDefinition' with unique index 'IDX_tblPropertyDefinition_ContentTypeAndName'.
It seems all instances tried to update new property into the DB instead just one could do and the other should fetch content from DB
Hi,
have anyone else experienced problems with model sync during DXP deployment? We seems to have the following issue quite often (=or always) with at least one of our customer:
In both cases, when we have model changes (new properties added to page types for example), the changes seem to be missing after the deployment, and will only come visible after launching restart for the site from PaaS portal. We've checked from admin and from the changed page itself to see if model changes are there.
We've had a ticket open for this in support, suggestion was to make sure our assembly version is correctly increased in updates. That we do, as suggested, but still it seems that we always need to do (additional) site restart after deployment. Annoying.
According to this Episerver article the deployment slot is first stopped, then the deployment is done, and then slot is started. My understanding would be that in this process the site is starting when initial load is hitting causing normal initialization and model sync to happen.
Am I missing something here?
For us the extra restart is really a pain in you-know-where because we would like to use deployment API and schedule deployments during night time, but if (manual)site restart is needed, it always requires someone to be available to do that. And the warmup time for our site is quite long (multisite etc) so restart during business ours is always bad.
Ideas?