dylanpiergies commented on code in PR #9592:
URL: https://github.com/apache/camel/pull/9592#discussion_r1143978501


##########
components/camel-azure/camel-azure-servicebus/src/main/java/org/apache/camel/component/azure/servicebus/ServiceBusConsumer.java:
##########
@@ -145,6 +145,9 @@ private void onEventListener(final 
ServiceBusReceivedMessage message) {
         // use default consumer callback
         AsyncCallback cb = defaultConsumerCallback(exchange, true);
         getAsyncProcessor().process(exchange, cb);
+        if (exchange.getException() != null) {

Review Comment:
   There is, but it requires the `ServiceBusReceivedMessage` to be in scope and 
it returns a `Mono<Void>` to which we need to subscribe in order for it to 
execute. The way things are right now, an invocation to 
`ServiceBusReceiverAsyncClientWrapper#complete` or 
`ServiceBusReceiverAsyncClientWrapper#abandon` would return a `Mono<Void>` on 
which we'd then have to invoke `block()`.
   
   I've looked into this problem in some depth, and I'm still looking for the 
"right" approach to addressing this. I kinda feel like using the async client 
isn't a very good fit, because we're then dealing with a component that is 
reactive from the outset and I don't think there's any framework within Camel 
for handling this in a clean and intuitive way (although correct me if I'm 
wrong).
   
   I understand your point about the result not being valid until the callback 
completes, but while I was step debugging I did find that callback was always 
being executed before `getAsyncProcessor().process(exchange, cb);` returned. 
This probably isn't great either, because `onEventListener` is the processor 
for a `Flux` subscription which I believe places it within a reactive context 
and it therefore shouldn't block.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to