Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resilient Emitter behaviour for continuous Message publishing #9545

Open
botsteve opened this issue Nov 29, 2024 · 0 comments
Open

Resilient Emitter behaviour for continuous Message publishing #9545

botsteve opened this issue Nov 29, 2024 · 0 comments

Comments

@botsteve
Copy link

Environment Details

  • Helidon Version: 4.x
  • Helidon MP
  • JDK version: 21

Problem Description

The current behavior of the Emitter API in the MicroProfile Messaging specification enforces that when an error is encountered (via the Emitter.error(Throwable) method), the emitter transitions to a failed state. Once in this state:
1. A failure event is sent to the channel.
2. No further messages can be sent through the emitter.
3. The application requires a restart to re-establish the emitter’s operability.

This design aligns with the principle that error states should halt further processing to prevent unpredictable behavior. However, in scenarios involving transient failures—such as temporary disconnections or outages of the external message broker (e.g., Kafka)—this behavior poses challenges:
• The entire application or pod often needs to restart, disrupting other unrelated application functionality.
• The inability to resume message publishing after the broker reconnects without a restart limits fault tolerance.

Proposed Enhancement

Enable Recovery and Continuation:

  • Automatically detect when the external message broker is back online and resume normal message publishing.
  • Allow the application to continue operating without requiring a full restart, ensuring high availability for other functionalities.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

No branches or pull requests

1 participant