You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The MCE and MAE consumer services in DataHub start processing messages without waiting for the version check. This can potentially lead to issues where newer versions of consumers run with older versions of GMS.
To Reproduce
Steps to reproduce the behavior:
Deploy GMS, MCE and MAE as separate pods in a K8s cluster
Upgrade images to new versions
At this point the new GMS pod will wait for datahub-upgrade job to finish running with the corresponding version. The old GMS pod will continue running. MCE/MAE will start with the new version regardless of datahub-upgade.
Expected behavior
The expectation is that both MCE and MAE consumers will perform a version check during startup to match the version number published to the Kafka topic by datahub-upgrade.
Additional context
The bootstrapManager is not started in ApplicationStartupListener when running any consumer in standalone mode, as the context id is actually "application", which is the default for SpringBoot configured contexts, not WebApplicationContext.class.getName(). Maybe an alternative check to see if the current context is the root context would be to check if the current context has no parent, which should work in both standalone and gms only deployments.
The text was updated successfully, but these errors were encountered:
Describe the bug
The MCE and MAE consumer services in DataHub start processing messages without waiting for the version check. This can potentially lead to issues where newer versions of consumers run with older versions of GMS.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The expectation is that both MCE and MAE consumers will perform a version check during startup to match the version number published to the Kafka topic by datahub-upgrade.
Additional context
The bootstrapManager is not started in ApplicationStartupListener when running any consumer in standalone mode, as the context id is actually "application", which is the default for SpringBoot configured contexts, not WebApplicationContext.class.getName(). Maybe an alternative check to see if the current context is the root context would be to check if the current context has no parent, which should work in both standalone and gms only deployments.
The text was updated successfully, but these errors were encountered: