Operational Defect Database
BugZero updated this defect 44 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
VMware | 90707
vCenter Content Library sync fails when a subscribed library processes changes to items out of order.
Last update date:
4/5/2024
Affected products:
vCenter Server
Affected releases:
8.07.0
Fixed releases:
No fixed releases provided.
Description:
Symptoms
Subscribed libraries might fail to sync changes on an itemMessages similar to the following might be seen in /var/log/vmware/content-library/cls.log. error = TransferError (com.vmware.transfer.transfer_error) => { message = Reached the maximum number of retries (10) while attempting to transfer from com.vmware.transfer.impl.HttpClientEndpointImpl@c5f0374. Failing transfer.,2022-12-24T23:59:59.512Z | ERROR | abcdefg-23436551-auto-dcba-h5:73829-83-74-d8 | cls-simple-activity-3 | SimpleActivityWorker | Exception will not be handled by activity UpdateLibraryItemActivity (handle=35780f2-c13d-4569-a338-31575fe9664, entityId=8241a0f2-ad8b-4aba-b235-38ca5fe8e5): AlreadyExists (com.vmware.vapi.std.errors.already_exists) => { messages = [LocalizableMessage (com.vmware.vapi.std.localizable_message) => { id = com.vmware.vdcs.cls-main.duplicate_item_name_unsupported_in_library, defaultMessage = Operation is not supported since a library item with the name xdt_isp exists in the library 'TestSubscriber' (ID: 8241a0f2-ad8b-4aba-b235-38ca5fe8e5)., args = [xdt_isp, CLS-Subscriber-library, 8241a0f2-ad8b-4aba-b235-38ca5fe8e5], params = <null>, localized = <null>}], data = <null>, errorType = ALREADY_EXISTS} Important Note: The error "Reached the maximum number of retries (10)" is also seen in cls.log when the concurrent transfer limit is reached for long enough to cause a library item file to timeout. This is not the same scenario as what is described in this article.
Cause
When several changes are made on content library items, and subscribing libraries pull these changes down via a sync operation, they can be prioritized and executed in the wrong order on the subscribed vCenter, leading to a conflict. For example, if an item is renamed and then deleted, the subscriber side might receive these out of order and attempt to delete it before renaming it, leading to a sync failure.
Resolution
VMware is aware of this issue and working towards a resolution.
Workaround
You can work around this issue by issuing a manual sync on an item before making any further changes that might conflict if read out of order.
Related Information
Depending on the tasks that are taken on the Content Library Items, there are other ways this may surface, which may result in differing log entries than stated in the symptoms section.
