Skip to content

Propagate startup failure properties to created container#1506

Open
seonwooj0810 wants to merge 1 commit into
spring-projects:mainfrom
seonwooj0810:fix/issue-1505-propagate-startup-failure-props
Open

Propagate startup failure properties to created container#1506
seonwooj0810 wants to merge 1 commit into
spring-projects:mainfrom
seonwooj0810:fix/issue-1505-propagate-startup-failure-props

Conversation

@seonwooj0810
Copy link
Copy Markdown

Fixes #1505

Problem

ConcurrentPulsarListenerContainerFactory#createContainerInstance creates a fresh PulsarContainerProperties for every container and copies only a curated subset of the factory's container properties onto it (consumer task executor, schema/topic resolvers, subscription type/name, transactions). The startup failure policy and startup failure retry template are not among them.

As a result, when a user configures StartupFailurePolicy.RETRY and/or a custom startupFailureRetryTemplate on the factory's container properties — e.g. via a PulsarContainerFactoryCustomizer, which is the documented way to opt into startup retries — those settings are silently dropped and the created container keeps the default STOP policy (Configured to stop on startup failures - exiting).

Fix

Copy the startup failure retry template and policy from the factory props to the container props in createContainerInstance. The retry template is set before the policy because PulsarContainerProperties#setStartupFailureRetryTemplate implicitly switches the policy to RETRY when given a non-null template; the policy is then set explicitly to mirror the factory exactly.

containerProps.setStartupFailureRetryTemplate(factoryProps.getStartupFailureRetryTemplate());
containerProps.setStartupFailurePolicy(factoryProps.getStartupFailurePolicy());

Tests

Added unit tests to ConcurrentPulsarListenerContainerFactoryTests:

  • StartupFailurePolicyFrom — factory's policy is propagated to the created container, and the default (STOP) is used when unset.
  • StartupFailureRetryTemplateFrom — factory's retry template is propagated (and the policy is switched to RETRY accordingly).

Verification done

  • ./gradlew :spring-pulsar:test --tests "*ConcurrentPulsarListenerContainerFactoryTests" — BUILD SUCCESSFUL (new tests pass; compiled with -Werror and the project's nullability/errorprone checks).
  • ./gradlew :spring-pulsar:checkFormat :spring-pulsar:checkstyleMain :spring-pulsar:checkstyleTest — BUILD SUCCESSFUL.
  • Change is limited to the two files above (a stray pre-existing formatting diff the format task surfaced in an unrelated class was reverted).

Note: this PR addresses the startup-failure properties called out by the reproducer; if maintainers prefer, the same propagation block could later be reviewed for any other factory-level properties not yet copied.

ConcurrentPulsarListenerContainerFactory#createContainerInstance builds a
fresh PulsarContainerProperties for each container and only copies a curated
subset of the factory's container properties onto it. The startup failure
policy and startup failure retry template were not among them, so a
StartupFailurePolicy.RETRY (and a custom retry template) configured on the
factory - for example via a PulsarContainerFactoryCustomizer, which is the
documented way to opt into startup retries - was silently dropped and the
container kept the default STOP policy.

Copy the startup failure retry template and policy from the factory props
to the container props. The retry template is set first because setting a
non-null template implicitly switches the policy to RETRY; the policy is
then set explicitly to mirror the factory exactly.

Signed-off-by: seonwoo_jung <79202163+seonwooj0810@users.noreply.github.com>
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

Successfully merging this pull request may close these issues.

ConcurrentPulsarListenerContainerFactory customizations not respected

1 participant