Skip to Content
0
Jun 08, 2018 at 05:13 PM

CatalogVersionSyncJob and abortOnCollidingSync not working?

533 Views

Hello

In Hybris version > 6.3.0.9 and at least in 6.7.0.0 which we are currently running...a new attribute has been introduced on CatalogVersionSyncCronJobModel. This attribute is called abortOnCollidingSync and nowadays controls whether a CronJob should be set to state = ABORTED or be left in UNKNOWN state if another CatalogVersionSyncCronJob is currently running.

The logic for canPerform() also performs a randomized sleep for all CronJobs created by a job which are in UNKNOWN. This sleep is a random time of 200 + (1-1000) for each job found to be in this UNKNOWN state.

We have an automated trigger for our ProductCatalog which will trigger a catalogsync every 15 minutes, so we happen to get a few of these (not overly many). One bad sideeffect are these lines in the log

 2018-06-08T07:45:18,317 WARN  CatalogVersionSyncJob   - Other cron job '0000AU2P' (pk:8812658491893) is still in UNKNOWN state. Waiting '986' milliseconds for start
 2018-06-08T07:45:19,307 WARN  CatalogVersionSyncJob   - Other cron job '0000AU4M' (pk:8812660752885) is still in UNKNOWN state. Waiting '280' milliseconds for start
 2018-06-08T07:45:19,595 WARN  CatalogVersionSyncJob   - Other cron job '0000AUC3' (pk:8812669567477) is still in UNKNOWN state. Waiting '839' milliseconds for start
 2018-06-08T07:45:20,435 WARN  CatalogVersionSyncJob   - Other cron job '0000B00S' (pk:8812911034869) is still in UNKNOWN state. Waiting '665' milliseconds for start
 2018-06-08T07:45:21,102 WARN  CatalogVersionSyncJob [(0000B1PQ) ]   - Other cron job '0000AI4J' (pk:8812151046645) is still in UNKNOWN state. Waiting '972' milliseconds for start
 2018-06-08T07:45:22,088 WARN  CatalogVersionSyncJob [(0000B1PQ) ]   - Other cron job '0000AI66' (pk:8812152979957) is still in UNKNOWN state. Waiting '228' milliseconds for start
 2018-06-08T07:45:22,317 WARN  CatalogVersionSyncJob [(0000B1PQ) ]   - Other cron job '0000AI8Z' (pk:8812156289525) is still in UNKNOWN state. Waiting '582' milliseconds for start
 2018-06-08T07:45:22,899 WARN  CatalogVersionSyncJob [(0000B1PQ) ]   - Other cron job '0000AFUE' (pk:8812054151669) is still in UNKNOWN state. Waiting '1172' milliseconds for start
 2018-06-08T07:45:24,072 WARN  CatalogVersionSyncJob [(0000B1PQ) ]   - Other cron job '0000AKK9' (pk:8812254527989) is still in UNKNOWN state. Waiting '1053' milliseconds for start

Annoying.

There is also a new button for synchronization in backoffice. It is just labeled Synchronize. If you click this button on a CatalogVersion, (warning: By default you get a full sync with forceUpdate=true.You can override that behavior with backoffice.sync.config.forceUpdate=false) you will actually run with abortOnCollidingSync=true since that is how it is implemented.

Using the old button (one step to the left) will bring up the dialog and you can choose if you want forceUpdate or not. This button will not set abortOnCollidingSync=true so that will be false and you can get some new UNKNOWNS if you are lucky.

Triggered syncjobs do not get configured with abortOnCollidingSync and there does not seem to be a way to get them to. This seems like a bug to me

We will probably solve our issue here with a LoadInterceptor<CatalogVersionSyncCronJobModel> to set abortOnCollidingSyncto true when it is unset, or possibly injecting a nulldecorator on the model. I don't know which is better. Right now I'm thinking LoadInterceptor so I can easily remove it if this gets fixed.

Do you agree this is a bug?

Martin