spring-cloud / spring-cloud/spring-cloud-stream

MessageChannelBinder support for futures

Open
#2,091 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ideal-for-contribution
Dominant language
Java
Stars
1.1k
Forks
646
Avg merge
2d 3h
Merged PRs (30d)
8

Description

Following is related to: https://github.com/SolaceProducts/solace-spring-cloud/issues/35

I want to do some brain storming how to solve this problematic most elegant.

The Problem:
  • When sending a message to broker
  • The response from broker if the messages was accepted gets async
  • This leads currently to that not submitted messages will only be reported on error channel
  • But this makes it very hard for the application to handle those problem, caused by the missing relation.
Possible improvement A:

https://github.com/spring-projects/spring-integration/blob/a66e82b0aad0eb3ffb909dd5568c14b6713259c0/spring-integration-core/src/main/java/org/springframework/integration/channel/AbstractSubscribableChannel.java#L70

@Override
protected boolean doSend(Message<?> message, long timeout) {
    try {
        CompletableFuture<MessaggingExecption> asyncErrorConsumer = new CompletableFuture<>();
        message.getHeaders().add(MessageHeaders.ERROR_CONSUMER, asyncErrorConsumer);
        
        boolean result = getRequiredDispatcher().dispatch(message);
        
        if (!result) {
          return result;
        }  
        
        MessagingException possibleError = asyncErrorConsumer.get(timeout, TimeUnit.SECONDS);
        if (possibleError != null) {
          throw possibleError;
        }
    
        return result;
    }
    catch (MessageDispatchingException ex) {
        String description = ex.getMessage() + " for channel '" + getFullChannelName() + "'.";
        throw new MessageDeliveryException(message, description, ex);
    }
}
  • The code is everything not nice
  • It is a breaking change that all binders have to implement
  • The benefit of async message persistant confirmation is gone for all producer wanting fire and forget
Possible improvement B:

Rewrite all the sender code including StreamBridge to not return "boolean" but instead "Future"

  • Big refactoring in spring-cloud-stream and spring-integration-core
  • Breaking change for all binder
  • Allows applications to make fire and forget as well as wait for confirmation that the message was persisted/accepted
Possible improvement C:

An äquivalent to:
https://docs.spring.io/spring-cloud-stream-binder-rabbit/docs/3.1.0/reference/html/spring-cloud-stream-binder-rabbit.html#publisher-confirms

But i opened this issue to find a better solution that also could be used from rabbit.

  • A developer can choose if he wants a confirmation.
  • Its not very straight forward. (Not easy to understand)
  • No changes on spring framework.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the referenced AbstractSubscribableChannel.java implementation and the sender code in spring-cloud-stream, including StreamBridge. Compare the proposed CompletableFuture and Future approaches with the Rabbit publisher-confirms behavior. Done requires an agreed API and implementation scope, plus identified tests for asynchronous confirmation and fire-and-forget behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring
Domain
backend, distributed-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.