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
I call streamBridge.send method inside a block that utilizes CompletableFuture.supplyAsync to interrupt execution when it takes longer time than expected. At the first call after application started, messageChannel is not found inside the cache, so the producer tries to bind topic. Binding takes a bit long time and the thread is completed by the CompletableFuture.
Here is the flow after the time exceeds for the supplier run by CompletableFuture.supplyAsync
InterruptedException is thrown inside the thread that tries to bind
It is caught by AbstractMessageChannelBinder.doBindProducer and then BinderException exception is thrown
BinderException is caught by BindingService.doBindProducer and then LateBinding object is returned
Even though binding is not completed, message is tried to be sent in StreamBridge.send. Because resolveDestination method returns without error.
UnicastingDispatcher.getHandlerIterator does not find the handler for the message and throws MessageDispatchingException(message, "Dispatcher has no subscribers");
I expect streamBridge.send to throw InterruptedException but it throws MessageDispatchingException. I could not get why it is required to send message when binding is unsuccessful.
Here is a sample code to reproduce the issue
public String publishMessage(String message) {
ExecutorService executorService = Executors.newSingleThreadExecutor();
TestMessage testMessage = TestMessage.builder().command(Command.ADD_ITEM).message(message).build();
try {
return CompletableFuture
.supplyAsync(() -> customStreamBridge.publishEvent(testMessage.toPartitionedMessage()), executorService)
.exceptionallyAsync(throwable -> {
return null;
}).completeOnTimeout(null, 10, TimeUnit.MILLISECONDS).join();
} finally {
log.info("!!!");
executorService.shutdownNow();
}
}
public class CustomStreamBridge {
private final StreamBridge streamBridge;
public EventStreamBridge(StreamBridge streamBridge) {
this.streamBridge = streamBridge;
}
public String publishEvent(Message<?> message) {
try {
streamBridge.send("test-out-0", message);
} catch (Exception e) {
if (e instanceof InterruptedException) {
// retry with timeout
} else {
throw e;
}
}
return "OK";
}
}
The text was updated successfully, but these errors were encountered:
sobychacko
transferred this issue from spring-attic/spring-cloud-stream-binder-kafka
Nov 5, 2024
Have you actually tried to set StreamBridge to async mode such as streamBridge.setAsync(true) before sending a message? This would avoid all that code you are writing to be able to send message asynch.
Also, if you stil believe there is an issue, please compile a small reproducible sample and push it to GitHub somewhere or attach it as zip so we can take a look,
I call
streamBridge.send
method inside a block that utilizesCompletableFuture.supplyAsync
to interrupt execution when it takes longer time than expected.At the first call after application started,
messageChannel
is not found inside the cache, so the producer tries to bind topic. Binding takes a bit long time and the thread is completed by theCompletableFuture
.Here is the flow after the time exceeds for the supplier run by
CompletableFuture.supplyAsync
InterruptedException
is thrown inside the thread that tries to bindAbstractMessageChannelBinder.doBindProducer
and thenBinderException
exception is thrownBinderException
is caught byBindingService.doBindProducer
and thenLateBinding
object is returnedStreamBridge.send
. BecauseresolveDestination
method returns without error.UnicastingDispatcher.getHandlerIterator
does not find the handler for the message and throwsMessageDispatchingException(message, "Dispatcher has no subscribers")
;I expect
streamBridge.send
to throwInterruptedException
but it throwsMessageDispatchingException
. I could not get why it is required to send message when binding is unsuccessful.Here is a sample code to reproduce the issue
The text was updated successfully, but these errors were encountered: