Skip to content

Conversation

@cppwfs
Copy link
Contributor

@cppwfs cppwfs commented Jan 14, 2026

Fixes: #10697

Address race condition in Mqttv5PahoMessageHandler when multiple threads attempt to connect simultaneously.

Changes:

  • Add RetryTemplate with configurable retry count for connection attempts
  • Implement MqttExceptionMatcher to handle specific MQTT error codes
  • Add setRetryConnectionCount method to configure retry behavior
  • Create test suite validating retry logic

The retry mechanism specifically handles REASON_CODE_CONNECT_IN_PROGRESS and REASON_CODE_CLIENT_CONNECTED errors, allowing the client to recover gracefully when connection establishment is already in progress. Default retry count is set to 5 with 100ms delay between attempts.

Fixes: spring-projects#10697

Address race condition in `Mqttv5PahoMessageHandler` when multiple
threads attempt to connect simultaneously.

Changes:
- Add `RetryTemplate` with configurable retry count for connection
  attempts
- Implement `MqttExceptionMatcher` to handle specific MQTT error codes
- Add `setRetryConnectionCount` method to configure retry behavior
- Create test suite validating retry logic

The retry mechanism specifically handles `REASON_CODE_CONNECT_IN_PROGRESS`
and `REASON_CODE_CLIENT_CONNECTED` errors, allowing the client to
recover gracefully when connection establishment is already in
progress. Default retry count is set to 5 with 100ms delay between
attempts.
@cppwfs cppwfs requested a review from artembilan January 14, 2026 22:59
@artembilan
Copy link
Member

Good. I’ll take a look into your idea in the morning. Meanwhile , please , check this where we give a retry option already: https://docs.spring.io/spring-integration/reference/handler-advice.html

Enhance `Mqttv5PahoMessageHandler` to support custom `RetryTemplate`
configuration for connection retry logic. Previously, the retry
behavior was hardcoded with a fixed policy. Users can now provide
their own `RetryTemplate` for more flexible retry strategies.

Changes:
- Add `connectionRetryTemplate` field to store custom retry template
- Add `setConnectionRetryTemplate` setter for configuration
- Initialize `connectionRetryTemplate` in `onInit` if not already set
- Rename `getRetryTemplate` to `getDefaultConnectionRetryTemplate`
- Update Javadoc for `setRetryConnectionCount` to note custom template takes precedence
- Remove NOSONAR comment from token wait call
@cppwfs
Copy link
Contributor Author

cppwfs commented Jan 15, 2026

Good point. I thought about allowing the user set the retry policy but thought it was overkill. But after your comment above, I reconsidered and added that capability.

Provide a lightweight while to check for connection vs heavyweight retrytemplate
Copy link
Member

@artembilan artembilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great!
Thank you!

* It assumed multi-thread issue which is not always correct
* Update documentation to remove multi-thread connection association
* Cleanup based on code review
Copy link
Member

@artembilan artembilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!
Will merge when build is green

@artembilan artembilan merged commit 9db27af into spring-projects:main Jan 15, 2026
3 checks passed
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.

Revise MQTT Message Handlers logic around recconnection

2 participants