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
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.
The text was updated successfully, but these errors were encountered:
Environment Details
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:
The text was updated successfully, but these errors were encountered: