Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicorn thread hangs while changing template on sitecore media Items #410

Open
jdb0317 opened this issue Apr 15, 2021 · 7 comments
Open

Comments

@jdb0317
Copy link

jdb0317 commented Apr 15, 2021

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Unicorn data provider is making extra requests to database, which is causing the delay while attempting to change media items from unversioned to versioned. In my tests, the problematic thread is Thread#110, which is running for about ~18 seconds. It is suggested to disable unicorn from deployed environments but we currently use it to deploy templates and layouts. Sitecore support suggested that I reach out to unicorn team directly.

If the current behavior is a bug, please provide the steps to reproduce.
Apply unicorn to environment.
Log into sitecore content editor
Select media item (pdf or image) that has an unversioned or versioned media template
Change template from unversioned to versioned (or vice-versa)

What is the expected behavior?
Sitecore should be able to update templates without timing out.

Please mention your Sitecore version and Unicorn version.
Sitecore version 9.1 (initial release)
Unicorn version 4.0.8

@cassidydotdk
Copy link
Member

You don't need to disable Unicorn entirely on your target environment. But make sure you don't have the DataProvider active. Unicorn should not be triggering anything on your target which tells me you overlooked this.

@jdb0317
Copy link
Author

jdb0317 commented Apr 20, 2021

Is there something specific here that happens during builds or should I be able to simply remove the element from the config? I ask because doing so seems to break all of my sitecore items that were base on a synced template.

@cassidydotdk
Copy link
Member

Not sure what you mean. Unicorn.DataProvider.config should not be present on your target instance at all; alternatively make sure it is only activated for the StandAlone role (your target environment will be ContentManagement and ContentDelivery etc)

@jdb0317
Copy link
Author

jdb0317 commented Apr 26, 2021

I am able to disable Unicorn.DataProvider.config as long as I restore the previously synced templates/layouts with a sitecore package. So is it the case that transparent sync should not be used to deploy to non-developer environments?

@cassidydotdk
Copy link
Member

The media item you are issuing a change-template on, is it under Unicorn control in the target environment? if so, it raises two additional questions. 1. why? 2. if you issue the same change-template on your dev environment is the problem the same?

@strice
Copy link

strice commented Apr 27, 2021

Hi @cassidydotdk - I'm working with @jdb0317 on this issue.

The media item you are issuing a change-template on, is it under Unicorn control in the target environment? if so, it raises two additional questions. 1. why? 2. if you issue the same change-template on your dev environment is the problem the same?

The media items themselves are not configured to be serialized by Unicorn. However, some of the media templates used by those items are being serialized/controlled by Unicorn (e.g. /sitecore/templates/System/Media/Versioned/Pdf).

Would you still expect this behavior in that case?

@cassidydotdk
Copy link
Member

Not sure. This isn't really a tested use-case. I will try and see if I can reproduce on my test environment. But if the items in question are not under Unicorn control, no actual change happens to items under Unicorn control. And if so, I don't really see how Unicorn could be involved at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants